Posted by Adam
SR&ED is the largest source of R&D support in Canada, and software work is some of the most commonly eligible.
Yet it’s also some of the most commonly under-claimed.
Not because teams aren’t doing qualifying work. But because they don’t recognise it as qualifying while it’s happening, and the evidence is gone by the time anyone goes looking.
So before you either write it off or assume everything counts, it’s worth understanding what the program is actually asking for.
It’s not about what you built. It’s about what you didn’t know.
The most common misconception is that shipping something new and technical is enough. It isn’t.
SR&ED isn’t a reward for building software — it’s support for resolving genuine technical uncertainty: problems where a competent team couldn’t know in advance whether their approach would work, and had to experiment to find out.
That distinction is everything. Wiring up a standard integration, however much effort it takes, usually isn’t eligible. The path was known, it was ‘just work’.
But building something where you genuinely didn’t know if the architecture would hold, or whether the performance was achievable, and you tried, measured, and adjusted? Well, that’s the shape of an eligible project.
Most software teams are doing more of the second kind than they think. They just don’t frame it that way in the moment.
The work that tends to qualify
Without turning this into a checklist you shouldn’t rely on, the eligible work usually looks like:
- Attempting something where the outcome was genuinely in doubt on technical grounds, not just commercially.
- Building and testing approaches that might not have worked, and sometimes (oten times) didn’t.
- Pushing past the limits of what existing tools or documented methods could do for your case.
And the work that usually doesn’t:
- Routine development where the approach was known going in (tapping into pre-existing API’s and SDK’s for a new business outcome, for example)
- Configuration, styling, and standard feature work.
- Effort or difficulty on its own. Hard is not the same as uncertain.
Why the claim is usually won or lost during the build
Here’s the part teams learn too late: a claim succeeds or fails on whether the technical uncertainty is legible to a reviewer — and that’s decided by what you can show, not what you did.
The evidence a strong claim needs is generated while the work happens: the commit history, the decisions and why you made them, the experiments that failed before the one that worked. Reconstruct that eleven months later from memory and a deadline, and even genuinely eligible work becomes hard to defend.
Capture it as a byproduct of how the team already works, and substantiation stops being a project of its own.
That’s the single highest-leverage thing you can do: decide, at the start of a build, which parts are likely to qualify — and then work in a way that leaves a trail.
Where we fit
We’re the technical half of this. We know which parts of a build are likely to qualify and flag it while the work is being scoped. We help frame the technical story so it holds up, and we build the documentation habits in so the evidence exists when it’s needed.
We work alongside your accountant or a specialist claim preparer. We don’t replace them, and we’ll say so plainly.
If you’re planning a build this year, the time to think about SR&ED is now, not at year end. That’s what the funding side of what we do is about.
This is general information about a Canadian innovation program, not tax, accounting, or legal advice. Eligibility and program details change — confirm the specifics with the Canada Revenue Agency and your own advisors before making decisions.