Learn
Documentation requirements
Proper documentation is the foundation of a successful SR&ED claim. With ~20% of claims audited annually, the records you keep today determine whether your credits survive a CRA review tomorrow.
90%
of claims are accepted as filed when documentation is solid
4%
of claims are denied entirely — poor documentation is the #1 cause
$200M
gap between claimed and allowed ITCs each year
The Framework
Three things CRA checks
Miss any one of these and your claim is at risk. Here's what auditors look for.
Establish Eligibility
It's important to show not only 'What' was done, but also 'Why' and 'How'. The best case for this is an Objective, Approach, and Outcome. This will build a technical narrative.
Identify Extent
There should be some direct method to connect SR&ED to actual expenses, typically through activity-tracking, and ideally showing hours spent on eligible work. This is the financial backbone of your claim.
Record Contemporaneously
Documentation should be a natural part of your R&D process. It's much easier to show that your experiments were meaningful if there was real-time data about them as work progresses.
Required Information
Six elements of compliant documentation
Every SR&ED claim should be supported by documentation that addresses these six key areas. The first two apply at the project level; the remaining four capture the iterative work.
Common mistake: Companies show CRA the finished product and expect applause. CRA wants to see the dead ends, the failed experiments, the iterations. Show the journey, not just the destination.
Technological advancement sought
What new knowledge or capability were you trying to achieve? Define the objective clearly.
State-of-the-art baseline
What was the existing level of technology or knowledge when the project began?
Technological uncertainties
What specific technical problems or unknowns did you encounter that couldn't be resolved through standard practice?
Hypotheses or ideas tested
What approaches did you consider? Document the reasoning behind each hypothesis.
Work performed
Detailed records of the systematic investigation — experiments, prototypes, testing, iterations, and methodology.
Test results and conclusions
What did you learn? Document outcomes, whether the hypothesis was confirmed or not, and next steps taken.
Evidence Types
What counts as documentation?
CRA accepts many forms of evidence. The key is that records are contemporaneous, correlated to SR&ED work, and show the nexus of activity, performer, and time.
Time Records
- Timesheets & time logs
- Sprint/project tracking
- Calendar entries
- HR records
Technical Records
- Design documents
- Architecture diagrams
- Test plans & results
- Code review notes
Communication
- Meeting minutes
- Emails about R&D
- Slack/Teams messages
- Standup notes
Development Artifacts
- Git commit history
- Jira/Trello tickets
- CI/CD logs
- Pull request reviews
Best Practices
Key documentation tips
Simple habits that separate claims that sail through from claims that get picked apart.
Timesheets are your #1 priority
Wages are usually the biggest line item on your claim. An unambigous record that connects working hours to SR&ED expenses, your labour expenses will be challenged at audit.
Weekly summaries work well
Biweekly or weekly supervisor summaries capturing work performed, testing methods, challenges, and team hours are highly effective. These are easy to maintain and CRA loves them.
Document failures, not just successes
Failed experiments are often the strongest evidence of SR&ED. They demonstrate genuine technological uncertainty and systematic investigation.
Leverage your existing tools
We provide guidance for documenting SR&ED in Jira, Trello, Git, Confluence, and can work with any other tools your team already uses. No need to adopt new systems or install weird plugins.
Keep records in real-time
Retrospective documentation is one of the top reasons claims are denied. Make documentation a natural part of your development workflow, not an afterthought.
Separate SR&ED from routine work
Clearly delineate which portions of a project involve technological uncertainty vs. standard engineering. Not everything in a project qualifies.
Stop scrambling at claim time
Get help setting up documentation processes inside your existing tools — Jira, Git, Confluence, Slack — so evidence gets captured while your team works, not reconstructed six months later.