AI Wrote the Code. Who Gets the Tax Credit?
Your AI Strategy Is Shrinking Your Tax Credit (Maybe)
Your AI Strategy Is Shrinking Your Tax Credit (Maybe)
Two SR&ED consultants look at the same developer, using the same AI tool, writing the same code. One says it qualifies for R&D tax credits. The other says it doesn't.
Leyton, one of Canada's largest SR&ED consulting firms, published a clear position: "The CRA will not recognize the act of calling an API or engineering prompts as SR&ED-eligible work, as that activity is considered routine implementation." Prompting an AI is like calling an API; the uncertainty was resolved by Anthropic or OpenAI, not by the developer.
GrowWise Partners, another major SR&ED consultancy, says the opposite: "AI does not disqualify work, but claimants must show that human-led experimentation is still present." Same developer. Same tool. Same output. Different framing, different documentation, different outcome.
The gap between "we used AI as a research tool" and "AI did our work for us" is less technical and more about the documentation that supports the claim. And that distinction is worth up to $2.1 million in refundable tax credits in Canada; six figures or more in the US. This is not an accounting footnote.
Right now, Agentic coding and AI-assisted development are in a regulatory vacuum. No government has issued guidance; no court has ruled. The CRA's five-question eligibility test was written for human researchers; the IRS four-part test never contemplated AI as the primary code author. The entire field is governed by consultant interpretation of statutes that predate GitHub Copilot by decades.
If your company claims SR&ED credits in Canada or R&D tax credits in the US -- and if your engineering team uses AI coding tools -- your tax position depends on how well you can document your work. The "(Maybe)" in the subtitle is genuine; this might work out fine. But the regulatory vacuum means nobody can tell you that with certainty, and is the companies that are left holding the bag.
No one is sure
R&D tax credits live in the CFO's domain -- or they used to. The engineering org's practices now determine whether the credit survives an audit, and the gap between a defensible claim and a rejected one can be six figures. Tax mechanics are not why you took the CTO job, but this is your problem whether you want it or not.
Canada's 2025 federal budget doubled the SR&ED expenditure limit from $3 million to $6 million, expanded eligible entities beyond CCPCs, and restored capital expenditure eligibility for the first time since 2014. The maximum refundable investment tax credit jumped to $2.1 million. The program has never been more generous.
Starting April 2026, the CRA will launch an AI-enhanced review process to streamline claim reviews, alongside a new elective pre-claim approval process. And while the CRA is using AI to review claims, nobody at the CRA has published a single word of guidance on how AI coding tools affect eligibility.
South of the border, the story is pretty much the same. The One Big Beautiful Bill Act restored immediate R&D expensing in July 2025, reversing the TCJA's punishing five-year capitalization regime that had forced companies to amortize domestic research costs over five years. The new Form 6765 Section G becomes mandatory for 2026 filings -- business-component-level disclosure for anyone claiming more than $1.5 million in qualified research expenses, reporting on up to fifty business components. More granular disclosure than the IRS has ever required. Meanwhile, the IRS is deploying its own AI tools: a Line Anomaly Recommender for audit selection and Agentforce across the Office of Chief Counsel.
Robert Kovacev, a tax litigator who published an analysis on SSRN, observed that "nothing in the statute or regulations states that activities must be performed by humans." He's right -- the statute is silent. But silence cuts both ways; it means the answer depends entirely on how you frame and document the work.
Ottawa doubled the SR&ED expenditure limit in the same budget year that ISED launched new AI adoption grants. Washington restored R&D expensing three months after the White House issued executive orders accelerating AI deployment. Nobody in either capital connected the dots; companies are filing R&D claims based on whatever their consultant tells them, and the consultants -- as we've seen -- don't agree; which makes things more a mess, and as always is our job as CTOs to figure out how to navigate this.
Who eliminated the uncertainty -- the developer or the AI? That's the question neither statute answers. The CRA's five-question test requires "systematic investigation" by means of "experiment or analysis"; the IRS four-part test requires a "process of experimentation" to "eliminate uncertainty." Both assume human researchers. Neither says what happens when AI does the generating and the human does the evaluating.
The Productivity Paradox
R&D tax credits are calculated primarily on employee wages allocated to qualifying research. If AI reduces the time developers spend on qualifying activities, the wage base shrinks. The credit shrinks with it; this is mechanical, not interpretive. It follows directly from how the math works.
The implications are counterintuitive. Your AI strategy might be making your engineers more productive while simultaneously making your company's tax position worse.
Walk through the Canadian numbers. A developer earning $150,000 per year who previously allocated 50% of their time to SR&ED work generated $75,000 in eligible salary, plus $41,250 in proxy overhead -- $116,250 in qualified expenditure. At the enhanced 35% rate, that produced roughly $40,700 in investment tax credits per developer. Compress that developer's SR&ED-eligible time to 20% with AI tools -- nothing else changes, same salary, same project, same research outcomes -- and the ITC drops to approximately $16,300. Sixty percent gone.
The US math is different in structure but identical in direction. A ten-person team spending 60% of time on qualifying research might see that drop to 30% after AI adoption; the wage-based credit cuts roughly in half.
But the US has an additional cliff. Under Treasury Reg. 1.41-2, if 80% or more of an employee's services constitute qualified research, 100% of their wages count as qualified research expenses. Drop below 80%, and only the actual proportion counts. Pre-AI, a developer at 85% qualifying research had 100% of wages in the QRE pool. Post-AI, that same developer at 60% qualifying research has only 60% of wages in the pool.
The 7th Circuit made this concrete in *Little Sandy Coal* (2023): the taxpayer must demonstrate a "principled way to determine what portion of employee activities constituted elements of a process of experimentation." If you can't show that principled allocation, you lose.
The paradox is this: AI may simultaneously expand the universe of qualifying activities -- more experimentation, more alternatives evaluated, more systematic investigation -- while compressing the economic value of the credit through fewer developer-hours and lower wage QREs. Companies might qualify for credits more easily while claiming smaller dollar amounts.
Scale this across a team. If three AI-augmented developers replace the output of ten, the wage base drops 70% -- even if every minute of their remaining time qualifies. The productivity gain that your CEO celebrates is the same productivity gain that mechanically erodes your R&D credit. The only defense is reframing what counts as qualifying activity; that reframing lives or dies in documentation.
The Documentation Is the R&D
Before AI, tickets, PRs, and comments documented the work, any additional documentation was a bonus; meaning we could get away with using the output as evidence of the work. With AI in the mix, we need to document the work in a way that supports the claim and at higher levels of detail.
When AI generates most of the code, the code is no longer evidence of human-led investigation. Traditional signals -- commit history, code comments, design docs -- may be thinner or absent entirely. A developer who generates fifty lines of code in a single AI prompt produces a different artifact than a developer who wrote those fifty lines over three days of iterative experimentation. The output might be identical but how we got there is not.
Documentation must now prove something the code used to prove implicitly: that a human drove the investigation and iteration process. That a human identified the uncertainty, designed the experiment, evaluated the results, and advanced knowledge. With agentic coding, documentation is no longer a record of the R&D. It is the R&D -- it's the only surviving evidence that qualifying work occurred.
Five elements make this concrete.
The uncertainty. What didn't you know? What couldn't be achieved through standard practice? Document this before prompting AI -- not after. The uncertainty must exist in the developer's understanding, not in the model's training data.
The hypothesis. Record which approach the developer chose to test and why they picked it over alternatives. The reasoning belongs to the human, not the model. If nobody can articulate why this approach rather than another, there's no hypothesis -- there's a guess.
The experiment. Save the prompts, the iterations, the evaluation criteria. Where AI interaction logs show a cycle -- hypothesis, generation, evaluation, iteration -- those logs are evidence. This is the one area where agentic coding actually helps your claim; the tool produces a richer paper trail than manual development ever did.
The evaluation. A developer tries three approaches and two of them fail. Those failures are strong evidence; Platform Calgary notes that failed experiments in AI development often represent the strongest SR&ED evidence. Document what was rejected and why it didn't hold up.
The advancement. If the only thing your team gained was working code, that's a product -- not a research outcome. The advancement is the new knowledge: what works under these conditions, what doesn't, and why. That knowledge belongs to the organization, not the model.
In practice, this means your developers need to write something down before they start prompting. Not necessarily a formal document but a Jira ticket, a Slack message to themselves, a comment in the PR. What's the uncertainty? What are they about to try? After the AI generates output, they need to record what they rejected and why. GrowWise recommends preparing "a summary of AI usage explaining how it enhanced, but did not replace, systematic investigation." That summary is what ties your engineering workflow to your tax credit; and it should take five minutes to write if you do it in the moment.
If we are smart we can tweak our developer process to create enough evidence and documentation to support the claim. For example:
Make sure our git history shows iteration.
PR descriptions capture what was tried and rejected.
Jira or Linear tickets can document the uncertainty if your developers write them that way.
More formal documents like architecture decision records, AI interaction logs, and developer journals can capture the experiment and evaluation.
Heck even a developer's Slack thread where they talk through an approach -- all of it counts. You have the tooling; what you probably don't have is anyone treating this as an engineering practice instead of a tax compliance exercise.
The Dominant Actor
For all their disagreements on specifics, McGuire Sponsel, KBKG, Warren Averett, and Bloomberg Tax converge on one thing: the developer has to be the dominant actor. The person who drove the investigation, not someone who showed up for the review. Where exactly that line sits depends on who you ask.
Two scenarios — identical in every way except how the work was framed.
Eligible: A developer hits a problem they can't solve through standard practice -- say, a concurrency issue under specific load conditions that no existing pattern handles cleanly. They hypothesize a few approaches, use AI to generate implementations faster than they could write them, then test each one against their criteria. Three approaches fail. They document why, adjust, and eventually land on something that holds. The investigation was theirs; AI just wrote the code.
Not eligible: A developer opens Claude Code, types "build a feature that handles multi-currency refunds," and gets back something that works. They tweak the formatting, maybe rename a variable, and push it to staging. Done in twenty minutes. The problem is that nobody documented an uncertainty before that prompt -- because there wasn't one, or at least none that the developer articulated. No hypothesis, no evaluation criteria, no record of what got rejected. Leyton's analysis says the CRA will treat that as routine implementation, and they're probably right.
So what separates those two scenarios? Not the code -- the code might be identical. What separates them is whether anyone wrote down why they were building it that way.
Bloomberg Tax offers a useful reframing: "the bug is the proof that the initial hypothesis was false, and the debugging and testing process then becomes the new, qualified experiment." AI-assisted development may involve more process of experimentation, not less -- more alternatives generated, more systematic evaluation, more documented iteration. The key is making that visible. If the experimentation happened but nobody recorded it.
To survive an audit, your documentation needs to tell that story. Problem identification, experiment design, evaluation, iteration -- those belong to the developer. The AI generated code faster; it didn't investigate anything. That distinction holds whether you're answering the CRA's five questions or the IRS four-part test.
If your documentation tells that story -- and tells it contemporaneously, not retroactively -- the credit is defensible. If your documentation is thin, the same work becomes indistinguishable from routine implementation.
Now final disclaimer: I'm not a tax attorney; just a CTO that has done his fair share of R&D tax credit claims and has seen the pitfalls. Talk to your SR&ED consultant or R&D credit advisor -- but talk to them with the right questions, which hopefully this article provides.
Key Takeaways
When was the last time you talked to your SR&ED consultant or R&D credit advisor about how your team uses AI tools? If the answer is "never," that conversation is overdue.
Can your engineering team demonstrate -- with documentation created at the time of the work, not assembled retroactively -- that developers drove the systematic investigation on your last R&D project? Not that they were present. That they drove it.
Do you know your developers' current time allocation to qualifying activities? Has it changed since AI tool adoption? If you're in the US, are you sure you're still above the 80% threshold?
Think about your last sprint. A developer prompted Claude Code, iterated until it worked, and shipped. Six months later, an auditor asks them to prove that was systematic investigation. They won't remember the prompts. They won't remember what they rejected. The documentation either captured it in real time or it didn't -- and "it worked" is not evidence of experimentation.