SR&ED eligibility for software development: criteria and examples

Your technical team spends weeks solving a problem with no obvious solution. That situation may raise a question about SR&ED eligibility for software development, even if no one on the team has considered the tax credit yet.

The Scientific Research and Experimental Development (SR&ED) program is Canada’s main federal research and development tax incentive. Software projects can qualify, but only when the work meets the program’s technical requirements.

The challenge is distinguishing routine implementation from a genuine attempt to generate new technological knowledge. A long, expensive or complex project is not automatically eligible.

Understanding SR&ED eligibility for software development

According to the Canada Revenue Agency’s current SR&ED eligibility criteria, the work must be conducted in Canada and meet two requirements.

1. Why is the work being carried out?

The work must be conducted for the advancement of scientific knowledge or to achieve a technological advancement. An advancement is the generation or discovery of knowledge that moves the understanding of science or technology forward.

In software, new knowledge is needed when the knowledge available within the business and from sources reasonably accessible to the public cannot establish whether a result can be achieved or how to achieve it. This is technological uncertainty.

A business challenge, tight deadline, lack of experience on the team or the overall complexity of a product is not enough. The limitation must exist in the available technological knowledge base, not only in the claimant’s resources.

2. How is the work carried out?

The work must be a systematic investigation or search conducted through experiment or analysis. The CRA describes an approach that includes:

1. defining a problem;
2. advancing a hypothesis toward resolving it;
3. planning and testing the hypothesis through experiment or analysis;
4. developing logical conclusions based on the results.

Following a structured development method or Agile framework is not sufficient on its own. The tests must relate to a technological hypothesis and show what knowledge was gained, whether or not the commercial objective was achieved.

Examples of potentially eligible software projects

Some scenarios may contain experimental development when they go beyond applying known practices.

• Designing an architecture capable of handling data volumes or loads beyond the demonstrated limits of available solutions.
• Developing a processing, optimization or security algorithm when known approaches cannot meet the required technical characteristics.
• Adapting an artificial intelligence model to limited, noisy or non-standard data through a series of hypotheses and experiments.
• Integrating systems whose unpredictable interactions create system uncertainty and require changes to the underlying technologies.
• Attempting to reduce latency, memory use or error rates beyond what publicly available methods can achieve.

Eligibility depends on the facts in every case. The team must identify the limitation in available technology, state its hypotheses, test approaches and draw conclusions from the results. Calling a product “innovative” does not replace this evidence.

Work that is generally not eligible

Not all software development qualifies, even when it requires substantial time or expertise.

Activity	Typical analysis
Experimental development of a new algorithm to overcome a documented technological limitation	Potentially eligible
Configuring or customizing a standard enterprise resource planning system	Generally not eligible
Integrating existing software using known methods and with no unpredictable interaction	Generally not eligible
Experimenting with an architecture to support a load that available solutions cannot achieve	Potentially eligible
Building a website with an existing content management system	Generally not eligible
Routine debugging, quality control or routine testing	Generally not eligible
Training the team or hiring a specialist to apply existing know-how	Not eligible on its own

A solution that is unknown to your team may still be part of publicly available knowledge or known to a competent professional. In that situation, the work will normally be routine engineering or programming.

Conversely, integrating known technologies can sometimes create system uncertainty when their interactions are unpredictable and the subsystems must be changed to meet the specifications. That conclusion must be supported by the facts and experiments.

Why the analysis differs from manufacturing SR&ED

SR&ED applies across industries, but technological uncertainty does not look the same everywhere. In manufacturing, it may involve a material, mechanical tolerance, physical process or scale-up challenge.

In software development, uncertainty is often found in an architecture, algorithm, system interaction or measurable performance constraint. These decisions are difficult to reconstruct when the team records only delivered features.

Our SR&ED guide for the manufacturing sector illustrates this contrast with examples involving processes and equipment.

CRA pre-claim approval for a planned project

Since April 1, 2026, some businesses have been able to use the CRA’s optional Pre-claim approval process. It allows an organization to request a technical determination before starting work or incurring project costs.

The process is available to Canadian-controlled private corporations, Canadian corporations and Canadian partnerships with annual gross income below $25 million that are in good standing with the CRA. One request may cover up to three projects, and the CRA states that it will issue a determination within eight weeks of a complete application.

An approval can remain valid for up to three years. It does not remove the need to retain supporting evidence, report expenses correctly or satisfy the requirements of the annual claim.

SR&ED and CDAE-IA for the same IT project

A Quebec company may sometimes be affected by both SR&ED and CDAE-IA. The two measures do not assess activities using the same criteria.

SR&ED addresses work undertaken to achieve scientific or technological advancement through a systematic investigation. CDAE-IA instead depends on whether the business, activities and employees meet Quebec’s rules for e-business activities that meaningfully integrate artificial intelligence.

When the same employee or project appears in both analyses, the costs must be carefully allocated. Government assistance must be reported, and the same expenses cannot be treated as though no other assistance had been received. Our SR&ED and CDAE-IA comparison explains the differences and interactions to review.

To have your software project portfolio assessed, speak with a specialist.

Documentation to retain for a software project

Evidence produced while the work is underway helps demonstrate the problem, hypotheses, testing and knowledge gained. Documentation may include:

• technical notes describing the initial limitation and why known approaches were insufficient;
• hypotheses and measurable criteria used to assess each approach;
• test results, benchmarks, logs, performance measurements and prototypes;
• the history of attempts, including failures and the reasons for changing direction;
• dated code commits, pull requests, tickets and architecture decisions;
• time spent by each person on investigative work, separated from routine implementation.

Commits and tickets are useful, but they do not automatically prove eligibility. Their content should make it possible to understand the technological uncertainty and the progression of the investigation.

Lightweight tracking during each sprint is generally more reliable than reconstructing the project months later when preparing Form T661. Our SR&ED documentation guide presents practical ways to structure this evidence.

Assessing software projects before filing

A software project can qualify even when it fails, while a commercially successful product may contain no SR&ED work. The analysis focuses on why and how the work was performed, not the product’s commercial novelty.

Start by isolating the periods when the team could not resolve a limitation with the available knowledge. Then connect each hypothesis to the tests, results and new knowledge obtained. Routine development tasks should remain separate.

To assess your projects and structure the documentation before your next claim, book a consultation with Avinova or review our page about the SR&ED tax credit.

FAQ

Is an artificial intelligence project automatically eligible for SR&ED?

No. Using artificial intelligence does not automatically create technological uncertainty. Applying an existing model or method through known practices is generally routine development. A project may contain SR&ED when the team attempts, through experiment or analysis, to generate new knowledge to overcome a technological limitation that the available knowledge cannot resolve.

Can failed development work be included in an SR&ED claim?

Yes. The success of the product or hypothesis is not an eligibility requirement. An unsuccessful test may generate new knowledge by showing that an approach does not work under the conditions studied. The business must still demonstrate that the work sought an advancement and was carried out through a systematic investigation.

Are Git commits and tickets sufficient documentation?

They are useful evidence when produced as the work progresses, but they may not be sufficient on their own. They should be accompanied by information connecting the technological problem, hypotheses, tests, results and conclusions. Generic task titles such as “fix performance” rarely explain why the work was necessary or what the team learned.

How long does it take to document a software SR&ED project?

The effort depends on the project’s size, but a few structured notes recorded when decisions are made substantially reduce year-end work. The goal is not to produce a lengthy daily report. It is to retain enough contemporaneous evidence to reconstruct the uncertainty, hypotheses, experiments and conclusions.