In my years reviewing SR&ED claims at CRA, I saw strong technical work get reduced or denied not because the science was weak, but because the documentation did not support it. The five mistakes below account for the vast majority of those cases. Each one is avoidable — if you know what reviewers are actually looking for.
1. Reconstructing Records After the Fact
This is the most damaging mistake, and it is surprisingly common. Many companies complete their R&D work, then engage a consultant at year-end who asks them to write up what they did. The result is a polished technical narrative that describes the outcome — but reads like it was written after the fact, because it was.
Why it matters to CRA: Contemporaneous records are the gold standard. When a reviewer sees documents created months after the work was completed, with no lab notebooks, version history, commit logs, Jira tickets, or meeting notes from the period in question, the claim becomes very difficult to defend. CRA’s position is that the absence of contemporaneous records raises questions about whether the work was genuinely experimental.
What to do instead: Document as you go. Engineering meeting notes, hypothesis logs, test result summaries, Slack threads saved to a shared drive, annotated code comments explaining what you were attempting — all of this builds a contemporaneous record that a reviewer can trace back to specific time periods.
2. Describing What Was Built Instead of the Uncertainty That Was Overcome
The second most common mistake is writing technical narratives that describe the final product or feature rather than the technological uncertainty that made the work SR&ED-eligible.
Why it matters to CRA: SR&ED eligibility is determined by the uncertainty you faced and the systematic work you did to resolve it — not by how impressive the finished product is. A narrative that says “we built a real-time recommendation engine using a transformer architecture” tells a reviewer nothing about whether there was genuine uncertainty. A narrative that says “we could not determine whether standard transformer attention mechanisms could achieve sub-50ms inference at our required sequence length, and existing literature provided no solution for our specific embedding dimensionality constraint” gives a reviewer what they need.
What to do instead: Structure every project narrative around the technological uncertainty first. What did you not know? Why could you not find the answer in existing knowledge? What hypotheses did you test? What failed, and what did you learn from the failures?
3. Not Documenting Failed Experiments and Dead Ends
Many SR&ED claimants only document their successes. From a business perspective, this makes sense — you want to showcase what you achieved. From a CRA reviewer’s perspective, it is a red flag.
Why it matters to CRA: Genuine research involves failure. If every experiment in your claim documentation succeeded on the first try, the work starts to look more like development using known techniques than experimental investigation under uncertainty. Dead ends and failed approaches are evidence that uncertainty was real.
What to do instead: Keep a record of approaches that did not work, what you expected to happen, what actually happened, and why you moved on. A sentence or two per failed approach, tied to a specific date, is often sufficient.
4. Mixing SR&ED and Non-SR&ED Work Without Clear Segregation
SR&ED claims require you to separate eligible work from routine development. Companies that do not track this distinction during the year often end up either over-claiming (which creates audit risk) or under-claiming (which leaves money on the table).
Why it matters to CRA: If your time tracking, project management records, and payroll data cannot clearly show which activities were experimental versus routine, a reviewer will default to the lower estimate. The burden of proof is on the claimant.
What to do instead: Tag SR&ED activities in your project management tool. Use separate cost centres or project codes for SR&ED work. Have engineers log their time against specific SR&ED projects weekly, not reconstructed monthly. The granularity does not need to be perfect — but it does need to be traceable.
5. Not Connecting Technical Narratives to Specific Financial Expenditures
A strong technical narrative that is not connected to specific, claimable expenditures leaves money unclaimed. Conversely, claiming large dollar amounts without a technical narrative that justifies the scope is a common trigger for a more intensive review.
Why it matters to CRA: The financial and technical components of an SR&ED claim are reviewed together. A reviewer who sees $800,000 in claimed labour costs wants to see technical documentation that reflects roughly that level of effort. Mismatches raise questions.
What to do instead: Map your technical projects to the people who worked on them and the time they spent. Your T661 narratives should reflect the scope of work that your financial data supports — and your financial data should reflect the scope described in your narratives. A good SR&ED consultant will help you build this alignment before filing.
Documentation Is Your First Line of Defence
A well-documented SR&ED claim that accurately reflects genuine experimental work is the most defensible claim. The goal is not to create documentation that looks good — it is to create documentation that accurately reflects what your team actually did. If what your team did was genuinely experimental, good documentation should be straightforward to create as you go.