Chances are, you didn’t magically produce your latest innovation in your head – it took hours of prototyping, tweaking and fixing, and some extra help here and there. If you didn’t document those challenges, how are you going to support your work and make a successful SR&ED claim?
To qualify for an SR&ED tax credit, you must show that you attempted to advance technology, you faced challenges and you either achieved your desired outcome or you didn’t (don’t worry, this is okay too). Documentation is extremely important so that you can support your claim, regardless of its size. Document your progress, highlight your challenges, and prove that you and your team went through a systematic process to overcome those challenges.
SR&ED Documentation Requirements
The CRA requires that documentation is:
- Contemporaneous – this means that it is documented at the time the SR&ED work is done.
- Dated – to prove that the work occurred in the fiscal year you are claiming.
- Highlights technological issues/challenges – to support the technical reports that will be submitted with the claim.
These requirements seem simple and straightforward, but can actually be difficult for some teams to stay on top of and record diligently. This is especially true when it comes to software development teams using an agile method to iterate.
Forms of Documentation
Still unsure what counts as adequate documentation? Here are common forms of documentation (that you are hopefully already using) that can be used to support your software SR&ED claims:
Timesheets – all employees involved in R&D should track 100% of their time as well as separate SR&ED and non-SR&ED eligible activities. This will allow the percentage of time spent on SR&ED to be calculated accurately. Include notes in timesheets on activities and technical challenges encountered.
Technical challenges – maintain records on technical challenges faced during development. Include detail on experiments conducted, prototypes created, iterations, testing, and analysis of test results. Include specific metrics as appropriate (i.e. performance was greater than 5 seconds when the limit was 1 second; memory usage was X with only 10 concurrent users). This could be done weekly or bi-weekly.
Version control for all technical documents – use in architecture documents, design documents, as well as source code to track the evolution of the system. Include notes on technical issues when checking files into the version control system.
Software prototypes – save prototypes (possibly in the version control system) and include notes on the analysis of the prototype.
Test documents – save test cases, results, and analysis. Include dates and who performed the testing.
Developer Notebooks – keep all handwritten developer notebooks. Have them include dates on the notes.
Meeting minutes – include the date, attendees, duration of the meeting, point form descriptions of technical issues discussed.
Whiteboard photos – take pictures of software designs created on whiteboards and save with project documentation.
Emails – track email exchanges with labels when relevant challenges were discussed.
In other industries, you can also include product prototypes and associated materials, and engineer notebooks.
SR&ED Documentation Tips
We don’t like to tell companies how to record their work as we find each and every organization and team handles documentation differently. We can, however, provide some successful tips that we’ve experienced during the claiming process:
Don’t underestimate the importance of challenges and notes captured in emails.
Start recording early, even if you aren’t sure if your work is SR&ED eligible yet.
Schedule reminders to create notes in your project management system.
Schedule reminders to record your time at the end of every day.
For software companies, record notes on the source code itself.
- Enlist an internal champion to oversee the process.
So do you really have to document your SR&ED eligible work? Yes, you do. And the more you do, the better your SR&ED claim will be.