SR&ED ACADEMY

DOCUMENTING YOUR WORK

Documentation That CRA EXPECTS


How to Prove Your Claim

So, your developer tells you they spent “weeks on the problem” – do you know if they really did? CRA won’t take that at face value. They want to see the Jira tickets, the timesheets, and the test results that back it up. Documentation is the bridge between what your team did and what CRA will accept.

When CRA reviews your claim, they expect proof. Documentation should show:

  • Technical records → lab notes, design drawings, prototypes, Git commits, Jira tickets, testing logs.
  • Financial records → payroll, invoices, receipts, T4s, contractor agreements.
  • Supporting documents → contracts, meeting notes, project plans, emails, even photos of whiteboards.
Record enough details to make your documentation meaningful. 

Technical records show what you tried. Financial records show what it cost. Linked together, they prove uncertainty, investigation, and advancement and tell the story of how much it cost you to get there! 

Let’s explore key documentation habits that will support your claim:

1. Technical Diaries & Project Logs

Scientific investigation is not the same as standard trial and error. Diaries and logs show that you took an experimental approach and wrote down your hypothesies, what happened, and what you learned. That diary became gold—proof of systematic investigation, not guesswork.

Technical Diaries & Project Logs

One of the simplest ways to stay audit-ready is a technical diary or project log:

  • It doesn’t need to be complicated —just consistent.
  • Record uncertainties, tests, results, and lessons learned.
  • Ensure all ‘sred-eligible’ activities are logged.
Action Steps
  • Create a lightweight template for technical diaries (hypothesis → test → result → next step).
  • Log experiments as they happen and review/update at least quarterly (monthly is even better).
  • Store diaries in a shared, secure and searchable location.
  • Save “small but meaningful” evidence (whiteboard photos, meeting minutes) alongside entries.
Potential Pitfalls
  • Recording only final successes and ignoring failed attempts (CRA wants the process).
  • Treating the diary as optional—missed logs weaken your claim.
  • Reconstructing entries long after the fact.
  • Leaving documentation scattered across emails and sticky notes.

2. Align Technical & Financial Records

Common audit red flag: your report says five engineers worked on prototypes, but payroll shows only three. That mismatch gets attention fast. The best claims tell one consistent story across technical and financial records.

Align Technical & Financial Records

CRA will compare your technical story to your financial numbers. If they don’t match, that’s a problem.

  • Claim 5 engineers in the technical report? Payroll and timesheets must reflect it.
  • Claim $40,000 in contractor costs? There should be agreements and invoices tied to specific technical activities.
Action Steps
  • Cross-check payroll/time records against technical reports each quarter.
  • Tag contractor invoices to specific SR&ED activities (not generic “dev work”).
  • Link material receipts directly to experiment logs or prototypes.
  • Review whether technical narratives and financial data tell the same story.
Potential Pitfalls
  • Reporting work in the technical section without financial evidence to back it up.
  • Claiming payroll without time tracking that shows SR&ED percentages.
  • Misclassifying routine operating costs as SR&ED.
  • Technical vs. financial mismatches (e.g., 4 engineers in the report, 2 in payroll).

3. Create (Easy) Systems & Teach Good Habits

Think about the difference between keeping receipts in a shoebox versus logging them as you go. One leaves you scrambling at year-end; the other leaves you audit-ready. SR&ED documentation works the same way. The strongest claims come from teams that learn good record-keeping habits and build them into everyday routines.

Create (Easy) Systems & Teach Good Habits

Creatre simple, easy-to-follow systems— and make sure your team follow it and understand why they’re doing it.

If your team sees documentation as “extra admin work,” they’ll skip it. If they see it as fueling innovation funding, they’ll take it seriously.

  • Strong system → Jira ticket shows problem, approach, test, outcome (with hours linked).
  • Weak system → “Problem fixed.”
Action Steps
  • Bake record-keeping into existing team rituals (standups, sprint reviews).
  • Use tools your team already knows (Jira, Git, spreadsheets) instead of adding clunky new ones.
  • Run short training sessions to explain why accurate logs matter to SR&ED funding.
  • Encourage real-time logging—don’t wait to reconstruct later.
Potential Pitfalls
  • Year-end reconstructions that miss key details.
  • Over-engineered systems nobody actually uses.
  • “We remember what we did” without written proof.
  • Rudimentary tools (Trello/Slack chatter) that don’t capture time or outcomes.

Exercise: Build Your Documentation and Training Plan

Every company’s setup will look a little different. A biotech lab might use lab notebooks; a software team leans on Git and Jira.

What matters is a plan your team will actually follow.

Use the SR&ED Documentation and Training Plan Worksheet to design a system that works for your business.

CRA doesn’t prescribe a single format for documentation, but they do require clear evidence to support uncertainty, systematic investigation, and advancement.

Check the official CRA page here:

SR&ED Supporting Documentation

Action Steps

  • In the next section, we’ll explore the steps to take to pull all the pieces together and build your claim package.