Product Failure, Financial Success: Can We Still Claim SR&ED If Our Project Failed?

There is a lingering fear in the boardrooms of Canadian companies that goes something
like this: “We poured $100,000 into developing a new automated sorting system, but the
prototype kept jamming, and we eventually had to scrap the entire project. Since we
have nothing to show for it, we can’t claim those expenses on our taxes.”

If this sounds like your company, here is some incredibly good news: Yes, you
absolutely can still claim SR&ED if your project failed. In fact, from the perspective
of the Canada Revenue Agency (CRA), a well-documented technical failure is often one
of the strongest indicators that your project was truly eligible for the program in the first
place.

Why the CRA Rewards Failure

To understand why failure is eligible, you have to look at what the SR&ED program is
actually designed to incentivize. The government isn’t looking to reward commercial
success; they are looking to reward technological risk-taking.

The CRA evaluates your eligibility based on two core technical requirements, both of
which are fundamentally tied to the possibility of failing:

1. Technological Uncertainty
   
   If you knew exactly how to build your project from day one, it wouldn’t be R&D—it would
   be standard engineering. The fact that your project failed proves that there was an
   inherent technological uncertainty that could not be solved using standard industry
   knowledge or public libraries. You took a gamble on an unproven technical approach,
   which is precisely what the program exists to support.
   
2. Technological Advancement
   
   Many business owners assume that “advancement” means creating a flawless, market-
   ready product. However, the CRA defines advancement as the creation of new
   technical knowledge within your company.

When your project fails, your team still learns something incredibly valuable. You learn
that Hypothesis A is mathematically unviable, or that Material B cannot withstand
specific stress parameters. This new knowledge alters your future development path. By
discovering what doesn’t work, you have successfully advanced your internal scientific
or technological understanding.

CRA Policy Direct Note: The official guidelines explicitly state: “You do not have to
achieve your goal in order to gain new knowledge… if your work allowed you to
understand that the idea you tested is not a solution for your situation, this can be
considered new knowledge.”

How to Frame a Failed Project in Your Application?

When writing your technical narratives (Form T261) for a failed project, your framing is
critical. You should never try to hide the failure or paint a picture of artificial success.
Instead, lean into it:

• Emphasize the Bottleneck: Clearly explain the technical obstacles that brought
  the project to a halt. What were the specific limitations of standard industry
  practices that you couldn’t overcome?
  
• Detail the Scientific Method: Show the CRA your systematic investigation.
  Explain the hypothesis your team formulated, how you designed prototypes or
  code to test that hypothesis, and what the experimental data revealed.
  
• Document the Conclusion: Conclude your narrative by explaining why the
  project was halted. State the technical limitations your team uncovered,
  transforming the product’s failure into a successful “advancement of knowledge.”

The Audit Catch: The Critical Importance of Evidence

While a failed project is highly eligible, it does come with one major caveat: It is harder
to reconstruct a paper trail for a project you abandoned.

When a project is successful and goes to market, companies naturally keep the
blueprints, the final code bases, and user manuals. When a project fails, human nature
is to close the tab, throw away the broken physical prototypes, and move on.

If the CRA selects your claim for a review, you cannot simply tell them, “Trust us, we
tried really hard and failed.” You must have contemporaneous evidence (records
created at the time the work was done):

• For Software: Keep the Git repositories containing the broken code,
  architectural notes detailing the crashes, and error logs showing system failures.
  
• For Manufacturing/Hardware: Retain the testing logs, schematics of the failed
  designs, and photos of the deformed materials or broken prototypes.
  
• For Financials: Ensure you can still map the exact hours your employees and
  contractors spent on the failed project via timesheets or project tracking boards
  (like Jira or DevOps).