Software and Research and Experimental Development (SR&ED) is one of the more commonly misunderstood tax credits among incorporated IT contractors and consulting firms. The instinct is to look at a hard technical project and assume it qualifies. CRA’s actual test is narrower and has nothing to do with how difficult or novel the work felt to the person doing it.
What SR&ED Actually Requires
SR&ED is a federal tax credit (with matching provincial credits in most provinces) for work that resolves a technological uncertainty through systematic investigation. CRA’s test has three components that all need to be present:
Technological uncertainty. Whether a result can be achieved, or how to achieve it, could not be determined in advance using existing knowledge, standard practice, or generally available techniques known to a competent professional in the field. If an experienced developer could look at the problem and know how to solve it using established methods, there is no technological uncertainty, regardless of how much work the solution actually took.
Systematic investigation. The work follows a structured process: forming a hypothesis about how to resolve the uncertainty, testing it, evaluating the results, and iterating based on what was learned. Ad hoc trial and error without a documented hypothesis and evaluation process does not meet this bar on its own, though real SR&ED work often looks messy in practice and does not need to resemble an academic paper.
Technological advancement. The work needs to advance the underlying technology, capability, or knowledge base beyond what existed before the project, not just deliver a working feature using known techniques applied to a new business context.
CRA: SR&ED eligibility of work in application software
Why Most Client-Billed Development Does Not Qualify
The bulk of IT contractor and consulting firm work is applying known methods and existing technology to a client’s specific business problem: building a web application using established frameworks, integrating APIs, configuring cloud infrastructure, or writing business logic that follows well-understood patterns. That work is valuable, often technically demanding, and completely ordinary from a tax perspective. It is business income earned in the normal course of a consulting engagement, not SR&ED.
The distinction CRA draws is between difficulty and uncertainty. A project can be hard because it requires deep expertise, careful architecture, or extensive testing, and still involve zero technological uncertainty, because a competent professional could have predicted the approach and outcome in advance. SR&ED is reserved for the narrower case where the outcome or the method to achieve it genuinely could not be known ahead of time.
Where Qualifying Work Tends to Show Up
Within a larger client engagement, a specific sub-problem can sometimes meet the SR&ED test even when the surrounding project does not. Examples that come up in IT consulting work include: developing a novel algorithm or data structure where existing published methods do not solve the specific performance or accuracy constraint, building custom machine learning model architecture or training methodology where the outcome was genuinely uncertain (as distinct from fine-tuning or calling an existing model, which does not qualify), solving a scaling or performance problem where standard architecture patterns are known not to work and a new approach has to be developed and tested, and integrating incompatible systems where the integration method itself required experimentation because no established approach existed for the specific combination.
In each case, the qualifying activity is the narrow technical uncertainty, not the client deliverable surrounding it. A firm building a full application for a client might have ten percent of the work meet the SR&ED bar and ninety percent be ordinary development. Claims should be scoped to that narrower slice, not the whole engagement.
AI Tools Do Not Change the Analysis
Using an existing large language model, API, or AI coding assistant as part of a build is applying existing technology. It does not create SR&ED eligibility on its own, no matter how new the tool is or how much it changes the contractor’s workflow. The same test applies: is there a technological uncertainty in how the system itself is built, trained, or evaluated, separate from the fact that AI is involved.
Work that can meet the bar in an AI context includes developing novel training methodology, architecture, or evaluation approaches where the outcome was genuinely uncertain in advance. Work that generally does not qualify includes prompt engineering, fine-tuning an existing model using documented techniques, building application features on top of an API, or using AI coding tools to write code faster. The presence of AI in a project’s marketing description has no bearing on its SR&ED eligibility.
Who Can Claim When Work Is Billed to a Client
Contract structure matters for SR&ED in a way it does not for most other tax questions. If a client contracts an IT consulting firm to perform work and retains ownership of the intellectual property, directs the technological approach, and bears the financial risk of the project’s success, the client may be the party entitled to claim SR&ED for that work rather than the contractor’s corporation, even though the contractor’s corporation performed the technical work.
Whether the performing firm or the contracting client can claim depends on the specific terms of the agreement: who owns the resulting IP, who bears the risk if the technology does not work, and who directs the technical approach versus simply receiving a deliverable. A firm doing genuinely eligible technical work under a standard client services agreement should review the contract terms before assuming it is entitled to claim the credit for that work.
Documentation Burden
SR&ED claims are reviewed more heavily than most credits, and the documentation standard is specific: records created contemporaneously, during the work, not reconstructed near the T2 filing deadline. CRA expects to see the uncertainty identified before work started, the approaches or hypotheses tested, why standard methods were insufficient or failed, and the actual results including unsuccessful attempts.
Practical sources of contemporaneous evidence include version control commit history showing iterative approaches and abandoned branches, internal design documents or technical notes written during the project rather than after, time tracking that separates qualifying technical work from ordinary feature delivery on the same engagement, and meeting notes or decision logs discussing why a particular technical path was chosen or rejected.
A claim built entirely from memory during tax season, without contemporaneous project records, is the most common reason CRA reduces or denies an SR&ED claim on review. The credit’s value depends as much on the documentation trail as on the underlying technical merit of the work.
Scoping a Claim Before Committing to It
For a small IT consulting firm, the SR&ED application and review process is a meaningful time commitment relative to the credit amount for a modest claim. Before pursuing a claim, it is worth scoping whether genuinely qualifying uncertainty exists separate from ordinary client-billed delivery, whether contemporaneous documentation already exists or can realistically be assembled, who is entitled to claim under the relevant client contracts, and whether the expected credit justifies the preparation and potential review effort.
This is a determination best made with a CPA experienced in SR&ED claims before time is invested in an application, since a claim built on an overstated eligibility assessment invites a CRA review with a limited or negative return relative to the effort spent defending it.