The CRA has been explicit about this: documentation is the single most important factor in whether an SR&ED claim is accepted. Good documentation doesn’t need to be extensive or created for the purpose of the claim — it needs to be contemporaneous, meaning created as the work happened rather than reconstructed at tax time.
Core Categories of Evidence
Project planning and design records
Design notes, requirement documents, hypotheses about why an approach might work, and records of the alternatives considered before starting.
Testing and results
Test plans, lab notebooks, prototype iterations, benchmark results, and version history showing how the approach evolved.
Technical discussion records
Meeting notes, emails, or tickets discussing technical obstacles, failed approaches, and decisions made in response to unexpected results.
Time and resource tracking
Time allocated to specific projects or technical activities, ideally tracked by task rather than reconstructed from memory.
Financial records
Payroll records for staff involved, contractor invoices, and material costs tied to the experimental work, supporting the expenditures claimed on the T661 form.
Software-Specific Evidence
- Version control history and commit messages describing why changes were made, not just what changed
- Architecture decision records and design discussions
- Bug reports and issue tickets describing unpredictable behaviour and the investigation that followed
Build the Habit, Not Just the Claim
The businesses with the strongest SR&ED claims aren’t the ones that scramble to document everything before filing — they’re the ones whose normal engineering workflow (tickets, commits, design docs, lab notes) already captures this evidence as a byproduct of doing the work. A short documentation habit built into the project cycle removes most of the year-end effort.
