SR&ED for software development: what qualifies, with AI/ML and SaaS examples

This is an independent guide. ClearSRED is not affiliated with the Canada Revenue Agency. Eligibility always depends on the facts of your project.

How big is software in the SR&ED program?

Software is the largest single field in the program. Here are the key points as of October 2026.

How does the CRA test apply to software?

The same test applies to code as to chemistry. The CRA's eligibility guidelines ask why the work was done and how it was done. For software, that breaks into three questions.

1. Was there a technological uncertainty, or just routine engineering?

The CRA says new knowledge is needed when "it is unknown (or uncertain) whether a given result or objective can be achieved," because available knowledge is insufficient. Available knowledge means what your team knows plus what is reasonably available publicly, such as documentation, papers, open-source code, vendor guidance and developer forums.

Most software work is routine engineering: a competent developer knows how to build it, even if it takes time. The CRA notes that businesses normally "follow known design methods, techniques, procedures, protocols, standards and other practices." The CRA lists problem characteristics that may suggest available knowledge is insufficient, including existing design methods that don't apply, too many variables or unknowns, parameters outside the normal operating range, and interlocking constraints. If you got around a problem with a known workaround, that is not SR&ED.

2. Was the goal a technological advancement, not a product feature?

The advancement is new knowledge about the technology, not what the product can now do. The CRA's T661 guide warns that novelty, feature enhancement or increased functionality "may not in itself" demonstrate a technological advancement. "Customers can now export to PDF" is a feature. "We learned that approach X cannot hold p99 latency under 50 ms beyond 10,000 concurrent writers, and why" is knowledge.

3. Was the work a systematic investigation?

You need hypotheses, tests by experiment or analysis, and conclusions drawn from results, with evidence kept as the work went on. Sprints and code reviews are systematic, but the CRA says it "is not enough that work be carried out systematically." The process must be aimed at the uncertainty itself.

Failures count. Two abandoned approaches with benchmarks showing why they failed are often the strongest part of a software claim. Not sure where your projects land? Our SR&ED eligibility check walks through these questions.

What typically qualifies, and what doesn't?

These are typical patterns, not rules. The same task can land on either side depending on what your team knew at the start.

Can AI and machine learning work qualify for SR&ED?

Yes, when it meets the same test. Using AI is not itself SR&ED, and building with AI is not automatically excluded. What matters is whether the outcome was uncertain given what the field already knows, and that knowledge moves fast. We would describe the following as patterns, not guarantees.

Work that may qualify:

• Architecture under constraints. Designing a model that must fit on-device memory or a latency budget while holding an accuracy target, where published architectures miss one constraint or the other.
• Latency and accuracy trade-offs at scale. Not knowing whether quantization, distillation or retrieval changes can keep quality above a measured threshold at your inference volume, then testing it systematically.
• Data pipeline limits. Training or retrieval pipelines where data volume, noise or sparsity breaks standard approaches, and you investigate why and how to fix it.
• Evaluation methods. Building a way to measure model behaviour (for example, factual accuracy in a narrow domain) where no reliable method exists for your case.

Work that usually doesn't:

• Calling a hosted model API to add a chatbot or summary feature.
• Prompt tweaking by trial and error without hypotheses, controlled tests or recorded results.
• A standard fine-tuning run using documented recipes that worked as expected.
• Wiring up a retrieval-augmented generation stack from tutorials and off-the-shelf components.

The line is not about how sophisticated the tools are. A structured investigation into why a fine-tuned model fails on a class of inputs, with logged experiments, can qualify. A large custom model built by following a known recipe may not.

What SR&ED work do SaaS companies typically have?

SaaS claims usually come from scaling, performance and data problems rather than from product features. The business model doesn't matter; the work does.

• Possible: a multi-tenant system where isolation, cost and query latency can't all be met with documented patterns, and your team tested several designs to understand why.
• Possible: real-time sync or offline-first conflict resolution where known algorithms break under your data model.
• Unlikely: adding replicas, caching or autoscaling along vendor-recommended lines; standard Kubernetes or database tuning; SOC 2 or compliance work.

Three SR&ED project examples

Fictional examples. These companies and projects are made up for illustration. They are not real companies, claims or CRA decisions.

Likely qualifies: "Tidewater Analytics" streaming deduplication

Tidewater needed to deduplicate 2 million events per second with under 100 ms delay and bounded memory. Published probabilistic structures either used too much memory or produced false-positive rates the product couldn't accept. The team tested three hypotheses, rejected two with benchmark data, and characterized why a hybrid approach held the error rate.

Why: a specific technical unknown, known methods shown to fall short, recorded experiments, and new knowledge, including from the failures.

Borderline: "Maplecrest Health" clinical note summarizer

Maplecrest fine-tuned an open model to summarize clinical notes. Most work followed documented methods. But the team found the model dropped medication dosages in long notes, and ran a logged series of experiments on chunking and training data to understand and reduce the failure rate.

Why: the overall project is routine, but the dosage-omission investigation may be eligible if the records show genuine uncertainty and systematic testing. Only that part would be claimed.

Doesn't qualify: "Birchline Commerce" AI support assistant

Birchline added a support assistant built on a hosted model API, with a retrieval layer from a vendor tutorial. The team spent weeks refining prompts and fixing integration bugs before launch.

Why: it was hard work, but a competent developer could achieve it with available knowledge. There was no technological uncertainty, only implementation effort.

What evidence does your development workflow already produce?

Most of it, if you keep it. The CRA's get ready to claim page recommends being proactive with records, and Guide T4088 lists "design, system architecture, and source code" for software, along with test data, progress reports, meeting minutes and time sheets. In a modern team, that maps to:

• Commits and pull requests: dated, attributed, and showing what was tried. PR descriptions that explain an approach and why it was dropped are valuable.
• Tickets: issues in GitHub, Jira or Linear that state the technical problem, not just the feature.
• Design documents and ADRs: options considered, why known approaches fall short, and the hypothesis chosen.
• Experiment logs and benchmarks: notebooks, experiment-tracking runs, load-test results, with the configuration that produced them.
• Time records: who worked on what, so salary can be allocated to the right project.

Simple habits make this contemporaneous rather than reconstructed:

1. Add a label such as sred-candidate in GitHub, Jira or Linear when a ticket hits a real unknown.
2. Use a short template for those tickets: problem, what's known, hypothesis, test, result.
3. Link PRs and benchmark results to the ticket so the trail is connected.
4. Write a brief note when an approach is abandoned, with the data that killed it.

If you plan major uncertain work in advance, pre-claim approval lets you get the CRA's view on technical eligibility up front using Form T1322.

How does ClearSRED prepare software claims?

We draft from your own records instead of a blank page. With your permission, we read the relevant repositories, tickets and design documents, interview your technical lead, and separate the eligible investigations from routine development. An experienced SR&ED reviewer then checks every project description before you see it. You review, sign and file. We charge a flat fee agreed up front, not a percentage of your refund, and support you if the CRA reviews the claim.

For the filing steps, see how to file an SR&ED claim. To estimate what your work could be worth, try the SR&ED calculator.

1. CRA: Guidelines on the eligibility of work for SR&ED tax incentives
2. CRA: Guide T4088, Guide to Form T661
3. CRA: SR&ED annual program statistics
4. CRA: Get ready to claim SR&ED
5. CRA: SR&ED Filing Requirements Policy