Key Takeaway
The line between qualifying and non-qualifying SR&ED work isn't about difficulty or effort. It's whether a skilled practitioner could have predicted the outcome from existing knowledge. These 10 examples show exactly where that line falls.
The three-part test for SR&ED reads clearly enough: technological uncertainty, systematic investigation, technological advancement. Then you look at a sprint board and try to apply it.
That’s where most companies get stuck. What helps isn’t a deeper explanation of the criteria. It’s examples.
Below are 10, running from clearly qualifying to clearly excluded, with the reasoning CRA applies to each. For the full framework, see SR&ED Eligible Activities for Software Companies.
Example 1: Novel real-time anomaly detection algorithm
What the team did: An e-commerce platform needed to catch fraudulent transactions in under 50ms. Slower than that and legitimate checkouts get blocked. Existing fraud detection either blew the latency target or rejected too many real customers. The team spent three months testing whether a hybrid of statistical baselines and lightweight ML inference could hit both constraints at once.
Does it qualify? Yes.
Why: The uncertainty was real. No published approach covered that combination of latency target and false positive tolerance at their transaction volume. The work was systematic: specific hypotheses about which architectures could fit the latency budget, tested against defined benchmarks, with documented reasons each rejected approach failed.
The documentation that matters: The benchmark methodology. The latency and false positive measurements at each stage. A written explanation of why published approaches fell short.
Example 2: Implementing a standard recommendation algorithm
What the team did: A retailer added product recommendations using collaborative filtering. Six weeks integrating a library, tuning parameters, and A/B testing placements.
Does it qualify? No.
Why: A qualified practitioner could have worked this out from existing knowledge. Collaborative filtering is well documented. Open-source implementations are everywhere. Tuning and placement testing is standard practice.
The line: Applying known methods skillfully is not SR&ED. The answer has to be genuinely unknowable from the literature.
Example 3: Investigating memory corruption in a custom runtime
What the team did: A fintech company built a custom C++ transaction runtime for speed. After deployment it hit intermittent memory corruption under specific load, causing silent data errors. Standard debuggers couldn’t reproduce it reliably.
The team spent eight weeks building custom instrumentation to capture memory state at microsecond intervals. They tested several hypotheses about race conditions in their lock-free data structures. The cause turned out to be an interaction between their memory allocator and the processor’s cache coherency behaviour.
Does it qualify? Yes.
Why: That interaction wasn’t documented anywhere for their architecture. The investigation followed a clear method: form a hypothesis, build instrumentation, run controlled experiments, record results. The knowledge they ended up with didn’t exist before they went looking for it.
The documentation that matters: Each hypothesis and the experiment designed to test it. The instrumentation itself. How the understanding progressed as approaches were ruled out.
Example 4: Bug fix using standard debugging procedures
What the team did: Engineers spent 40 hours on a race condition in a Node.js API causing intermittent 500s under load. They used the Node inspector, async stack traces and a load testing harness, found a missing mutex around a shared cache, and fixed it.
Does it qualify? No.
Why: Known tools, known class of problem, known solution. Race conditions in concurrent programming are thoroughly understood, and protecting shared state with a mutex is textbook.
The distinction: This was hard work by skilled engineers. Difficulty isn’t the criterion. Uncertainty is. Forty hours of applying known techniques is still applying known techniques.
Example 5: Building a novel compression format for edge devices
What the team did: An IoT company had to transmit telemetry from devices with 8KB of RAM over 2G. Existing compression formats were either too expensive to run on that hardware or didn’t compress their data structure enough. Five months developing and validating a custom scheme tuned to the statistical properties of their sensor data.
Does it qualify? Yes.
Why: No existing format met both the memory budget and the compression ratio for that data type. The work had defined performance targets, controlled benchmarks and documented results for every approach tried. What came out is a genuinely new technical artifact.
The documentation that matters: The hardware constraints and performance targets. Benchmarks against existing formats showing why they didn’t work. Experimental results at each stage.
Example 6: Tuning ML model performance with standard techniques
What the team did: A SaaS company fine-tuned a pre-trained language model on its own dataset. Two months of hyperparameter optimization, learning rate schedules, batch sizes and regularization, evaluated on a held-out test set.
Does it qualify? No.
Why: Fine-tuning with hyperparameter optimization is established practice. The techniques are documented and the tooling is off the shelf. New data doesn’t create technological uncertainty on its own.
The possible exception: If the fine-tuning surfaced a specific failure mode that needed original investigation to diagnose, and the literature didn’t cover it, that investigation might qualify. The routine tuning around it still doesn’t.
Example 7: Designing a novel distributed consensus mechanism
What the team did: A blockchain infrastructure company needed sub-two-second finality while tolerating 33% Byzantine node failures. PBFT, Tendermint and HotStuff each failed one constraint or the other at their network scale. Eight months modifying HotStuff, testing security properties against formal threat models, and validating performance in simulation.
Does it qualify? Yes.
Why: No published protocol satisfied that constraint space. The investigation combined formal security analysis with empirical performance testing, which is about as rigorous as it gets. The result extends what’s known in distributed systems.
The documentation that matters: The constraint analysis showing existing protocols fell short. The formal security analysis of the proposed modifications. Simulation methodology and results.
Example 8: Integrating existing APIs for a new feature
What the team did: A project management SaaS added a Slack integration. Three weeks reading Slack’s API docs, handling webhooks, building a settings UI and testing end to end.
Does it qualify? No.
Why: The Slack API is thoroughly documented. A qualified developer implements this by following the documentation. There’s no investigation happening, just reading and building.
The possible exception: If the integration exposed undocumented API behaviour that required original investigation, that part might qualify. The integration itself doesn’t.
Example 9: A custom query optimizer for sparse datasets
What the team did: A geospatial analytics company ran analytical queries over sparse, irregularly distributed geographic data. PostgreSQL, BigQuery and Snowflake all produced poor query plans, because their cost models assume data properties that sparse geospatial data doesn’t have.
Six months investigating whether a custom planning layer aware of their data distribution could beat the general-purpose planners. They formed cost model hypotheses, built a prototype, and validated it against production-representative benchmarks.
Does it qualify? Yes.
Why: The hypothesis was specific and testable, and the failure of the general-purpose planners was documentable. Published query optimization literature didn’t resolve their case. A domain-specific planning layer with modified cost models is real advancement.
The documentation that matters: Benchmarks showing the general-purpose planners were inadequate. The cost model hypotheses tested. Performance measurements at each stage.
Example 10: A failed investigation that produced nothing
What the team did: A healthtech company tested whether neural-symbolic hybrid reasoning could beat pure ML on diagnostic accuracy for their clinical dataset. Four months, five hybrid architectures, controlled experiments against a clinical benchmark. None beat the existing model. They abandoned it.
Does it qualify? Yes.
Why: SR&ED requires genuine investigation, not success. Nobody knew whether hybrid reasoning would outperform pure ML on that task, and the literature couldn’t tell them. The method was sound: defined hypotheses, controlled experiments, documented results. Finding out that those approaches don’t beat the baseline is itself knowledge. CRA explicitly recognizes that failed experiments can qualify.
The documentation that matters: Each architecture evaluated and the hypothesis behind it. The benchmark methodology. Experimental logs. A clear account of why each approach was dropped.
What’s the pattern?
The qualifying cases share three properties.
The uncertainty was specific. Not “we weren’t sure it would work.” Something closer to “this constraint combination isn’t addressed by published approaches, and here’s the evidence.”
The investigation had structure. Not “we tried some things.” A documented progression: hypothesis, test, result, next hypothesis.
The documentation already existed. The record of what was tried was captured while it was happening, not assembled from memory in March.
The non-qualifying cases all fail the first test. The answer was available. Applying known algorithms, implementing documented APIs, tuning established architectures. That’s skilled engineering. It isn’t research.
Here’s the mistake software companies make most: filing on effort and complexity instead of uncertainty and investigation. Hard work isn’t SR&ED. The question is whether a qualified engineer with existing knowledge could have called the outcome before the work started.
Frequently Asked Questions
Does hard engineering work automatically qualify for SR&ED?
No. Difficulty and effort aren’t the criteria. The test is whether a qualified engineer with existing public knowledge could have predicted the outcome. Implementing documented APIs or tuning established models doesn’t qualify, however many hours it takes.
Can a failed project still qualify for SR&ED?
Yes. CRA explicitly recognizes failed experiments. If the uncertainty was genuine and the investigation was systematic, finding out that an approach doesn’t work is a technological advancement. Example 10 covers exactly this.
What documentation makes the difference?
The hypotheses tested at each stage, benchmarks showing why existing approaches fell short, logs of what was tried and observed, and a clear account of why each approach was pursued or dropped. Records made during the work carry far more weight than a narrative written months later.
Want help identifying qualifying work in your engineering team? Talk to our team about automating SR&ED documentation from your development tools.