Most software companies know SR&ED exists. Far fewer know where the program’s boundaries actually sit. Teams routinely exclude qualifying work from their claims, or worse, include work that draws CRA scrutiny and weakens the whole filing.
CRA’s criteria aren’t arbitrary. Once you understand the underlying logic, the pattern becomes clear. This article translates CRA’s eligibility framework into software development terms: what qualifies, what doesn’t, and the categories of work that software teams consistently undervalue.
The Three Categories of Eligible Work
CRA defines SR&ED-eligible work across three types.
Basic research advances scientific or technological knowledge without a specific practical application. Almost no commercial software company does this. It’s included here for completeness.
Applied research also advances knowledge, but targets a specific practical application. Some deep technology companies qualify here: novel ML architectures, new cryptographic methods, custom compilers. The bar is high.
Experimental development is where nearly all software SR&ED claims live. CRA defines it as work carried out to achieve technological advancement for the purpose of creating new, or improving existing, materials, devices, products, or processes. It includes systematic investigation carried out by means of experiment or analysis.
That last phrase matters. Not just building something hard. Not just doing work you haven’t done before. Investigating a technological problem you don’t know how to solve, using a structured approach, producing documented results.
The Three-Part Eligibility Test
For any activity to qualify under experimental development, CRA applies three criteria simultaneously. All three must be present.
1. Technological Uncertainty
There must be a technological problem where the solution is not known or determinable by a qualified practitioner through generally available scientific or technological knowledge.
This criterion trips up the most claims. “We weren’t sure if it would work” is not technological uncertainty. “A skilled engineer applying known techniques could not have predicted the outcome” is.
The test is objective, not subjective. It doesn’t matter that your team didn’t know the answer. What matters is whether the answer was knowable from existing public knowledge. If the solution was documented in academic literature, open-source repositories, or existing product implementations, the uncertainty probably isn’t technological in CRA’s sense.
Uncertainty can also arise at the system level. A 2024 Tax Court decision (DAZZM Inc. v. His Majesty the King, 2024 CCI 129) confirmed that integrating multiple known components can itself create technological uncertainty when their interactions produce unpredictable behavior. If your team combined established technologies and encountered interaction effects that required original investigation, that interaction may qualify.
2. Systematic Investigation
The work must follow a structured process: formulating hypotheses, testing them, observing results, drawing conclusions. CRA uses the phrase “experiment or analysis” specifically.
In practice, your engineers should approach the uncertain problem with structure. What approach did we try? What did we observe? What did we rule out? What did we learn? That documented loop is what survives a CRA review.
“We tried a bunch of things and eventually got it working” doesn’t satisfy systematic investigation. “We formulated three approaches based on available research, tested each against a defined benchmark, eliminated two due to latency constraints, and modified the third to address edge cases not covered in existing literature” does.
3. Technological Advancement
The work must advance the general base of knowledge in the field, not just your company’s product. CRA’s language: “advance the state of technology.”
In practice, “advancement” doesn’t require a published paper or a commercially novel invention. It requires that your investigation produced new technical knowledge: your team now understands something about the problem space that wasn’t previously understood from public sources.
A failed experiment qualifies. Discovering that a particular approach won’t work under certain conditions advances knowledge. CRA does not require success. Only genuine investigation.
What Qualifies in Software Development
CRA’s eligibility policy identifies three scenarios where software development qualifies.
Scenario 1: The software itself is the novel object. New algorithms where no known solution exists. Novel data structures with performance characteristics exceeding published benchmarks. ML model architectures addressing limitations in existing approaches. Custom compiler implementations for non-standard environments.
Scenario 2: Software combined with hardware creates a technologically advanced product. Embedded control systems with novel signal processing requirements. Custom neural network implementations for specialized hardware. Real-time operating systems designed for environments where existing RTOS implementations fall short.
Scenario 3: Software developed to enable other qualifying SR&ED work. Custom test frameworks built because no available testing tool could simulate the required conditions. Simulation environments created specifically for an SR&ED project. This is often overlooked: the tooling you build to do the research can qualify even if it’s never shipped to customers.
Specific Activities That Commonly Qualify
Novel algorithm development. When no known algorithm solves your problem within acceptable performance bounds, and your team conducts original investigation to develop one, the investigation qualifies. The key: documenting what was known, what was unknown, and what experiments you ran.
New data architectures. If your team designed a data model or storage architecture that addresses a constraint no existing approach could solve, and the design required original experimentation to validate, the work qualifies. This includes custom query optimization, novel indexing approaches, and storage architectures for access patterns that existing databases handle poorly.
ML model development at the research boundary. Training a model using established techniques on your specific data is generally not SR&ED. Developing a new training method, addressing a known failure mode in existing architectures, or investigating unexpected model behavior in production may qualify. The line is whether your work extended beyond applying known techniques.
Performance optimization beyond documented techniques. Tuning performance using established profiling methods doesn’t qualify. Investigating why your system fails to meet targets after all known optimization techniques have been applied, formulating hypotheses about root causes, and conducting experiments to test them may qualify. The uncertainty must be genuine.
New protocol implementations. Implementing an existing network protocol doesn’t qualify. Designing a protocol for communication requirements that existing protocols can’t satisfy, or investigating how to extend a protocol to environments it wasn’t designed for, can qualify.
Custom compiler and interpreter work. Building a compiler for a novel language or for a target environment where existing compiler tooling is inadequate is a well-established SR&ED category. The investigation into generating correct and efficient output for non-standard targets typically satisfies all three criteria.
What Does Not Qualify
CRA is specific. These categories are explicitly excluded.
Routine bug fixes. Debugging using established diagnostic methods doesn’t qualify. “We spent 40 hours tracking down a race condition” isn’t SR&ED if your team applied standard debugging tools. If the bug revealed something genuinely unknown about how your system behaves that required original investigation, that investigation may qualify. The debug itself does not.
Standard feature development using known techniques. Building features with established frameworks and architectural patterns doesn’t qualify regardless of complexity. Complexity isn’t the criterion. Uncertainty is. If a skilled developer could look up how to build it, it’s not SR&ED.
UI and UX work. CRA explicitly excludes design, aesthetics, and user experience work. This includes render pipeline performance improvements achieved through established optimization techniques.
Data collection and market research. Engineering work fundamentally gathering data about user behavior, market demand, or product performance doesn’t qualify. Data collection to support a qualifying technological investigation may qualify separately.
Applying AI/ML tools using existing methods. Plugging data into a known model architecture, fine-tuning a foundation model without addressing a novel technical problem, or implementing RAG using available libraries is standard practice. If the established approach works as documented, no qualifying uncertainty exists.
Quality assurance and routine testing. Standard QA, regression testing, and acceptance testing don’t qualify. Testing as part of a qualifying systematic investigation may qualify if it generates experimental results rather than verifying known behavior.
Post-development deployment and maintenance. Infrastructure setup, CI/CD configuration, production monitoring, and routine maintenance are explicitly excluded.
Eligible Expenditures: What CRA Allows You to Claim
Eligible activities generate eligible expenditures. CRA allows claims across four categories.
SR&ED wages. Salaries and benefits paid to employees directly engaged in SR&ED work. Time allocations must be supported by records. CRA scrutinizes allocations above 80% for any individual employee.
SR&ED materials. The cost of materials consumed or transformed in the SR&ED process. For most software companies, this is minimal. Server costs for experiments are the most common item.
SR&ED contracts. If you contracted third parties to perform qualifying SR&ED work on your behalf, 80% of those costs are eligible expenditures (the 20% holdback accounts for potential IP transfer considerations). Contracts require supporting documentation: signed agreements, invoices, and a description of the qualifying work performed.
Overhead. Two methods apply. The Proxy Method applies a 55% multiplier to your SR&ED salary base. No itemized overhead tracking required. Most software companies use this because the administrative burden is lower. The Traditional Method allows you to claim specific overhead costs that directly support SR&ED activities. Higher potential ceiling, but requires detailed allocation documentation for every overhead item.
The choice between methods is made on the T661 and is binding for the tax year. For a full walkthrough of how expenditures are reported, see the T661 form guide.
The Activities Most Software Companies Miss
SR&ED claims are consistently incomplete in two areas.
Developer time on failed approaches. Engineers who spent weeks investigating a problem that ultimately required abandoning the first approach often don’t flag that work. But the investigation of a dead end is often the most eligible work in the project. The uncertainty was real, the investigation was systematic, and the knowledge gained is genuine advancement.
Internal tooling built to enable research. If your team built a simulation environment, custom test harness, or benchmarking framework because no available tool could do what you needed, that tooling work may qualify. It’s not shipped to customers, so it’s easy to overlook. But CRA explicitly includes software created to support qualifying SR&ED projects.
Integration work with genuine system-level uncertainty. Before the DAZZM ruling, many practitioners excluded integration work on the grounds that individual components were all known. Post-DAZZM, the picture is clearer: if your team’s integration of known components produced interaction effects that required original investigation, that work may qualify at the system level. If you’ve been excluding this category, it’s worth revisiting.
From Eligibility to Documentation
Knowing what qualifies is step one. Step two is capturing it in a way that survives CRA review. The common failure: companies do qualifying work all year, then spend weeks at filing time trying to reconstruct technical narratives from memory and commit logs. The reconstruction is expensive, often incomplete, and produces documentation CRA treats skeptically because it wasn’t created contemporaneously.
The alternative is continuous capture: flagging qualifying work as it happens, building technical narratives incrementally, arriving at filing time with documentation that reflects what actually occurred. More accurate, more defensible, and it recovers work that retrospective reconstruction misses.
Want to see how much qualifying work your team is leaving on the table? Talk to our team about automating your SR&ED documentation.