Illustrative example based on the kinds of matters we handle — not a specific client engagement; outcomes depend on the facts.
The situation
A small technology company — a software and hardware-integration shop with a lean team of developers and engineers — came to us after its Scientific Research and Experimental Development (SR&ED) claim was denied. The company had built a new system that pushed past what its off-the-shelf tools could do, spent real money on developer salaries and contractors over the year, and filed for the investment tax credits its accountant had prepared. Those credits were effectively the runway the founders were counting on.
The Canada Revenue Agency selected the claim for review and disallowed the eligible work almost entirely. The reason was not that the development had not happened, and not that the dollars were wrong — it was that the project, in the reviewer's view, did not involve technological uncertainty. In SR&ED terms that is close to fatal: without qualifying experimental development, the credits vanish.
The challenge
SR&ED eligibility turns on a technical test, not a financial one: did the work seek to advance technology by resolving uncertainty that a competent professional could not have settled using standard practice, through systematic experimentation. On this file, the gap was not the engineering — it was how the engineering had been described:
- The claim read like a project summary, not an experiment. It described what the team built and how well it worked — the language of a product launch — rather than what was unknown at the outset.
- "We solved a hard problem" is not the test. A difficult build or a clever result does not, by itself, establish technological uncertainty, and the CRA had read the difficulty as ordinary engineering effort.
- Contemporaneous records were thin. The real experimentation — failed approaches, abandoned architectures, iterations that did not work — lived in commit histories, sprint tickets, and test logs, not in a tidy SR&ED narrative.
- Routine work was bundled in. Configuration, debugging known errors, and standard feature development had been folded into the claim, making the whole project look like ordinary development.
The task was not to invent uncertainty, but to show — with evidence the company already had — that genuine technological uncertainty existed at the start and was resolved systematically.
How we approached it
We began by explaining that a denied SR&ED claim is the CRA's position at the review stage, not the last word, and that a Notice of Objection reopens the technical question with Appeals. From there the work was methodical:
- Rebuilt the technical narrative around the uncertainty. We reframed the project with the developers: what obstacles standard practice could not overcome, what hypotheses the team formed, and how they tested them — shifting the story from "the product we shipped" to "the unknowns we had to resolve."
- Mined the contemporaneous record. Version-control history, issue trackers, branch experiments, and test results showed iteration and failed attempts — the fingerprints of systematic experimentation — dated to the year of the claim rather than reconstructed after the fact.
- Separated routine development from eligible work, so the eligible experimental development stood on its own.
- Mapped the evidence to the CRA's own questions, so the Appeals reviewer could follow the eligibility analysis step by step rather than re-litigate the whole project.
- Filed and argued the objection within the deadline, dealing with the CRA directly and keeping a Tax Court of Canada appeal in reserve.
For how the technological-uncertainty test plays out in the courts, our note on the Canafric SR&ED decision and the five questions walks through the same framework, and our guide on filing a Notice of Objection explains the procedure.
The outcome
What can happen on a matter like this is that a denial driven by presentation rather than substance is substantially reversed once the evidence is reframed. By the close of the objection, a large share of the disallowed work was accepted as eligible and the associated investment tax credits were reinstated. A residual portion — genuinely routine development — was not pursued, because advancing ineligible work would not serve the company. The matter resolved at the objection stage without the need to litigate.
It is equally honest to say these files take time and coordination. The result turns on what the evidence can establish — not on how hard the team worked.
The takeaway
On an SR&ED file, the question is rarely "did you do difficult engineering" — it is "can you show technological uncertainty that standard practice could not resolve, and systematic experimentation to resolve it." Many claims are denied not because the work was ineligible but because it was written up as a finished product rather than an experiment, with the real evidence of iteration left buried in commit logs and tickets. A denial for "no technological uncertainty" can often be challenged on objection by reframing that evidence against the criteria the CRA actually applies — and the earlier the technical narrative is built, the stronger the claim usually is.
If your SR&ED claim has been challenged or denied, our pages on audit representation and tax disputes and objections explain how these matters work.
This is an anonymized, illustrative example and not legal advice. Results vary with the facts of each matter; nothing here is a prediction or assurance of any particular outcome in your case.