Key takeaway: SR&ED for AI startups depends on the same two-part CRA test every other SR&ED claim depends on: technological uncertainty, attacked through systematic investigation. Building a product on top of a foundation model's API is usually routine engineering. Designing and testing a novel architecture where you genuinely didn't know if it would work is a different question entirely. Software already takes 42.6% of all SR&ED credits allowed in a given year, the largest share of any field. The AI label on your company changes none of the rules. What you actually did to the model is what decides your claim.
Every AI startup thinks it qualifies for SR&ED because, well, it's AI. Most of the pitch decks say "advanced machine learning" somewhere on slide four. A CRA reviewer doesn't care about that phrase, and it can work against you if the claim never shows what was actually uncertain.
This post walks through where SR&ED eligibility actually lands for a company building on machine learning: what kind of ML work clears the CRA's bar, what looks like R&D but isn't, how contractors and pre-trained models change the math, and the mistakes that turn a real claim into a weak one.
Does SR&ED cover AI and machine learning work
Yes, machine learning work can qualify for SR&ED, but "we use AI" is not the test. The test is the same one every SR&ED claim has to clear: was there a technological uncertainty that couldn't be resolved with standard practice, and did you attack it through systematic investigation rather than trial and error dressed up as a process.
Per the CRA's own eligibility guidance, the two requirements are the "why" (advancement of scientific or technological knowledge, in the face of uncertainty that existing knowledge or standard practice can't resolve) and the "how" (a systematic investigation carried out by experiment or analysis). Computer programming and mathematical analysis are two of the eight categories of support work the CRA explicitly recognizes, alongside engineering, design, operations research, data collection, testing, and psychological research. None of that language mentions machine learning by name, because it doesn't need to. The test applies to your model training the same way it applies to a compiler team or a database engine.
Where the line actually falls
The line isn't "AI vs. not AI." It's whether the behavior of what you built was knowable in advance.
Calling a foundation model's API and building a product around the response is, from the CRA's perspective, standard engineering: you're integrating a known tool the same way you'd integrate a payments processor. The uncertainty, if there is any, is in your product decisions, not in the technology. That's a real business, and it might be a good one, but it's not what the program funds.
Now change the scenario. You're fine-tuning a model on a domain-specific dataset and the published techniques don't hold, so you have to design and test a new training approach, and you genuinely don't know going in whether it'll converge to something usable. You're building an inference pipeline that has to hit a latency target no documented architecture achieves at your data volume, and you run a series of structured experiments to find out if it's even possible. Or you're attempting a novel approach to a known limitation, maybe cost-per-inference at scale, where the standard playbook has been tried on your data and simply doesn't work. Each of those cases has a real chance of failure and a systematic way of testing it. That's the shape of eligible work, applied to ML instead of anything else.
This distinction, and most of the ML-specific examples in this post, is our read on how the general test applies to machine learning, not a CRA-published ML rule; there isn't one. The CRA doesn't publish an "AI eligibility bulletin." It publishes a technology-neutral test and expects you to apply it honestly to whatever you built.
What usually doesn't qualify
Most of what an AI startup does day to day is still just software engineering, and most software engineering isn't SR&ED, model or no model. Here too, this is our application of the general test rather than a CRA ruling written for machine learning specifically.
Prompt engineering against a third-party model, without any experimentation on the model itself, is a UX and product problem, not a technological one. Deploying a well-documented fine-tuning recipe from a paper or the model provider's own guide, and having it work about as expected, is applying a known technique with no unresolved uncertainty behind it. Standing up training infrastructure, CI for models, or monitoring dashboards is a form of routine testing once the underlying pattern is established, even when the tooling is new to your team.
That doesn't make the work worthless. It makes it not-SR&ED. A company can be doing genuinely hard, valuable engineering that still fails the "why" half of the test because nothing about it was technologically uncertain in the CRA's sense, just difficult and time-consuming. Hard and uncertain are not the same thing, and mixing them up is the single most common way an AI startup overclaims.
Where the uncertainty actually shows up
If you want a fast filter, ask whether a senior engineer at a comparable company could have told you the outcome before you ran the experiment. If yes, it's probably not SR&ED, however novel the tooling feels to your own team.
Genuine ML uncertainty tends to cluster around a few recurring shapes: architecture choices where no published approach has been validated at your scale or your data distribution; training stability problems that standard hyperparameter tuning doesn't fix; accuracy or latency targets that push past what documented techniques achieve, forcing you to try and discard multiple approaches; and data problems, like extreme class imbalance or noisy labels, where the standard mitigation techniques don't hold up and you have to develop and test your own. In every one of those cases, the giveaway isn't the word "model." It's a documented trail of things you tried that didn't work, why they didn't, and what you tried next. Failure counts as evidence, not disqualification — the CRA's own guidance is explicit that a project doesn't need to succeed to qualify.
Two AI startups, two different claims
Picture two companies that would both describe themselves as "AI startups" on a pitch deck, doing genuinely different work underneath.
Company A builds a customer-support product. It sends prompts to a third-party model's API, wraps the responses in a clean interface, and routes escalations to a human. The engineering is real and the product might be excellent, but nothing about the model's behavior was uncertain to the team building it; the provider's documentation describes exactly how the API responds to a given input. Company A's SR&ED claim, if it files one at all, is probably thin, because the "why" half of the test, a genuine technological uncertainty, doesn't have much to point to.
Company B builds a fraud-detection system for a niche transaction type nobody's published a model for. Standard architectures either miss too many cases or flag too many false positives at their data volume, and the team runs a dozen structured experiments across three architecture families before landing on something that works within their latency budget. Half the experiments failed outright. That failure record, tied to a documented hypothesis for each attempt, is exactly what makes Company B's claim strong: it shows uncertainty that existed and a systematic process for resolving it, not a lucky guess that happened to work on the first try.
Neither company is more of an "AI company" than the other by any normal definition. Only one of them did work that clears the SR&ED bar, and the difference has nothing to do with how advanced the marketing sounds.
Where contractors and outside researchers fit
If you pay an outside ML researcher or a specialized shop to do the experimental work for you, only 80% of that spend enters your qualified expenditure pool, not the full invoice. This has been the rule since 2012, and it applies to arm's-length contract SR&ED the same way whether the contractor is building a database or training a model.
Whether that 80% rule even applies depends on the same substance test any contract goes through. Did the contract require specific experimental work, as opposed to just labour you directed? Who carried the cost risk if the approach didn't pan out? A fixed-price engagement to "build an ML feature" with no defined experimental scope is a weaker fact pattern than a contract that spells out the uncertainty being investigated, and IP ownership is one more signal worth getting right in writing. AI startups that outsource model research to a specialized lab should get that scoping right in the contract itself, not reconstruct it after the fact when the claim gets written.
The overhead question
Salaries for the ML engineers running the experiments are the core of most AI startups' claims, and the CRA's proxy method adds an overhead allowance on top of them without requiring you to track every individual expense. The prescribed proxy amount has been 55% of your SR&ED salary base since 2014, meant to approximate overhead like admin support, rather than making you itemize every server bill and every Slack subscription separately.
That 55% is not free money for GPU compute. How a specific training run's compute spend gets categorized, expensed outright, treated as a capital cost, folded into overhead, is a real question with real dollars attached, and it's not one we're aware of a single published CRA rule settling for every case. If your training runs are a meaningful line item, treat that categorization as a question for whoever prepares your claim, not something to guess at or assume the proxy method already covers.
What ML teams get wrong about documentation
The most common failure mode isn't ineligible work. It's eligible work with no evidence trail. The team's actual process lives in notebooks, Slack threads, and a training run's logs, and nobody was ever asked to preserve any of it for a tax claim.
An experiment log that just says "tried v3, didn't work, moved to v4" is a start, but it doesn't show what the hypothesis was, why the failure was surprising given the current state of the technology, or what specifically changed between v3 and v4. A CRA reviewer isn't a machine learning engineer by default; they're reading your narrative to understand whether real uncertainty existed and whether you investigated it systematically. If your team already documents this well internally, for their own model cards and postmortems, most of the raw material for a strong claim already exists. It just needs to be captured while it's happening and translated into the CRA's language, not rebuilt eighteen months later from memory and half-deleted branches.
Who should think twice before claiming
Skip this, or claim carefully, if your AI work is entirely prompt-and-wrapper: a thin product layer over an unmodified third-party model, with no model training, fine-tuning, or architectural experimentation of your own. The same goes if your team's honest answer to "what was uncertain here" is "we weren't sure which vendor to pick" or "we weren't sure users would like it." Those are real product risks. They aren't technological uncertainty.
Plenty of teams get it backwards, too, assuming they don't qualify because they're "just using AI tools, not building AI." If your engineers are up against an accuracy or latency problem with no documented answer and they're running real experiments to solve it, that's the kind of experimental development the program is built for, whatever you call it internally.
What SR&ED for AI startups is actually worth
The rates don't change because your R&D happens to be machine learning. A Canadian-controlled private corporation earns the enhanced 35% refundable rate on up to $6 million of qualifying expenditures a year, for tax years beginning after December 15, 2024, with the basic 15% rate applying beyond that. At the enhanced rate, that's as much as $2.1 million a year. Credits earned on current expenditures like salaries at the 35% rate are 100% refundable up to the limit for most CCPCs, cash even if you owe zero tax, though excluded corporations get a 40% refund on that same spend instead.
The clock runs the same way too: a corporation's SR&ED reporting deadline is 18 months after its fiscal year end, and there's no extension process. An AI startup mid-fundraise, where the technical team is heads-down on the next model iteration, is exactly the kind of company that lets that date sneak up. The eligibility question doesn't get easier by waiting; the documentation only gets harder to reconstruct.
This is the part of the job that doesn't care whether your R&D is a neural network or a database index: continuous documentation, captured from the tools your team already uses, reviewed by a qualified independent SR&ED expert before anything is filed. AI automation on our side handles the collecting; a named human still stands behind what goes in front of the CRA. It doesn't decide whether your model work qualifies, that's still the two-part test, but it means the evidence exists when you need it instead of getting rebuilt from six-month-old commit messages.
Frequently asked questions
Does using AI tools in my company automatically qualify for SR&ED? No. Using a third-party AI tool or API is adopting existing technology, not advancing it. The CRA's eligibility test looks for genuine technological uncertainty resolved through systematic investigation, not for the presence of machine learning in your product.
Is training or fine-tuning a model eligible SR&ED work? It can be, if there's real uncertainty about whether your approach will work and you investigate it systematically. Applying a well-documented fine-tuning recipe that behaves as expected is routine practice. Designing and testing an approach because the documented methods don't hold for your data or scale is a different situation.
Do failed experiments still count for SR&ED? Yes. The CRA's own eligibility guidance states that a project doesn't need to succeed to qualify. A well-documented failed approach is evidence of genuine uncertainty, not a reason to exclude the work.
What share of SR&ED credits actually goes to software and AI-adjacent work? Software development took 42.6% of all SR&ED credits allowed in the most recent CRA fiscal year, the largest share of any field. Machine learning work claimed as software or engineering falls inside that same category; the CRA doesn't track "AI" as a separate line item.
Do I need to be a research lab to claim SR&ED for ML work? No. The two-part test applies the same way to a two-person startup fine-tuning a model as it does to a large R&D team, and failure to succeed doesn't disqualify a project. What matters is whether the work involved genuine uncertainty, investigated systematically, not the size of the team or the word "lab" anywhere in your pitch.
Does outsourcing model training to a contractor change what I can claim? Yes, if the contractor is arm's length. Only 80% of that contract payment enters your qualified expenditure pool, and whether it qualifies as a contract payment at all depends on the substance of the agreement, not what the invoice says.
AI doesn't get its own SR&ED rulebook. It gets the same two-part test everything else does, applied honestly to what your team actually did to the model, not to what the pitch deck calls it.
See what your AI or ML work could be worth — estimate your refund or check your eligibility.