What qualifies for SR&ED in software development?

What qualifies for SR&ED in software development is not a special category of software work. It is ordinary experimental development that happens to be written in code, and CRA judges it against the same two requirements it applies to a vaccine lab or a greenhouse: the work must be conducted for the purpose of achieving a technological advancement, and it must be a systematic investigation carried out by experiment or analysis (CRA, what work is eligible).

The second thing worth knowing is stranger, and most articles on this topic quietly skip it. There is no CRA software rulebook. No software-specific policy appears on CRA's SR&ED policies and guidelines index, every worked example CRA publishes runs on vaccines and greenhouses, and the closest thing to a software-specific hook is the field-of-science code list in guide T4088, where software engineering and technology sits at 2.02.09, computer sciences at 1.02.01, and hardware development at 2.02.08. So claiming for software means translating general rules onto your own work, and that translation is where the money is won and lost.

At a glance

• Both requirements are mandatory, and the work must be done in Canada: a technological advancement (the "Why") and a systematic investigation by experiment or analysis (the "How") (CRA, updated April 1, 2026).
• The 2021 guidelines replaced the old "five questions" with those two requirements. The definition in the Act did not change (CRA, a brief history, updated August 27, 2025).
• New features are not an advancement by themselves (T4088, updated February 18, 2026).
• Wiring together well-known components can create "system uncertainty," a form of technological uncertainty (CRA glossary, updated May 22, 2026).
• Narrative limits on the T661: Line 242 gets 350 words, Line 244 gets 700, Line 246 gets 350 (T4088).

The test CRA actually applies to software

Software gets no exemption and no extra hurdle. The work must be done in Canada and satisfy both requirements, and uncertainty is what starts the clock: "The recognition that scientific or technological uncertainty exists marks the starting point for the SR&ED work, while the advancement is the targeted outcome of the work" (Guidelines on the eligibility of work, dated August 13, 2021).

Technological uncertainty has a specific meaning here. It is when "whether a given result or objective can be achieved, or how to achieve it, is unknown or uncertain due to an insufficiency of technological knowledge" (CRA glossary). Not "this was hard." The knowledge to do it did not exist in a form you could reach.

Shipping a feature is not an advancement

This is the correction most founders need, and CRA states it about as directly as a tax agency ever states anything: "Achieving the novelty, innovation, uniqueness, feature enhancement, or increased functionality of the product or process may not in itself demonstrate scientific or technological advancement" (T4088). The same guidance adds that "it is the advancement in the underlying science or technology that is important, not how the work advanced your business or business practices."

Your product can be new, genuinely better, and commercially valuable while producing no advancement at all. The question is whether the technological knowledge base moved, not whether the roadmap did.

Where most real software claims live

Almost no startup invents technology from first principles. You assemble known parts: a queue, a database, a model someone else trained, three APIs with their own opinions about latency. Founders assume this disqualifies them. CRA's glossary describes their situation precisely.

"System uncertainty is a form of technological uncertainty that can arise from or during the integration of technologies, the components of which are generally well known. This is due to unpredictable interactions between the individual components or sub-systems" (CRA glossary).

That is the most defensible claim most software teams have. The guidelines reach the same place from another angle, noting that uncertainty can arise "when there is a need to take existing technology and apply it in a new environment or context." CRA also lists signals that the knowledge base was insufficient, and the ones that show up in software are "too many variables or unknowns," "parameters or conditions are outside of the normal operating range," and "there are interlocking constraints."

The knowledge base is measured against you rather than the industry. It is "the combined knowledge of the resources within the business and those sources that are reasonably available publicly," and CRA says it "may vary from business to business." A four-person team can face real uncertainty on something a larger company would find routine.

What does not qualify, and why "hard for us" is not enough

The counterweight arrives immediately. If the knowledge exists and you can reach it, there is nothing to resolve. CRA is explicit: "Acquiring available knowledge or know-how, for example, through training, on-the-job learning, hiring expert employees or consultants, or by purchasing proprietary knowledge does not meet the requirement of attempting to achieve technological advancement." If the answer was in the documentation, on a forum, or inside a contractor you could have hired, the difficulty was yours rather than technology's.

The word "systematic" traps engineers. Your sprints, code review, CI pipeline and QA are all systematic, and none of them is a systematic investigation. CRA closes that door before you reach it: "it is not enough that work be carried out systematically in order for it to be eligible for SR&ED tax incentives." The bar is a defined problem, a hypothesis, a test by experiment or analysis, and logical conclusions, with evidence kept as you go.

Debugging deserves a flag. The clearest CRA statement on it says work "associated with trouble-shooting, debugging, and fine-tuning when there is no need to resolve technological uncertainties, is not SR&ED work," and that beta site testing to confirm agreed specifications is not either. That language comes from a 2015 policy CRA has since archived, and the current guidelines say nothing about debugging at all. Treat it as direction rather than live rule.

Your SR&ED project is a subset of your product project

You do not claim the quarter. You claim the part of it that chased an advancement. CRA separates the two cleanly: "The purpose of a business project is to achieve commercial success. The purpose of an SR&ED project is to advance scientific knowledge or to achieve a technological advancement," and "all the activities within an SR&ED project must be related to the same advancement" (CRA, group projects, updated April 1, 2026). Knowledge sets those boundaries, not your calendar: a project "ends when new scientific or technological knowledge is gained, whether you were successful in reaching your goal or not."

Computer programming is not stranded outside this. It appears in the Act as support work, eligible when it is "commensurate with the needs, and directly in support of" the experimental development. The code you wrote to run the experiment counts. The code you wrote because it was on the roadmap does not.

Frequently asked questions

What qualifies for SR&ED in software development?

Software work qualifies when it was done in Canada to achieve a technological advancement against a real uncertainty, and was carried out as a systematic investigation with a hypothesis tested by experiment or analysis.

Does building a new feature qualify for SR&ED?

Not on its own. CRA says novelty, feature enhancement, and increased functionality may not in themselves demonstrate a technological advancement. What matters is whether the underlying technological knowledge advanced, not whether your product improved.

Does integrating existing tools or APIs qualify?

It can. CRA recognises "system uncertainty," which arises during the integration of technologies whose components are generally well known, because of unpredictable interactions between them. For most software teams this is the strongest available claim.

Is debugging SR&ED?

Generally no. Archived CRA policy states that troubleshooting, debugging and fine-tuning are not SR&ED where there is no technological uncertainty to resolve. Debugging inside a genuine experiment is a different thing from debugging as maintenance.

Does CRA have a software-specific SR&ED policy?

No. There is no software document on CRA's SR&ED policies and guidelines index, and CRA's published examples are drawn from other fields. You apply the general definition to your own work, which is why the write-up carries so much weight.

The short version

The program was not written with software in mind, and CRA has not gone back to retrofit it. That leaves you doing the translation, and the translation has a shape: find the point where available knowledge ran out, show the hypotheses you tested against it, and keep the evidence that it happened. CRA names your own artifacts as proof, listing "design, system architecture, and source code (software development)" among its examples of supporting documentation (CRA, updated December 5, 2025), so your repository already holds most of what a reviewer wants. Building the claim from that record rather than from memory in month eleven is the whole game, and it is what SREDlog was built to do. The reviewer will not be impressed by your product. They will ask what you did not know.