Key Takeaway
SR&ED stands for Scientific Research and Experimental Development. The CRA defines it using three criteria: technological uncertainty (the outcome isn't knowable in advance), systematic investigation (you followed a methodical process), and technological advancement (you learned something new). Routine engineering doesn't count. Solving hard technical problems does.
The CRA’s official definition of SR&ED is 60 words of regulatory language that explains nothing and confuses everyone.
Here’s what it actually means: SR&ED is work your company does to solve technical problems where the solution wasn’t obvious from the start.
That’s it. Everything else is detail.
The CRA’s Definition (For Reference)
Scientific research and experimental development means systematic investigation or search carried out in a field of science or technology by means of experiment or analysis, which is directed toward achieving a scientific or technological advancement and which is connected with the creation of new, or the improvement of existing, materials, devices, products or processes.
This definition is precise and technical. Translated to practical terms: You did research. You used systematic methods. You faced uncertainty about whether your approach would work. And your work resulted in something better—a faster algorithm, a scalable architecture, a new feature, an optimization.
The key word is advancement. You moved the technical state of your work forward.
Breaking It Down
Three things have to be true for work to count as SR&ED:
1. Technological Uncertainty
You didn’t know at the start whether your approach would work.
You’re not building something from a tutorial or copying a well-known pattern. You’re facing a problem where the solution requires investigation. Maybe you’re solving it for the first time. Maybe you’re solving it in a way that’s new to your company. Maybe existing solutions don’t quite fit your constraints.
Examples:
- “We need a payment processor that handles currency conversion in real time. Existing solutions have 500ms latency. We need sub-100ms.”
- “Our database queries are slow. The standard optimization techniques don’t solve it. What will?”
- “We’re building a recommendation engine. The obvious ML approach gets 60% accuracy. Can we do better?”
In each case: you faced uncertainty. The solution wasn’t obvious. You had to investigate.
Non-examples:
- Integrating Stripe into your application (thousands of companies have done this; the solution is well-documented)
- Deploying to Kubernetes (well-known pattern, documented process)
- Building a standard REST API (established architecture, no uncertainty)
2. Systematic Investigation
You didn’t just guess and hope. You investigated systematically.
This means you:
- Reviewed the problem thoroughly
- Explored potential solutions
- Tested your approach
- Documented what you tried and why
- Made decisions based on evidence, not intuition
Systematic doesn’t mean perfect. It means intentional. It means you can explain your process.
Examples:
- “We benchmarked three different database architectures and selected the one that met our latency requirements.”
- “We tried approach A. It didn’t work because X. We tried approach B. It worked because Y.”
- “We ran experiments to determine which algorithm would give us the accuracy we needed.”
3. Technological Advancement
Your work resulted in progress. You improved something. You didn’t just implement existing technology; you extended it, optimized it, or applied it in a novel way.
The advancement has to be technological, not business-level. You can’t claim “we built a feature customers wanted” if the feature itself is technically straightforward.
You can claim “we optimized the backend to handle 10x more concurrent users at the same cost” because that’s a technological advancement.
Examples:
- Algorithm that achieves higher accuracy than existing open-source alternatives
- Architecture that scales to significantly higher throughput than the standard approach
- Optimization that reduces resource consumption below what existing solutions require
- New approach to a technical problem that competitors have solved differently
The Common Confusion: Novel to the World vs. Novel to You
Here’s what most people get wrong: SR&ED doesn’t require that you invent something new to the world.
It requires that you faced technological uncertainty and resolved it.
Example: Your team invents a machine learning approach for recommendation that achieves 75% accuracy. That’s never been done before—it’s novel to the world. Clear SR&ED.
But your team also solves a scaling problem in your database layer. You’re the first at your company to solve it this way, but companies have solved similar problems before. Still SR&ED, because you faced genuine uncertainty about how to solve your version of the problem.
The CRA cares about your process, not your originality.
Why This Matters for Your Company
The reason the CRA cares about these three criteria is that they’re trying to identify real R&D investment.
If every company just claimed “we did development work,” the program would be useless and expensive. The three criteria filter out the routine work—maintenance, standard implementations, obvious solutions—and identify the work that represents genuine innovation investment.
Your engineering team probably spends 60% of time on routine development (standard features, maintenance, obvious implementations). This doesn’t qualify.
Your engineering team probably spends 30-40% of time on work where they faced real technical uncertainty and had to investigate to solve it. This qualifies.
The CRA wants to identify that 30-40% and provide a credit for it.
What Doesn’t Qualify
- Bug fixes and routine maintenance
- Standard feature development from a clear specification
- Testing, QA, and documentation (supporting activities, not research)
- Sales, marketing, operations, or administrative work
- Routine infrastructure management
- Security patches to existing systems
What Does Qualify
- Developing a novel approach to a technical problem
- Optimizing something beyond what existing solutions achieve
- Solving a concurrency, scalability, or performance challenge with uncertainty
- Developing a machine learning model where the approach and accuracy weren’t guaranteed
- Architecting a system to meet constraints that didn’t have obvious solutions
- Experimenting with emerging technologies to see if they solve a problem
- Any engineering work where you faced genuine technical uncertainty and had to investigate
The Documentation Angle
Why does all this matter? Because when you file an SR&ED claim, you’re making a statement to the CRA: “This work meets the three criteria.”
The CRA can challenge you. They’ll ask: “What was the technological uncertainty? What did you do to investigate? What advancement did you achieve?”
Your documentation needs to answer those three questions clearly.
This is why most companies either under-claim (they’re conservative about what qualifies) or hire consultants (to defend the claim to the CRA).
But if you understand the three criteria clearly, you can document your own work. You can explain why it qualifies. And when the CRA reviews it, they’ll see your process was sound.
A Practical Framework
When your team completes a project, ask:
- Did we face technological uncertainty? Could we have just looked up the answer and implemented it, or did we have to investigate?
- Did we investigate systematically? Can we point to experiments we ran, approaches we tried, or decisions we made based on evidence?
- Did we achieve a technological advancement? Is the result faster, more accurate, more scalable, or more robust than existing solutions?
If yes to all three, it’s SR&ED work. Document it. You’ll claim it later.