How to prepare an SR&ED claim that survives a CRA review.

A Scientific Research and Experimental Development (SR&ED) claim is a self-assessment, which means the Canada Revenue Agency can review it after you file. A review is not an accusation, it is the program working as designed, and a well-documented claim moves through one without drama. A thin one does not. The difference is almost always the records you kept while the work was happening, not the cleverness of the write-up afterward.

Why claims get reviewed

The CRA reviews claims to confirm two things: that the work meets the SR&ED definition, and that the amounts claimed are supported. Software claims draw attention when the technical story is vague, when the dollars look large relative to the company, or when the documentation appears to have been assembled at year-end rather than kept along the way. You cannot control whether you are selected. You can control whether you sail through.

The technical narrative

The heart of the claim is a short technical narrative for each project, and the CRA wants it to answer three questions in plain technical language:

1. What was the technological uncertainty? What did you not know how to do, that standard practice could not resolve.
2. What did you do about it? The hypotheses you formed, what you built and tested, and how you iterated.
3. What did you learn? The technological advancement you were after, whether or not the project succeeded.

Write it for a technical reviewer, specific and concrete. Avoid marketing language about how innovative the product is; the CRA is assessing the engineering work, not the business. The narrative should read like an engineer describing a hard problem, because that is exactly what it is.

Tracking time and cost

The largest part of most software claims is staff wages, so the credit is only as solid as your record of who worked on the eligible projects and for how long. The CRA expects a reasonable, supportable basis for the time allocated to SR&ED. That does not require a stopwatch, but it does require more than a year-end guess. Light, regular time tracking against projects, even at the level of a weekly percentage estimate logged at the time, is far stronger than a number reconstructed in spring from memory.

The same logic applies to the new eligible cloud-computing costs: keep the invoices and a reasonable basis for the share tied to eligible experimentation, not general production.

The three working papers we keep

On every claim we maintain three working papers, because they answer the three questions a reviewer asks:

When these three line up with each other and with your accounting records, a review is a confirmation exercise. When they do not, it becomes a negotiation you are likely to lose.

Contemporaneous beats reconstructed

The single most important word in SR&ED documentation is contemporaneous, meaning created at the time the work happened. Code commits, design docs, test results, sprint records, and dated notes about technical problems are gold, because they are evidence the work occurred as described. A narrative written months later, unsupported by anything from the actual period, is the weakest possible position. You do not need to create new artifacts for the CRA; you need to keep the ones your team already produces and tie them to the claim.

The work of surviving a review happens during the year, not at filing. The companies that breeze through are the ones whose books and project records were built for it from the start.

If you do get reviewed

A review usually means a request for the technical and financial documentation, and sometimes an interview with the people who did the work. Respond on time, keep the technical staff involved (they, not the finance team, can speak to the uncertainty), and lean on the three working papers. A claim built on contemporaneous records and a clear narrative is defensible, and most well-prepared claims are accepted with little or no adjustment.