The Evidence Habit: What to Save Before Year-End
SR&ED claims are significantly easier to defend when you've been saving the right artefacts throughout the year. A practical pre-year-end checklist for Canadian tech companies.
Nine months later, the engineer is gone
Here's a scenario that plays out in too many SR&ED claims: it's Q3, and a founder is trying to reconstruct nine months of engineering work to support a T661 filing. The engineer who did the qualifying work has moved on. The Jira tickets are vague. The Git commits say 'fix' and 'update' and 'wip'. The design doc that existed never made it out of Notion draft.
The underlying work was real. It may well have qualified. But the claim is weak — not because the investigation wasn't systematic, but because there's no record that it was. The CRA distinguishes between contemporary evidence and reconstruction. One defends a claim. The other invites scrutiny.
Contemporaneous evidence is documentation created during the project, not assembled afterward. It doesn't need to be formal. It needs to have existed at the time the work happened — and to show that the investigation was methodical, not accidental.
Breadcrumbs: the only metaphor that matters
Think of SR&ED evidence like breadcrumbs left on a trail. If you drop them as you go, you can retrace the path a year later. If you don't, you're back at the start trying to describe where you walked from memory — and the CRA reviewer wasn't on the walk with you.
The breadcrumbs don't need to be formal. They need to exist at the time of the work, and they need to show the shape of the investigation: what you were trying to solve, what you tried, what you found.
Not useful: a Git commit message that says 'refactor inference pipeline.' Useful: 'Attempted batched inference with ONNX runtime — 3× latency improvement, but memory ceiling hit at batch_size=64 under production load. Investigating quantization-aware approach next.' Same work, same result, very different evidence value.
What CRA considers contemporaneous evidence
- Technical notes and design documents written during development — including drafts and rejected options
- Code commit histories with meaningful commit messages describing what was tried and why
- Issue tracker entries (Jira, Linear, GitHub) showing technical blockers, failed approaches, or unexpected findings
- Architecture decision records (ADRs) and design review notes
- Slack or email threads where technical trade-offs were debated
- Test logs, benchmark results, and records of failed experiments
- Technical post-mortems or sprint retrospective notes mentioning obstacles or unknowns
Volume is not quality. Dumping 400 Jira tickets into your evidence package doesn't help — it dilutes the few that actually matter. A handful of specific, detailed records showing the problem, the approach, the experiment, and the outcome are worth more than a full export of your project tracker.
Pre-year-end checklist — do this in the next 30 days
If your fiscal year is ending in the next quarter, time is your constraint. Here's the minimum viable evidence pass:
- Pull your Git commit log and flag branches or PRs related to genuinely uncertain technical problems — look for repeated attempts, pivots, and outcomes that surprised you
- Export relevant issue tracker tickets where engineers documented blockers, technical decisions, or unexpected results
- Collect architecture diagrams and design documents — including rejected options and early drafts
- Ask engineers who did qualifying work to write a brief technical memo now, while it's fresh: what problem, what they tried, what they found
- Review sprint retrospectives for the past 12 months — any mention of technical obstacles, failed approaches, or unexpected complexity
The 15-minute sprint habit that makes this irrelevant
The better solution is not to collect evidence at year-end — it's to build it throughout the year as a lightweight engineering habit. Once per sprint, one engineer spends 15 minutes noting any significant technical unknowns that arose and how they were resolved. This doesn't require a new process. It's a light layer on top of what most teams already do in retros and design docs.
Keep a running 'technical uncertainty log' — a shared document or wiki page. For each sprint: what technical questions came up that weren't answerable from documentation? What did you try? What did you learn? Over a year, this becomes your contemporaneous evidence base.
The teams that find SR&ED easy at year-end are the ones who weren't thinking about SR&ED at all — they were just building good engineering practices. The evidence was a by-product.
This guide is for general information only. SR&ED documentation requirements depend on the specific facts of each project and may be reviewed by the CRA. All claims should be reviewed by a qualified CPA or SR&ED preparer before filing.
Turn this guide into a claim package
SREDY.IO walks you through eligibility, project narratives, supporting costs, and evidence so your CPA has a cleaner file to review.
More guides
What Actually Makes Software Work SR&ED-Eligible?
Most software companies doing real R&D leave SR&ED credits on the table because they don't recognize their own qualifying work. Here's the eligibility distinction that matters.
T661 WritingPreparing a T661 Narrative Your CPA Can Actually Work With
A T661 project narrative covers technological advancement, systematic investigation, and the technical context that made new knowledge necessary. Here's how each part should read — and what CPAs typically flag.
ComplianceFounder-Friendly SR&ED Filing Deadlines
The SR&ED filing deadline is 12 months after the T2 filing due date — not your fiscal year-end. Here's what that means for your claim timeline, and what happens if you miss it.
Ready to check if your work qualifies? Take the free eligibility assessment.
Check eligibility — free →