SR&ED in software development
Part of it — not all of it. That distinction is what separates a claim that holds from a claim that gets reduced. Here is how SR&ED applies to a Canadian software development team.
- Algorithms and data structures
- Performance and scaling
- Applied machine learning
SR&ED applied to software development
SR&ED is Canada's federal tax credit for scientific research and experimental development. A Canadian-controlled private corporation recovers up to 35 % of its qualifying expenditures as a refundable cash payment, on a base of up to $6M per year; in Québec, the CRIC adds 30 % on the first $1M. Software is the most claimed domain in Canada, and therefore the most scrutinised: claims that describe a product rather than a technological uncertainty are reduced routinely.
- 01
Eligibility turns on a question, not on a technology
No technology stack is eligible or excluded in itself. What matters is that at the outset you knew neither whether the target outcome was achievable nor how to reach it, and that the answer was not available in the public documentation.
- 02
Most teams claim too much, or nothing at all
Claiming all of product development invites a reduction; claiming nothing because "this is not research" leaves a refundable credit on the table. The right answer is an identified fraction, and it rarely sits at either extreme.
- 03
Time is tracked during the year, not in March
A split established after year end is an estimate and is defended as one. A split kept as you go — even roughly, even monthly — becomes data. It is the single practice change that most improves software files.
Examples of eligible projects
Work that commonly qualifies among our clients in this sector. This list illustrates; it does not enumerate. A project absent from it is not a project excluded.
Commonly qualifying in this domain
- Designing an algorithm where known approaches do not hold the constraint
- Scaling a workload to previously unseen volumes
- Machine learning on noisy, scarce or imbalanced data
- Real-time processing under a strict latency constraint
- Custom rules, search or optimisation engines
- Integrating a legacy system with undocumented behaviour
The sector trap: presenting commercial novelty as technological novelty. "No one offers this product" is not an eligibility argument. "No published method reached this target; here are the three approaches we tried and their results" is one.
Frequently asked questions
There is no standard proportion, and relying on a percentage heard elsewhere is the surest way to get reduced. The qualifying share is computed project by project, from the work carried out to resolve a technological uncertainty. At most publishers it is a minority of total development — but a significant share of the engineering payroll.
No. No one is required to write everything themselves, and building on existing work is normal engineering practice. The project still qualifies if, despite those building blocks, a technological uncertainty remained that their documentation could not resolve — and the work consisted of resolving it.
No, and this is a widespread misconception. Calling an existing model, tuning hyperparameters or training by an established recipe is standard practice. Eligibility appears when the problem resists known methods: scarce or noisy data, a latency constraint, an explainability requirement, domain drift. The file is built on those obstacles, not on the technology used.
A review covers two things: the nature of the work, defended by the people who did it, and the consistency of the expenditures. A well-built file holds because it rests on contemporaneous traces — tickets, pull requests, test results, decision records — rather than on a narrative written afterwards. We support our clients through the review; it is part of the mandate.
Hubvention is a Canadian firm specialised in public R&D funding. Our work is to find the right fraction — neither all of development nor none of it — and anchor it in your existing engineering traces rather than in a year-end estimate. That is what makes a software claim defensible.