What Actually Makes Software Work SR&ED-Eligible?
Most software companies doing real R&D leave SR&ED credits on the table because they don't recognize their own qualifying work. Here's the eligibility distinction that matters.
The argument every team has at year-end
Picture a sprint review. Two engineers are arguing about whether the ML inference work they spent three months on qualifies for SR&ED. One says yes — it was technically difficult and took real effort. The other says no — they eventually found a published paper that described a similar approach. Who's right?
This argument happens because most teams conflate difficulty with eligibility. SR&ED doesn't reward effort. It rewards a specific type of technical investigation — and the test is narrower than most founders expect.
The CRA asks two questions, and both must be yes: (1) Did the work advance the state of knowledge or technology — not just for your team, but in the field? (2) Was it carried out through systematic investigation — forming hypotheses, running experiments, recording what you discovered?
The recipe versus experiment distinction
Think of it like cooking. Following a recipe is not SR&ED — even if you've never made the dish before and it takes three attempts to get right. Developing a recipe for an ingredient that doesn't yet exist, where no cookbook applies — that's closer to what CRA is evaluating.
If a competent engineer in your field could have solved the problem by searching the documentation, reading the relevant papers, or following a standard integration guide, it's a recipe. If the path required genuine experimentation because existing approaches didn't cover your specific constraints — that's where SR&ED eligibility lives.
CRA evaluates two things: technological advancement (did the work push the state of knowledge, not just your team's knowledge?) and systematic investigation (did you experiment, record findings, and learn — including from dead ends?). Difficulty and novelty-to-your-team are not the test.
Work that commonly qualifies
- Novel algorithm or approach developed because published methods couldn't meet your performance, accuracy, or scale requirements
- Resolving a fundamental conflict between technical requirements — consistency vs. throughput in a distributed system — where no established resolution existed for your specific parameters
- ML model architecture work for a domain where existing benchmarks didn't exist and standard fine-tuning failed for your data profile
- Performance optimization requiring understanding of runtime behaviour at a level beyond what documentation covers
A team builds a real-time anomaly detection system for a niche industrial sensor dataset. Published approaches (Isolation Forest, autoencoders) are well-documented, but they fail on the specific temporal patterns and noise characteristics of their data. The team experiments with three novel approaches, documents what each one revealed, and ultimately develops a hybrid method not in the literature. The investigation — including the failed attempts — qualifies.
Work that commonly doesn't qualify
- CRUD application development using documented frameworks and APIs — even complex ones
- Routine integrations where the third party provides documentation, SDKs, and support paths
- UI/UX work without underlying technical uncertainty in the platform or rendering layer
- Applying a technique your team hadn't used before, but which was well-documented and available in the field
- Configuration tuning within documented parameter ranges
'Novel to our team' is not the standard. If the approach was documented in a paper, available in a maintained library, or covered by vendor support — it doesn't matter that your team hadn't done it before. The advance must be in the state of the field, not the state of your codebase.
The investigation — the part most teams forget to document
Even genuinely qualifying work fails at the documentation stage. Systematic investigation means forming a hypothesis, trying something, and recording what you found — including what didn't work. It does not require formal lab notebooks.
Normal engineering artefacts serve as evidence when they show the reasoning process: design documents recording rejected approaches, PRs with technical rationale, architecture decision records, benchmark logs showing what was tried and what the outcomes were. A commit message that says 'fixed bug' is not evidence. One that says 'attempted [approach A] for [problem], found [result], switching to [approach B] because of [finding]' is.
If you systematically investigated an approach and discovered it didn't work, that's a valid SR&ED outcome. New knowledge that a path isn't viable for your constraints is exactly what the program rewards. Don't hide the dead ends — document them.
This guide is for general information only. SR&ED eligibility is determined by the CRA based on the specific facts of each project. All claims should be reviewed by a qualified CPA or SR&ED preparer before filing.
Turn this guide into a claim package
SREDY.IO walks you through eligibility, project narratives, supporting costs, and evidence so your CPA has a cleaner file to review.
More guides
The Evidence Habit: What to Save Before Year-End
SR&ED claims are significantly easier to defend when you've been saving the right artefacts throughout the year. A practical pre-year-end checklist for Canadian tech companies.
EligibilityAI Projects and SR&ED: What Changed, What Didn't
AI and ML work can qualify for SR&ED — but not all of it. The CRA's eligibility test hasn't changed. Here's what that means for model training, fine-tuning, and architecture decisions.
T661 WritingHow to Talk About Uncertainty Without Overclaiming
The language you use in a T661 narrative matters. Overstating uncertainty reads as speculative. Understating it undersells the challenge. Here's how to write about technical uncertainty in CRA-ready language.
Ready to check if your work qualifies? Take the free eligibility assessment.
Check eligibility — free →