Every new engineer or researcher your company hires is a documentation risk — not because they’re careless, but because they have no reason to know that how they record their work affects a significant government tax credit. Without explicit onboarding, new hires repeat the same undocumented patterns they used at their last job, and your SR&ED claim quietly erodes with each new addition to the team.
Why documentation culture breaks down with growth
In early-stage companies, SR&ED documentation is often held together by one or two people who understand the program and informally prompt the rest of the team. As companies grow and hire faster, that informal network breaks down. New engineers don’t know to write descriptive commit messages. Junior researchers don’t know to log failed experiments. Product managers don’t know that ticket descriptions matter for SR&ED purposes.
The result is that documentation quality often declines as team size grows — exactly the opposite of what you’d expect, and exactly the opposite of what you need as your SR&ED claim size increases.
What to cover in SR&ED onboarding
- What SR&ED is and why it matters to the company: a two-minute explanation of the program, the credit amount, and how the company uses the refund. Engineers who understand the stakes are more engaged with the documentation requirements.
- What good documentation looks like in practice: show examples of engineering notes, commit messages, and ticket descriptions that capture the SR&ED information CRA looks for — and examples of what’s insufficient.
- Your specific documentation tools and practices: which system to use, how often to update it, and who to contact with questions.
- The two questions that matter: “Was there genuine uncertainty about whether this would work?” and “Did we experiment systematically to find out?” If yes to both, document it in detail.
💡 Keep the onboarding session under 20 minutes. The goal is not to make engineers into SR&ED experts — it’s to build two or three specific habits that become automatic. Simplicity improves compliance.
Building documentation into existing workflows
The most effective SR&ED onboarding doesn’t create new processes — it modifies existing ones. Walk new hires through the tools they’ll actually use (Jira, GitHub, Notion, Confluence) and show them specifically how to use those tools in ways that support SR&ED documentation. A well-placed field in your ticket template, a convention for commit messages, or a section in your sprint retro template can do more for your SR&ED claim than any standalone documentation system.
Refreshers for existing staff
Onboarding new hires is the trigger, but it’s also a good opportunity to run a brief refresher for existing team members. SR&ED requirements evolve, documentation habits drift, and a short annual refresh — ideally timed to early Q1 when the new fiscal year begins — resets expectations and reinforces the habits that matter.
Making it part of performance expectations
Some companies formalize SR&ED documentation as part of engineering job expectations — a specific line in job descriptions, a check during performance reviews, or a recognition for engineers whose documentation contributed to a strong claim. This is more common in larger companies but can be adapted at any scale. Where the expectation is explicit, compliance is higher.
