One of the most common misconceptions I encountered while reviewing SR&ED claims at CRA was this: software companies either assumed everything they built qualified, or they assumed nothing did. Both assumptions cost them money. The reality is more nuanced — and if you understand the three eligibility criteria, you can identify the qualifying work embedded in nearly every serious software development effort.
The Three Eligibility Criteria
For any work to qualify as SR&ED under the Income Tax Act, it must satisfy all three of the following criteria simultaneously.
1. Technological Uncertainty
There must be a genuine technological uncertainty — meaning you did not know, and could not determine through standard practice or publicly available knowledge, how to achieve a specific technical result. This is not business uncertainty (“will customers buy this?”) or resource uncertainty (“can we build this on time?”). It is a question your engineering team could not answer by reading documentation, hiring someone with existing expertise, or applying known techniques.
For software companies, this might look like: an algorithm that must perform within latency constraints that existing approaches cannot meet; a distributed system that must guarantee consistency properties under failure modes not covered by established protocols; or an AI/ML model that must generalize to a data distribution where no published architecture has demonstrated success.
2. Systematic Investigation
The work must be carried out through a systematic investigation or search — meaning hypothesis-driven experimentation, not ad hoc tinkering. CRA expects to see that your team formulated hypotheses about potential solutions, designed experiments or test scenarios to evaluate them, observed and recorded results, and drew conclusions that informed subsequent iterations.
This is often where software companies fall short — not because they did not do the work, but because they did not document it in a way that makes the systematic nature visible to a reviewer.
3. Technological Advancement
The work must attempt to advance the general state of knowledge or capability in a field. Note the word “attempt” — you do not need to succeed to qualify. A failed experiment that advances your understanding of why an approach does not work can qualify just as much as a successful one.
What Typically Qualifies
In my experience reviewing software SR&ED claims, the following types of work most commonly meet all three criteria:
- Novel algorithms: Developing new sorting, search, compression, or optimization algorithms where existing approaches are insufficient for your specific constraints
- AI/ML with genuine uncertainty: Training models on novel data distributions, developing new architectures for specific performance targets, or solving generalization problems where published methods fall short
- New protocols or communication layers: Designing custom protocols for specific reliability, latency, or security requirements not met by existing standards
- Compiler or runtime development: Building language runtimes, transpilers, or low-level optimization layers
- Distributed systems with novel consistency or fault-tolerance requirements: Work at the boundaries of what CAP theorem tradeoffs allow
What Does Not Qualify
Equally important is what CRA consistently excludes:
- Routine bug fixes: Identifying and correcting known defects using established debugging techniques
- Using existing frameworks as intended: Integrating a third-party library, deploying on a cloud platform, or configuring existing tools — even if complex
- UI and UX work: Design, usability testing, and front-end development that does not involve technological uncertainty
- Market research and business analysis: Determining what to build is not SR&ED, even if technically informed
- Work that only involves uncertainty about project success: Not knowing if a feature will work as a product is different from not knowing if a technical approach will work
The Grey Zone
The hardest cases — and the ones where a former CRA reviewer’s perspective is most valuable — are projects that mix qualifying and non-qualifying work. A product feature might involve 20% genuinely novel algorithmic work and 80% integration and delivery effort. Only the 20% qualifies, but it can still represent significant dollars if your team spent meaningful engineering time in that space.
Book a Free Eligibility Review
If you are unsure whether your software development qualifies, the fastest path to an answer is a conversation with someone who has reviewed these claims from both sides. Book a free eligibility consultation and we will tell you directly what qualifies, what does not, and how to structure your documentation to support a defensible claim.