The CRA is moving toward requiring contemporaneous evidence for SR&ED claims — documentation created during R&D work, not reconstructed from memory at tax time. They’ve been signaling this for a while, but a February 17, 2026 CRA SR&ED webinar made the direction explicit.
The shift: contemporaneous evidence
Time tracking has to be specific. Weekly timesheets broken down by SR&ED project. “Sarah was roughly 30% R&D” doesn’t work anymore. They want actual buckets — admin, sales, marketing, Project A, Project B, bug fixing — tracked week over week. (The T4088 guide walks through exactly how to allocate salary costs.)
Artifacts matter more than narratives. The CRA name-dropped git commits, Jira tickets, lab notes, and design docs as the kind of evidence they’re looking for. Things that exist because the work happened — not because someone wrote a summary after the fact. Failed experiments are especially valuable. They’re what prove systematic investigation actually occurred.
Appendix 2 of the T4088 guide lists every type of documentation the CRA considers relevant to an SR&ED claim. It’s the closest thing to a checklist you’ll get from the government.
Business language is a red flag. If your T661 reads like a pitch deck, expect a phone call. The CRA wants to hear about technological uncertainty and systematic investigation. Not feature launches and engagement metrics.
Why now? Blame AI.
Part of this is a direct response to AI-generated claims. It’s now trivially easy to produce a convincing-sounding technical narrative with ChatGPT. The CRA knows this. Their counter: demand evidence with real timestamps from real tools — commit histories, Jira tickets, weekly timesheets — that corroborates the narrative rather than replacing it.
How claims actually get reviewed
Stage one: desk review. A non-technical administrator reads your claim. They’re checking for completeness, consistency, and red flags. They’ve read thousands of these. If the story makes sense and nothing looks off, it passes.
Stage two: technical review. If something gets flagged, a Research Technology Advisor digs in. They’ll review your narratives in detail and probably schedule a meeting. This is where weak claims die.
The CRA published their full review process guide for claimants. It walks through what to expect before, during, and after a review — worth reading before you file, not after you get the call.
About 20% of claims get some level of scrutiny. Strong contemporaneous docs keep you in the 80% that sails through. Weak docs put you in the group that has to explain themselves.
What triggers the escalation: six-figure claims, big year-over-year jumps, business-speak instead of technical language, and — the big one — no contemporaneous documentation.
What “good” documentation looks like
The CRA’s own T661 guidance tells you exactly what they want for each section:
- Uncertainty (Line 242): What was technologically unknown before you started? Meeting notes, protocols, technical specs. These should exist before or at the start of the R&D work.
- Systematic investigation (Line 244): What did you try? What failed? What did you change? For software: commit histories showing iterative approaches, tickets documenting technical pivots, architecture reviews, design docs.
- Knowledge gained (Line 246): What did you learn — including what you learned doesn’t work?
All of it should exist because the work generated it, not because someone wrote it up for the claim.
The hidden cost of doing it retroactively
Audit risk aside, the retroactive approach has a more basic problem: you forget things.
The work that’s hardest to reconstruct retroactively is often the most SR&ED-eligible: failed approaches, abandoned architectures, and iterative debugging cycles. These demonstrate the systematic investigation the CRA looks for on Line 244 — but they’re also the first things that lose detail over time. A commit message from July that says “reverted: latency 3x over threshold with event-sourced approach” is concrete SR&ED evidence. A developer’s recollection in February that “we tried a few things before the current approach worked” is not.
Five changes to make before your next claim
Five things, in order of impact:
- Track time at the project level, weekly. This is the single most impactful change. It doesn’t need to be onerous — but it needs to be specific and consistent. Set up buckets in whatever tool you use: R&D Project A, Project B, bug fixing, admin, client work. Done.
- Connect the dots between your existing tools and SR&ED. Your GitHub, Linear, Jira, Notion — these already generate exactly the contemporaneous evidence the CRA wants. The trick is tying that evidence to SR&ED projects instead of letting it sit disconnected.
- Capture uncertainty in real time. When your team hits a problem they don’t know how to solve, that’s a potential SR&ED moment. When they try something and it doesn’t work, that’s evidence of systematic investigation. Even a quick note in a ticket — “tried X approach, latency was 3x over threshold, reverting” — is gold.
- Separate R&D language from product language. Same work, different framing. Your standup says “shipped the recommendation engine.” Your SR&ED docs say “investigated collaborative filtering approaches for sparse user-item interaction matrices.” Train yourself to think in both frames.
- Stop treating SR&ED as an annual filing exercise. The CRA is telling you, explicitly, that they want year-round documentation. The companies that adapt to this will file stronger claims with less effort and way less audit risk.
You have exactly 18 months from your fiscal year-end to file your SR&ED claim. No extensions, no exceptions — it’s written into the Income Tax Act. Miss it by one day and you forfeit the entire year. Aim to file with your corporate tax return (within ~6 months of year-end) to avoid amendment risk.
The $4.5 billion sitting in this program every year isn’t going anywhere. But the bar for claiming it is rising. The good news: if you’re already building with modern dev tools, you’re already generating most of the evidence you need. You just need to capture it.