The Anatomy of a Denied SR&ED Claim

It's Rarely the R&D That's the Problem

Most denied SR&ED claims involved legitimate R&D work. The engineering was real. The uncertainty was genuine. The team learned something new. The claim still got denied.

That's because CRA doesn't evaluate your R&D. They evaluate your description of it. A Research and Technology Advisor reads your T661, assesses whether the language meets their eligibility criteria, and makes a determination based on what's on paper. If your narrative doesn't clearly articulate uncertainty, hypothesis-driven investigation, and advancement in the specific way CRA expects, the work doesn't matter.

After reviewing hundreds of SR&ED claims, we've identified five patterns that account for the vast majority of denials. Each one is preventable. And each one comes down to how the claim was written, not whether the work qualified.

Pattern 1: Vague Uncertainty Language

This is the most common reason claims get denied. The uncertainty statement is so broad it could apply to any software project.

Why it fails: An RTA reading this has no idea what system, what performance requirements, or what constraints. This sentence could describe any engineering project. It provides no evidence that the uncertainty was technological rather than practical.

Why it works: The uncertainty is specific to a defined technical problem. It identifies what was unknown, the technical context, and the success criteria. An RTA can evaluate whether this constitutes genuine technological uncertainty.

If your uncertainty statement could be copy-pasted into a different company's claim without changing a word, it's too vague and will likely be denied.

Pattern 2: Systematic Investigation That Reads Like a Dev Log

CRA requires evidence of hypothesis-driven experimentation. What they often receive is a chronological description of what the team built.

Why it fails: This describes a standard software development lifecycle. There's no hypothesis, no explanation of why specific approaches were chosen, no intermediate results informing the next phase. An RTA will classify this as routine development.

Why it works: Each phase starts with a hypothesis or technical question. Results are quantified. Failures are documented and explicitly inform the next phase.

Every phase should answer three questions: what did you hypothesize, what did you test, and what did the results tell you? If a phase only describes what you built, it's a dev log, not an investigation.

Pattern 3: Advancement That Restates the Project Scope

The technological advancement section (Line 246) asks what new knowledge was generated. Most denied claims answer a different question: what did you build?

Why it fails: This describes a product feature, not a knowledge advancement. An RTA will ask: What do you know now that you didn't know before? This statement answers neither question.

Why it works: The advancement is framed as new knowledge: extending existing theory, establishing where existing approaches fail, and demonstrating a specific technique resolves a previously open problem. Negative results add credibility.

Start your advancement with what was learned or established, not what was built or shipped. If your advancement section reads like a product release note, rewrite it.

Pattern 4: Missing or Unsupported Time Allocation

Even when the technical narrative is strong, claims get reduced or denied because the time allocation in Part 4 can't be defended.

Why it fails: An RTA will ask how the 60% was calculated. If the answer is 'that seemed about right,' the allocation gets reduced or rejected. Round numbers without methodology are a red flag.

Why it works: The allocation is broken down by project, tied to specific time periods, and supported by a documented methodology referencing actual artifacts. The number isn't round, signaling it was calculated rather than estimated.

Every allocation percentage needs a methodology sentence explaining how it was derived. If you can't explain why it's 65% and not 60%, you don't have a defensible allocation.

Pattern 5: The "Routine Engineering" Determination

This is the denial that stings the most because it feels like CRA is saying your work wasn't hard enough. What they're actually saying is that your claim didn't demonstrate why standard practices were insufficient.

Why it fails: Scaling and performance optimization are standard engineering concerns. Without an explanation of why standard approaches (caching, load balancing, horizontal scaling, established concurrency patterns) were insufficient, CRA will classify this as competent engineering, not SR&ED. The word 'challenges' is doing all the work, and CRA doesn't accept challenge as a synonym for technological uncertainty.

Why it works: It names the standard approaches considered, explains specifically why they were insufficient, and references the state of publicly available knowledge. The RTA can now assess whether this genuinely exceeds standard practice.

Always name the standard approaches you considered and explain specifically why they didn't work. "It was challenging" is never enough.

Why These Patterns Keep Recurring

All five denial patterns share a root cause: the person writing the claim didn't extract the right information from the people who did the work.

When an accountant or consultant writes the T661 based on a brief conversation or a project summary, they default to describing what was built rather than what was unknown, what was tested, and what was learned.

When a generic AI tool generates the narrative from commit logs or Jira tickets, it produces fluent text that sounds technical but lacks the specificity CRA requires.

The information needed to pass a CRA technical review exists. It's in the heads of the engineers who did the work. The question is whether your claim preparation process is designed to get it out.

This is why SR&EDgpt's structured interview approach asks the questions that map directly to each denial pattern:

• What didn't you know? (Pattern 1)
• What did you hypothesize and test? (Pattern 2)
• What did you learn? (Pattern 3)
• How did you spend your time? (Pattern 4)
• Why weren't standard approaches sufficient? (Pattern 5)

Every question exists because a specific denial pattern exists.

The Bottom Line

SR&ED denials are almost never about the quality of the R&D. They're about the quality of the claim.

The five patterns in this whitepaper account for the vast majority of denials we've reviewed. Every one of them is preventable with the right questions asked at the right time.

The difference between a denied claim and an approved one is rarely the underlying work. It's whether the narrative gives a CRA reviewer enough specific, technical, well-structured information to say yes.

If you've been denied before, look at your T661 through the lens of these five patterns. Chances are, the problem is in the framing, not the work.