A clean SR&ED claim for a CCPC moves through the CRA in 60 to 120 days. A flagged claim adds 6 to 12 monthsof back-and-forth, technical interviews, document requests, and — more often than not — a partial denial of the credit you were counting on. The frustrating part: the patterns that trigger reviews are predictable. We've seen the same five mistakes show up in claims year after year, and almost all of them are avoidable before you ever hit submit.
This is the blunt version of the conversation we have with every new SR&ED client in their first meeting. If your last filed claim contains any of the patterns below, you're running hotter than you need to. If your next claim contains them, you're asking for a review.
Mistake #1 — Treating the technical narrative as a marketing document
The single most common reason a CRA reviewer flags a claim is a technical narrative that reads like it was lifted off the company homepage. The CRA isn't scoring you on features shipped, product polish, or how impressive the platform sounds. They're looking for the program's actual eligibility criteria: scientific or technological uncertainty, a hypothesis, a systematic experimental approach, and results that advanced knowledge.
A narrative full of phrases like “state-of-the-art,” “industry-leading,” or “we built a scalable platform that...” signals to a reviewer that the author hasn't engaged with the program rules. That triggers a closer look at everything else in the claim.
Compare these two phrasings of the same work:
The second version doesn't sound as good in a pitch deck. It sounds exactly right to a CRA reviewer. Write for the reviewer, not for investors.
Mistake #2 — Claiming routine work as eligible
Database migrations. Framework version upgrades. UI redesigns. Well-trodden third-party API integrations. Standard mobile app rebuilds in a new language. These are the activities every software company does, and they are notSR&ED-eligible — no matter how much engineering effort they consumed.
Reviewers see the same patterns across hundreds of claims in the same sector each year. They have an internal sense of what every SaaS company is putting forward, and when your claim leans heavily on the well-known list, it draws scrutiny. Worse, even if the reviewer ultimately allows some of the work, they'll often re-examine the rest of the claim with a sharper eye.
The honest move is to cut the ineligible work before you file:
- Migrating from MySQL to Postgres because the team prefers it → not eligible.
- Building a novel sharding layer because off-the-shelf solutions failed under your specific workload → potentially eligible, with the right narrative.
- Rebuilding the iOS app in Swift because Objective-C is dated → not eligible.
- Integrating Stripe's standard API → not eligible.
- Reverse-engineering a workaround for an undocumented edge case in a payment provider's API after their support team couldn't resolve it → may be eligible with documentation.
A smaller, defensible claim that reflects real R&D will process cleanly. A bigger claim padded with routine work attracts the review that costs you the refundable cash.
Mistake #3 — Time allocation that doesn't add up
Time allocation is where many claims fall apart under scrutiny. The two failure modes we see most often:
The unrealistic individual percentage.An engineer claimed at 85% SR&ED whose git history, Jira tickets, and Slack activity show mostly code review, on-call rotations, hiring loops, and standard feature delivery. When the CRA asks for a breakdown of that engineer's actual time and gets a retroactive guess that doesn't match the visible record, the whole claim's credibility takes a hit.
The salary math that doesn't reconcile. Allocations across a team that, when summed, exceed any individual's total compensation or working time. One client came to us with a prior claim where four engineers' allocations totalled the equivalent of 480% of one full-time year. A reviewer needed about ninety seconds to spot it.
The CRA increasingly cross-references claimed time against role descriptions, LinkedIn titles, and public engineering output (commit history on open-source contributions, conference talks, blog posts). You don't need to track every minute, but you do need contemporaneous records — even a monthly per-project log in a spreadsheet beats a year-end reconstruction. Allocate conservatively; a defensible 55% beats an indefensible 85% every time.
Mistake #4 — Contractor and arm's-length confusion
Contractor treatment is the fastest way to drag your claim into a financial review (which is separate from, and often runs parallel to, a technical review). Three subtleties matter here:
Arm's-length vs non-arm's-length.An arm's-length contractor — an independent shop or freelancer with no ownership or family relationship to your company — generally has roughly 80%of their qualifying payments included in your SR&ED expenditure pool. A non-arm's-length contractor — a related party, an affiliated company, a co-founder's consulting LLC — is treated far more restrictively. Mixing the two up, or failing to flag non-arm's-length relationships at all, is a common trigger for a financial review.
The Canadian-work rule.SR&ED is a credit for R&D performed in Canada. Claiming the full bill rate of a US-based contractor for work physically performed in the US is not eligible. Claiming a Canadian contractor for work performed on a Canadian-incorporated client's project, in Canada, is eligible — but the documentation has to support it.
The contract structure.A contractor who behaves like an employee — fixed hours, company laptop, daily standup, ongoing direction — may be reclassified by the CRA as an employee for SR&ED purposes. That changes how their cost flows through the claim and can shift you out of the contractor bucket altogether.
Get any of these wrong and the CRA can disqualify the entire contractor pool in your claim — not just the problematic line items. Separate arm's-length from non-arm's-length on the schedule, confirm work location for every contractor, and keep the contracts themselves on file.
Mistake #5 — Filing late, then filing thin
The SR&ED filing deadline is 18 months from your fiscal year-end. It is absolute. There is no extension, no “late but with cause” exception, no appeals process to reclaim a missed deadline. Miss it by a day and the entire year's claim is gone.
The pattern we see far too often: a company realises in month 16 or 17 that they haven't filed, scrambles a thin claim together from memory, and submits something that the reviewer immediately flags for missing documentation. The narrative is rushed. The time allocations are guesses. There are no contemporaneous records. Half the project descriptions have been reconstructed from a Notion page someone updated quarterly.
From the CRA's perspective this is a textbook review candidate. From your perspective you've now spent legal and consulting time defending a claim that should have processed automatically.
The rule of thumb we give every client:
- Months 1–6 after year-end: file here. Documentation is fresh, the team remembers what they worked on, and the CRA processes well-prepared claims in this window quickly. CCPC refunds can hit the bank account inside 90 days.
- Months 7–12:still fine, but the documentation cost goes up. Engineers have moved on, repositories have churned, and you'll spend more on the consulting work.
- Months 13–18:risky. Even a careful claim here looks like a rush job to a reviewer, and you've given yourself no buffer if anything goes wrong with the filing.
What clean claims look like
The inverse of each mistake is a checklist any technical founder can run before filing:
- The narrative leads with uncertainty, hypothesis, experiment, result — not with product features.
- The claim includes only work that genuinely advanced technological knowledge. Routine engineering has been cut out entirely, not buried in.
- Time allocations per person are conservative and supported by contemporaneous records — even lightweight monthly logs.
- Contractors are split clearly into arm's-length and non-arm's-length on the financial schedule. Canadian work is documented. Bill rates and work locations are on file.
- The claim is filed in the first six months after fiscal year-end, with full supporting documentation attached.
Claims that meet all five conditions almost never get reviewed. That's not a guarantee — the CRA samples some clean claims randomly — but the base rate of trouble drops sharply.
Next steps
Two things to do this quarter, especially if you have a fiscal year-end coming up:
- Audit your last filed claim against the five mistakes above.Read the technical narrative as if you were a CRA reviewer who has seen a thousand SaaS claims this year. Where would they push back? If you're not sure, that uncertainty is itself a signal worth investigating before the next claim.
- Talk to a consultant before your next fiscal year-end, not after. The work to set up clean time tracking, separate contractor categories on your books, and identify eligible projects in advance is straightforward when you have months of runway. It's painful when you're reconstructing it eighteen months later.
If you want a fresh set of eyes on a prior claim, or want to bracket your next year cleanly, see our SR&ED page for how we work, or send us a short message via the contact pagedescribing your fiscal year-end and rough R&D spend. We'll come back with a one-page read on where the risk sits in your current claim and what to fix before the next one.