SR&ED for systems and productivity software
Rendering engines, memory management, offline synchronisation, format interoperability: systems and productivity software publishers constantly solve problems the public documentation does not solve. That is the work SR&ED funds.
- Engines, compilers and runtime layers
- Synchronisation, concurrency and consistency
- Interoperability and backward compatibility
SR&ED applied to software publishers
SR&ED is Canada's federal R&D tax credit. 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. At a software publisher the difficulty is not finding qualifying work — it is separating it from the rest of product development, which occupies the same team, the same repository and the same sprint.
- 01
The feature is not the project
The CRA reasons by technological uncertainty resolved, not by feature shipped. One SR&ED project can span five features, and a major feature can contain none. Cutting the claim along the product roadmap is the leading cause of rejection among publishers.
- 02
Performance and memory are real uncertainties
Hitting a latency, memory-footprint or power target on constrained hardware, when known approaches fall short, is experimental development. It is also the easiest work to document, because it produces measurements.
- 03
Poorly documented interoperability
Making a proprietary format, an unspecified interface or a legacy system whose real behaviour differs from its documentation actually work requires reverse engineering and trials. This work qualifies and is almost never claimed.
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 a rendering, computation or indexing engine
- Real-time collaborative editing and conflict resolution
- Offline synchronisation and cross-device consistency
- Optimising memory footprint or startup time
- Reverse engineering an unspecified format or interface
- Porting to an architecture with different behaviour
The sector trap: claiming the product instead of the problem. A new release, however ambitious commercially, is not SR&ED in itself. What qualifies are the components whose design had to be searched for because no known approach held the constraint.
Frequently asked questions
No, not as a whole. Writing code by applying established techniques — even complex code, even a lot of it — is not SR&ED. Eligibility rests on a technological uncertainty: an outcome you did not know, at the outset, was achievable or how to achieve. That is a fraction of a product team’s work, and it is that fraction you have to isolate.
By uncertainty, not by feature or by sprint. An SR&ED project is defined by the technical question you were trying to answer, the hypothesis tested and the trials run — it may span several product milestones. Branches, pull requests and benchmark results then serve as contemporaneous evidence attached to that question.
Yes. Distribution model, pricing and licensing have no bearing on SR&ED eligibility. What matters is the nature of the work performed and the fact that the company incurred the expenditures in Canada. Contributing to an open project to resolve a technological uncertainty blocking your product qualifies exactly as closed source would.
Yes. Qualifying salaries are those of personnel working in Canada; work performed abroad is generally excluded, with narrow exceptions. For a distributed team the geographic split of hours becomes a claim input rather than an administrative detail, and it has to be establishable year by year.
Hubvention is a Canadian firm specialised in public R&D funding. At a publisher our work consists of reframing the roadmap into technological-uncertainty projects — the scoping the CRA expects and that almost no product team produces on its own.