Does Your AI Transformation Qualify for SR&ED Credits?

A CFO approves a budget to automate order intake. Twelve months later the system is in production, the team is proud of it, and the year-end package goes to the accountant. Somewhere in that conversation the accountant asks whether any of the work was R&D. Nobody’s sure. The engineers who ran the hard experiments have moved on to the next project, the notebooks are half-deleted, and the only record of why the first two approaches failed is a Slack thread from March.

That company may have done qualifying SR&ED (Scientific Research and Experimental Development) work. It’ll now spend weeks trying to prove it, and the claim it files will be weaker than the work deserved.

This pattern is common among Canadian mid-market companies investing in AI and automation. They treat R&D economics as a tax question that shows up after the project. It belongs in the project plan. This article is for CFOs and operations leaders running AI programs who want to know which parts can qualify and how to keep the evidence.

Why do AI programs in operating businesses produce SR&ED-eligible work?

Because turning a messy operating process into a reliable production AI system regularly hits problems nobody has solved before. When the answer isn’t in documentation, published research or a vendor’s playbook, the team starts experimenting. That experimentation is exactly what SR&ED is designed to support.

Most of the SR&ED conversation in Canada targets software companies building products. That framing misses a large group: manufacturers, distributors, insurers, engineering firms and logistics operators putting AI into their own operations. These companies rarely think of themselves as doing R&D.

Yet the obstacles are real. The data is inconsistent in ways no vendor anticipated. The legacy systems were never meant to talk to each other. The decision logic lives in the heads of three senior people and a spreadsheet with 40 tabs.

What does the SR&ED test actually ask?

The Canada Revenue Agency (CRA) evaluates experimental development against three criteria, and all three must be present. The SR&ED eligible activities guide covers them in depth. In short:

Technological uncertainty. A competent practitioner couldn’t have known how to solve the problem using generally available knowledge. “We weren’t sure it would work” isn’t enough. “Standard approaches failed, and nothing published explained why” is.

Systematic investigation. The team worked the problem through hypotheses, experiments and recorded results. Trying things until something sticks doesn’t count.

Technological advancement. The investigation produced new knowledge, even if the answer was that an approach doesn’t work. Failed experiments can qualify.

Applying this to AI work inside an operating business takes judgment. The line isn’t about how hard the work was or how much it cost. It’s about whether the solution was knowable before you started.

Where can AI and automation work qualify?

A few patterns show up again and again when teams build production AI systems on real operational data. Treat each one as illustrative. Whether a specific project qualifies depends on the facts and how well they’re documented.

Model behaviour on messy operational data

Consider a distributor using a language model to extract line items from purchase orders. Thousands of customers send POs as scanned PDFs, emails, spreadsheets and the occasional fax. A standard extraction approach works on clean documents and collapses on the rest: merged cells, handwritten quantities, units that change mid-document, part numbers that match three different SKUs depending on the customer.

If the team baselines the standard approach, records that it fails against a defined accuracy threshold, forms hypotheses about why, and tests alternatives in a structured way, that investigation has the shape of SR&ED. CRA will ask whether the failure mode and its resolution were already described somewhere. For a specific mix of document types and domain rules, they often weren’t.

Integration problems with no known solution

Operating businesses run on systems that were never designed for AI. An ERP from 2009 with no API. A scheduling tool that exports CSVs on a timer. A quoting process built on a homegrown Access database.

Connecting a model to these systems is usually ordinary engineering. Sometimes it isn’t. Say a retrieval layer surfaces contradictory records from two systems of record and the model handles the contradiction unpredictably. That’s behaviour none of the components document on their own, and investigating it can qualify. A 2024 Tax Court decision (DAZZM Inc. v. His Majesty the King) confirmed that integrating known components can create genuine technological uncertainty at the system level. The AI and ML claims guide covers this angle in more detail.

Reliability under real operating constraints

A model that’s accurate 90% of the time is a demo. A model that has to be right on every insurance submission, or has to flag when it isn’t confident, is a production system. Getting from one to the other sometimes means investigating calibration, confidence thresholds or fallback logic where known techniques didn’t hold up on your data distribution. That work can qualify when it follows the systematic pattern.

Tooling built to run the investigation

If the team builds a custom evaluation harness or a simulation of a production workflow because nothing available could test what they needed, that tooling can qualify as support for the investigation. It’s easy to forget because it never ships to anyone.

What typically doesn’t qualify?

Using AI isn’t the same as advancing it, and CRA reviewers draw that line clearly. Rolling out tools, configuring them and iterating on prompts is applying known technology. This side of the line matters just as much, because CRA has been looking hard at AI claims. The 2026 SR&ED changes post explains why that scrutiny has increased.

Work that generally falls outside SR&ED:

• Rolling out off-the-shelf tools. Deploying a vendor copilot, configuring a CRM’s built-in AI features, or turning on document processing in an existing platform.
• Routine configuration and integration. Mapping fields, setting up API connections that work as documented, building standard data pipelines.
• Prompt iteration on its own. Rewording prompts and testing variations to improve output is application of a known tool.
• Standard fine-tuning that works. Using documented methods on your data and getting acceptable results.
• Data entry, labelling and cleanup. Necessary, often expensive, and not experimental development unless the curation method itself required solving an unknown.
• Training, change management and adoption work. Essential to the outcome, and outside the program.
• Deployment, monitoring and maintenance of a system once it works.

A large AI program will contain both kinds of work, often in the same sprint. The qualifying portion might be a few weeks of investigation inside a several-month build. Claim the whole program as R&D and you’ll end up in a review you can’t win. Claim none of it and you leave real money behind.

Why does reconstructing evidence later cost you?

Because the details that make a claim defensible fade within months, and the people who hold them leave. Corporations have 18 months after the end of the tax year to file, so there’s no apparent rush. That gap is where most of the value leaks out.

Memory degrades fast. Engineers remember that an approach failed. They rarely remember the metrics, the configuration, or why they picked the next hypothesis. Those specifics are exactly what a reviewer asks for.

The people move on. In AI programs especially, the person who ran the experiments may be a contractor, a partner’s engineer, or someone who’s since left. Their notebooks leave with them.

Reconstruction is billable time. Someone has to interview the team, dig through commit history and tickets, and rebuild a narrative. Your engineers or an advisor get paid for that time, and the result is a document that was obviously written after the fact.

Reconstructed narratives are weaker. CRA has been increasingly clear about wanting contemporaneous records, meaning documentation created while the work happened. A narrative assembled a year later with vague time estimates is easier to challenge and harder to defend in an SR&ED audit.

Some work never gets claimed. Failed experiments are often the most eligible part of a project and the least likely to be remembered. When nobody wrote them down, they vanish from the claim.

How do you capture SR&ED evidence while the work happens?

Build a few habits into how the AI work runs from day one. You don’t need a heavier process. Most of these habits are the same ones that make AI projects succeed anyway.

Write down the problem before you solve it

When the team hits something that looks genuinely unknown, record it. What were you trying to achieve? What’s the target, in numbers? What does existing knowledge suggest, and why doesn’t it apply here? A short note in the ticket is enough. It becomes the technological uncertainty section of the eventual narrative.

Baseline the standard approach

Before trying anything novel, run the obvious method and record the result. “Standard extraction reached 71% field accuracy against a 98% requirement on our document set” is evidence. “We knew it wouldn’t work” isn’t.

Keep hypotheses and results together

Each experiment gets a line: the hypothesis, what changed, what was measured, what happened, what you concluded. Experiment tracking tools generate most of this automatically. A disciplined ticket history works too.

Separate investigation from implementation

Run the uncertain work as its own stream, with its own tickets or tags. When the investigation resolves and the team moves on to building the production version, that shift should show up in the records. It makes the qualifying hours easy to identify and keeps you from over-claiming.

Log time against the right buckets

Time records set the dollar value of the claim. If people log “AI project, 40 hours,” nobody can separate eligible from non-eligible work later. Two or three time codes per project solve most of this.

Draft the narrative as you go

A rough monthly or quarterly summary of each investigation, written while it’s fresh, beats a polished document written at filing. The technical narratives guide shows what CRA expects in each section.

None of this slows the work down. A team that writes down its hypotheses and measures against a baseline ships better AI systems. The evidence trail is a by-product of running the project well.

How much can an AI program recover through SR&ED?

For Canadian-controlled private corporations (CCPCs), the federal SR&ED investment tax credit is 35% and refundable on qualifying expenditures up to an annual expenditure limit. Recent federal changes raise that limit from $3 million to $6 million. Above the limit, and for non-CCPCs, the rate is 15% and non-refundable. Check with your advisor how the current limit applies to your tax year, since effective dates matter.

Qualifying expenditures include salaries of the people doing the eligible work, with an overhead allowance under the proxy method. If an arm’s-length Canadian partner performs eligible work for you, you can generally include 80% of the eligible portion of what you pay them. Work performed outside Canada doesn’t count. The contractor and outsourced development guide explains the rules, including how to write contracts that support the claim.

That last point matters if you’re working with an outside partner on AI. Who directs the work, where it’s performed and how the contract is structured all affect whether you can claim it. Sort that out before the engagement starts.

What changes for Québec companies?

Québec layers its own refundable R&D tax credits on top of the federal claim, so Québec companies doing eligible work often recover meaningfully more than the federal credit alone. Québec also reworked the CDAE (its e-business tax credit) into a version focused on integrating AI into business processes, for fiscal years beginning after December 31, 2025. It has its own eligibility tests, including a per-employee time threshold, and its own rules on how it interacts with other credits claimed on the same salaries.

Rates and rules for both have shifted in recent Québec budgets. Use this as a reason to raise the question early with your advisor, not as a figure to put in a budget.

Who should file the SR&ED claim for your AI work?

That’s your call. Your in-house finance team, your external accountant or a specialized SR&ED advisor can all file it, and the choice shouldn’t be tied to who builds your AI systems.

Here’s how we handle it. When we run an AI engagement with a Canadian client, evidence capture is part of how the work gets done. Hypotheses, baselines, experiment results and time allocations are recorded as the project moves. At year end, you own that record along with the systems and code. Hand it to whichever accountant or advisor you already trust. If you want software to organize it into CRA-ready documentation, Chrono R&D does that, but nothing about the engagement depends on using it.

We won’t promise that a specific project qualifies. That depends on the facts and on CRA’s review. What we will do is make sure that if qualifying work happens, there’s a clean, contemporaneous record of it.

What should a CFO add to the AI project kickoff?

Three questions. The practical change is small, and it pays off at filing time.

1. Which parts of this work are likely to involve genuine technical unknowns?
2. Who is capturing hypotheses, baselines, results and time against those parts?
3. Who files the claim, and do they know this project exists?

Answer those at the start and you’re in a far better position than the company reconstructing a year of work from Slack threads.

Frequently Asked Questions

Does using ChatGPT or a vendor copilot in my business qualify for SR&ED?

No. Deploying or configuring off-the-shelf AI tools is applying known technology. SR&ED covers the investigation of technical problems that available knowledge couldn’t solve, such as making a model reliable on data where standard methods failed.

Can failed AI experiments qualify for SR&ED?

Yes. Technological advancement includes learning that an approach doesn’t work, as long as the investigation was systematic. Failed experiments are often the most eligible part of a project, but only if someone recorded the hypothesis, the setup and the result.

How long do I have to file an SR&ED claim for AI work?

Corporations have 18 months after the end of the tax year to file. The deadline isn’t the problem. Evidence quality drops long before it, so capture records during the project.

If you’re planning AI work in your operations and want the R&D economics built in from the first week, book a call with Chrono Innovation. We’ll look at the problem you want to solve, how we’d scope a first production engagement around it, and where evidence capture fits. For more on picking that first problem, see how to prove AI value on one problem.