TL;DR: Machine learning and LLM work can qualify for SR&ED (Scientific Research and Experimental Development) when your team is trying to solve a technical problem that standard practice can't, and works through it with hypotheses and testing. Calling an API, tweaking prompts or applying a known fine-tuning recipe usually doesn't qualify. The technical challenge decides eligibility, not the tool your team used.
At GrowWise Partners, a Canadian SR&ED consulting firm, I talk to a lot of founders building on LLMs right now. Most of them start with the same assumption: every hour the team spends in Claude Code, Cursor or a fine-tuning notebook counts. It usually doesn't. The opposite mistake happens too, where some of the most eligible work sits inside teams that think "we just use an API." Want a second opinion on your own projects? Book a free consultation with our team.
Tool time vs problem time
Here's the framework I use with ML teams: split the year into two buckets.
Tool time is the work of using AI well: writing prompts, wiring an API into your product, picking a model, running a fine-tune the way the documentation says to, and cleaning data for normal operations. It ships product, but it isn't SR&ED, because the answer already existed. Someone else resolved that uncertainty when they built the model or wrote the guide. It's the same reason not all R&D qualifies for SR&ED.
Problem time starts when the known approach stops working against your specific constraint. The model can't hold accuracy on your messy data. It can't run inside your latency or memory budget. It breaks on edge cases nobody has published a fix for. From there, your team forms a hypothesis, tests it, learns something and tries again.
That second bucket is what CRA calls a systematic investigation: define the problem, advance a hypothesis, test it by experiment or analysis, and draw conclusions from the results (CRA: What work is eligible). The core SR&ED questions don't change for AI. They just need translating: What didn't you know at the start? What did you try? What did you learn?
For the full criteria across every industry, see our guide to SR&ED eligibility.
What did CRA clarify about AI and LLM claims?
Short answer: the uncertainty you start with matters more than the failures along the way, and your records have to tell the story your code can't.
In August 2026, we met with a research and technology policy coordinator in CRA's SR&ED program to clarify how CRA looks at claims from teams building with AI. These were his informal views in conversation, not published CRA policy, but they're the clearest guidance we've had on the topic:
- Eligibility starts at kickoff. A claim rests on a real technological uncertainty identified at the start of the project, not on how many experiments failed.
- Success can still qualify. A well-planned project run by skilled engineers can be SR&ED if it systematically closed a genuine technical gap.
- Repository data backs up the story but doesn't tell it. GitHub commits and Jira tickets are supporting evidence. A written explanation of the technical problem gives them context.
- Time tracking can be light. People on SR&ED full time need a simple daily log; people who split their time need a weekly summary covering both SR&ED and non-SR&ED work. Either takes about 3 to 5 minutes a day.
- Engineers describe, leads decide. Developers record what they worked on without judging eligibility. A technical lead who knows the criteria pulls out the SR&ED hours.
- AI can help write the claim, but people own it. Using an LLM to polish a technical narrative is fine if a person verifies every fact. A fully AI-generated claim raises review risk.
- Expectations grow with you. As companies scale, CRA expects time tracking to move into formal timekeeping software.
Does fine-tuning an LLM count as SR&ED?
Short answer: sometimes. It depends on why you fine-tuned and whether you knew it would work.
Fine-tuning an open-weight model on your support tickets with a published method that hits your target is implementation. If that method plateaued below the accuracy your product needs, and your engineers had to test data mixes, training approaches or model structures to find out why, you may be in SR&ED territory.
What matters is the uncertainty at the start, not how many attempts failed. That's one of the points we clarified with CRA, covered above.
Is prompt engineering or building on an API eligible?
Short answer: on its own, usually not.
Wrapping a chatbot around an off-the-shelf model or refining prompts until the tone sounds right is tool time. So is your marketing, BD or ops team using AI tools. SR&ED is about technical experts, your developers and engineers, working on a technical problem.
Prompt work can still sit inside an eligible project, for example when engineers test structured prompting against a fine-tuned model as competing fixes for the same reliability problem. What counts is the question the prompts were helping to answer. Our guide to whether software development is eligible for SR&ED covers the wider software rules.
What does eligible LLM work look like in practice?
Here are patterns where I'd dig in further with an ML team. None qualify automatically: each one only counts if the standard approach measurably fell short for you. Our AI and machine learning SR&ED page has more examples by technology.
- Reliability on messy, domain-specific input. The model has to interpret inconsistent context, partial information or industry jargon, and off-the-shelf retrieval or fine-tuning can't reach the reliability your product needs.
- Grounding and hallucination control. Your use case can't tolerate made-up answers, and you're testing retrieval, re-ranking or verification approaches to get errors below a defined threshold.
- Running inside hard limits. The model has to run on your own hardware, a device, or a strict latency or cost budget, and techniques like quantization or distillation don't hold accuracy at the size you need.
- Building data that doesn't exist yet. No public dataset covers your edge cases, so your team designs new training or test data specifically to answer the technical question.
- Measuring what no benchmark measures. Your team has to invent a way to evaluate correctness for a task that has no standard test.
And here's what usually doesn't qualify:
- Calling a model through an API and shipping the output
- Prompt refinement for tone, format or style
- A fine-tune that follows a published recipe and works
- Setting up a vector database or retrieval pipeline with default settings
- Collecting or labelling data for normal business operations
- Learning a new framework or model family
A client story: 50% expected, 40% eligible
One of our clients spent most of a year adapting an LLM for a voice AI product in a specialized industry, where calls are full of context the model has to catch, unique workflows, and callers who change details halfway through.
The team assumed about 50% of three engineers' time was SR&ED. When we dug in, about 20% of that was routine model refinement: prompt changes, configuration and standard tuning. That part wasn't eligible.
The other 30% was real problem time. The engineers were building and iterating on the logic that let the model process complex, inconsistent input, use context even when it wasn't stated cleanly, and handle edge cases correctly. A hypothesis for that kind of work might read:
If we add a context-tracking layer that reconciles details as a caller corrects or contradicts themselves, the system will route edge-case calls to the correct workflow with at least 95% reliability across our test set.
Then there was work the team hadn't counted at all. To test that logic, they built a system that generated and ran edge-case test calls. They couldn't have run the experiments without it, so it counted as support work and added another 10% of the team's time (more on support work below).
Final result: roughly 40% of three engineers' time, and an SR&ED refund of about $60,000 for that project. That's less time than they first assumed, and it's built on work that holds up.
Does testing and evaluation work count too?
Short answer: often yes, as support work.
Eval harnesses, synthetic test data and benchmark runs feel like plumbing, so teams skip them. CRA lists testing, data collection and computer programming among the types of support work that can be eligible, as long as the work directly supports the experimental development and is in proportion to what it needs (CRA: support work). A test suite you'd run on every release is routine testing, which CRA excludes.
What should your machine learning team document?
Short answer: the problem, what you tried, what happened, and who spent time on it.
Here's the step I'd set up this afternoon. In Jira or Linear, when an engineer hits a problem the standard approach can't solve, they open a ticket answering three questions: what's the problem, what are we trying, and how will we know it worked. Results go in the comments. That's your hypothesis trail, written at the time, in the tool your team already uses.
Pair that ticket with a light time record and you have both things CRA told us it looks for: the story, and the hours behind it.
This is also where we do the heavy lifting: GrowWise connects to GitHub, Jira, Confluence, Linear and shared drives and surfaces the projects, tickets and commits that signal eligible R&D, so your team doesn't rebuild that trail at year end. Our guide to SR&ED time tracking in 2026 covers the setup in more detail.
Signals you're ready, and signals you're not
You're likely ready to look at a claim if:
- Your developers or engineers, not your marketing or ops team, are spending real time on one hard technical problem
- The documented approach failed against your constraint, and you can say how
- You're running structured tests: hypotheses, evals, comparisons
- Your eligible technical spend could produce a refund of about $20,000 or more
It's probably a not yet if:
- Your AI work is an off-the-shelf model behind a nice interface
- Prompt and configuration changes are getting you where you need to go
- The eligible work so far would produce less than about $20,000
Timing is usually more financial than technical. A few years ago, I worked with two co-founders building impressive AI technology who weren't paying themselves yet. The work met the technical bar, but no expenses meant no claim. They came back with four engineers and filed a claim of over $300,000. It's not a no, it's a not yet. More on that in our guide to timing your first SR&ED claim.
Waiting does cost something: your filing window is generally 18 months after fiscal year end, and notes on what you tried fade fast.
The GrowWise take
I'm genuinely excited about what Canadian AI teams are building, and CRA's numbers show it. Software accounted for 42.6% of SR&ED credits allowed in 2025-26, up from 35.7% five years earlier (CRA annual program statistics).
I'd still push every ML team to be honest about the split between tool time and problem time. A claim built on real technical challenges, with notes written as the work happened, is one you can stand behind in a review.
My advice: if your work goes beyond basic LLM refinement, prompting or implementing off-the-shelf AI, it's always worth reaching out to find out for sure. You could be leaving tens of thousands of dollars on the table.
Quick-reference FAQ
Does using Claude Code or Copilot disqualify our SR&ED claim? No. The tools your engineers use aren't part of CRA's test. What matters is whether the work resolved a technological uncertainty through systematic investigation, so the eligible part is the problem solving around the code.
Do failed ML experiments count for SR&ED? Yes, if they were part of a systematic investigation. CRA says you don't have to achieve your goal, and learning that an approach won't work for your situation can count as new knowledge.
Do we need to train our own model from scratch to qualify? No. Adapting an existing model can qualify when standard methods fall short of your technical requirements and your team investigates why.
How much could an ML team get back from SR&ED? It depends on salaries and how much time is eligible. For example, a CCPC (Canadian-controlled private corporation) spending $600,000 on SR&ED salaries using the proxy method has $930,000 of qualified expenditures. At 35%, that's a federal refundable credit of about $325,500, before provincial credits. Try our SR&ED calculator for your own estimate. If contractors do part of the work, our CTO's guide to employee and contractor costs explains how each is treated.
Not sure where your work lands?
This post covers the general rules, and every team's situation is different. If you're not sure whether your ML or LLM work clears the bar, book a free consultation with our team and we'll look at your projects against what CRA actually asks for. There are no upfront costs: you pay when CRA pays you.
About the author. Lauren Valliere is Co-Founder and Managing Partner of GrowWise Partners, where she helps Canadian startups and scaleups claim SR&ED without hating the process. A chemical engineer by training (University of Waterloo), she works with companies across software, manufacturing, biotech, cleantech and hardware on what qualifies, how to track it and how to build a claim that holds up. She was named a 2026 Peak Emerging Leader.
