The SR&ED audit rate is low. CRA reviews roughly 12% of claims in any given year. But that statistic masks a useful nuance: the audit rate isn’t uniform. Certain claim characteristics trigger review far more reliably than others.
Companies that get audited are not, in most cases, companies that filed fraudulent claims. They’re companies that filed legitimate claims with documentation that didn’t hold up to scrutiny, or that showed patterns CRA recognizes as worth examining. Understanding those patterns is the most useful thing you can do to protect a legitimate claim.
What Triggers a CRA Review
CRA uses both risk-based selection and random sampling. The random component means no claim is fully immune. But the risk-based triggers are identifiable and addressable.
1. First-time and large-value claims
A company filing SR&ED for the first time is more likely to receive a review than an established filer. CRA’s interest isn’t adversarial. First-time filers make more documentation errors, and a review early in the relationship helps establish expectations.
Claims above certain dollar thresholds also attract more attention. A $50,000 refundable credit claim from a 10-person software company gets more scrutiny than a $15,000 claim from the same company. The threshold for heightened attention varies by business size and claim history.
2. Rapid year-over-year growth in claim value
If your SR&ED claim doubles or triples from one year to the next without a corresponding change in company size or revenue, that delta is a signal. CRA wants claims that grow because the underlying qualifying activity grew. Not claims that grow because someone got more aggressive with what they included.
3. High ratios of SR&ED salary to total payroll
Most software companies allocate 20-50% of their engineering payroll to SR&ED. A company claiming 90% or more will receive scrutiny, because it implies nearly all development work constitutes qualifying research and experimental development. CRA expects that a significant portion of software engineering is routine development, maintenance, and feature implementation that doesn’t qualify.
4. Contractor-heavy claims
Claims where the majority of eligible expenditures are third-party contracts rather than employee wages get flagged more frequently. CRA requires additional documentation for contracted SR&ED work, and the paperwork trail is often incomplete. Arm’s-length and non-arm’s-length contractor expenditures have different rules, and errors in applying them are common.
5. SR&ED work that appears routine from the outside
If your company’s public-facing marketing describes your work in terms suggesting you’re applying known technology (not investigating technological uncertainty) a CRA reviewer may find a discrepancy when comparing that with your T661 technical narratives. “We built a custom machine learning model” and “We provide AI-powered analytics” describe the same work differently. If the public description suggests implementation and the SR&ED claim describes research, that tension invites questions.
6. Industries under elevated scrutiny
CRA periodically focuses audit activity on industries where claim quality has been inconsistent. Software companies, particularly those claiming SR&ED for AI and machine learning work, have been under elevated scrutiny in recent years. The eligibility boundaries in this area are genuinely unclear and frequently misapplied. If your work involves ML, plan for more documentation rigor, not less.
What Happens During an SR&ED Review
Understanding the process makes it less stressful and helps you prepare.
Initial contact. CRA’s SR&ED audit team contacts you, usually by letter, to indicate they’re reviewing your claim. They’ll identify a Research and Technology Advisor (RTA) who will be your primary contact. The RTA is a technical reviewer, not a tax auditor. Their job is evaluating whether the work described in your T661 meets eligibility criteria.
Document request. The review begins with a document request. CRA asks for supporting documentation: your T661 technical narratives, project documentation maintained during the claim period, time records supporting salary allocations, and any third-party contracts.
This is where contemporaneous documentation matters most. If you can produce project notes, commit messages with SR&ED flags, technical meeting notes, and experimental logs from the review period, the RTA’s evaluation is straightforward. If you’re reconstructing everything from memory two years later, the quality shows.
Technical interview. In many reviews, CRA requests an interview with the technical team members who performed the SR&ED work. Not just the accountant or consultant who prepared the filing. The RTA asks engineers to describe what they were trying to accomplish, what they didn’t know how to do at the start, what approaches they tried, and what they learned.
Engineers who can speak fluently to these questions because they were actually doing systematic research are convincing. Engineers who can’t recall the work because an external consultant reconstructed it from Jira tickets are not.
Outcome. Three possibilities: claim approved as filed, claim adjusted (partially disallowed), or claim disallowed entirely. Adjustments are the most common outcome for software companies. CRA typically disallows specific project lines or reduces salary allocations rather than rejecting the entire claim.
You have the right to object. The objection process is formal and involves the appeals division, not the SR&ED audit team. If you have documentation supporting your position, it’s worth pursuing. If the documentation is thin, the fight gets harder.
The Documentation Problems That Drive Disallowance
Most SR&ED adjustments trace back to documentation, not to claims that were fundamentally ineligible. The qualifying work happened. The engineers did face genuine technological uncertainty. The investigation was systematic. But the documentation doesn’t demonstrate that clearly enough.
Vague technical narratives. The T661 requires a description of the technological uncertainty, the work performed, and the advancement achieved. General narratives like “we investigated performance optimization approaches” are less defensible than specific ones: “we investigated whether a distributed caching architecture based on [specific approach] could reduce query latency below [target] for concurrent reads, a constraint that existing published approaches address inadequately under our specific access pattern.”
Vague narratives invite CRA to draw their own conclusions. Specific narratives leave less room for interpretation.
Time records that don’t support salary allocations. CRA requires that salary allocations to SR&ED be supported by time records. The standard isn’t calendar entries or after-the-fact estimates. CRA expects records created during the claim period: timesheets, project tracking data, or other contemporaneous documentation of how engineers spent their time.
A company that allocates 50% of an engineer’s salary to SR&ED but can produce only vague recollections of which projects they worked on will see that allocation challenged. A company that can produce weekly project tracking data showing SR&ED-flagged work for each engineer has a defensible record.
Missing project trails. The best SR&ED documentation reads like a research log: what was the problem, what did we know at the start, what approaches did we try, what did we observe, what did we change, what did we conclude. For software companies, this trail exists naturally if engineers flag SR&ED work in their normal workflow. But it has to be captured at the time, not reconstructed later.
How to Prepare Before You Need To
Companies that come out of SR&ED audits without adjustments almost universally maintained consistent documentation throughout the year rather than assembling it at filing time.
Flag SR&ED work in your existing development workflow. Your engineers already use project management tools, commit messages, and documentation systems. The lowest-friction approach is integrating flags into those existing workflows. A label in Jira, a tag in Notion, a structured field in your sprint review template. Capture the qualifying context when the work happens, not eight months later.
Maintain project-level technical logs. For each SR&ED project, keep a running document capturing the key elements CRA cares about: the technical uncertainty, the hypotheses tested, the approaches tried, observations, and conclusions. This document becomes the T661 narrative foundation. A log maintained throughout the year is both more accurate and more defensible than a narrative written in December.
Track time with SR&ED in mind from the start. If your company uses time tracking, add SR&ED as a dimension. If it doesn’t, consider adding lightweight tracking for engineering work on qualifying projects. The bar isn’t strict timesheets. It’s something better than estimates made 18 months after the fact.
Review your claim characteristics annually before filing. Check the triggers above against your own claim. Is the SR&ED-to-payroll ratio above 70%? Is the claim growing significantly year-over-year? Are you relying heavily on contractor expenditures? If so, ensure documentation for those areas is solid before filing.
Separate out the marginal claims. Every SR&ED filing involves clearly qualifying work, clearly non-qualifying work, and work in between. The marginal work creates risk. If documentation for marginal items isn’t strong, excluding them reduces audit surface area without losing meaningful credit value.
What to Do If You Receive an Audit Notice
Getting a review notice isn’t a crisis. It’s a process.
Respond to CRA’s initial contact promptly, typically within 30 days. Engage the RTA professionally. The technical interview isn’t adversarial. The RTA is trying to understand the work, not trap you.
Gather your documentation before the interview, not during. Know which projects are in the claim, who worked on them, and what technical problem each one addressed. Brief the engineers who will participate.
During the interview, encourage your engineers to be specific. Vague answers about “exploring different approaches” are less compelling than specific descriptions of what was tried, what was observed, and what was ruled out.
If CRA proposes adjustments you disagree with, document your disagreement clearly and request a written explanation of the disallowance rationale. This record is useful if you choose to file a formal objection.
The Connection Between Documentation and Audit Risk
The SR&ED program isn’t adversarial. CRA’s interest is administering the program as intended: supporting genuine R&D investment by Canadian companies. The audit process protects program integrity, not claws back credits from companies doing legitimate research.
Companies that face the hardest audits are usually not the ones that over-claimed aggressively. They’re the ones that did qualifying work, didn’t document it properly, and can’t demonstrate it clearly when asked. The work happened. The credit is legitimate. But the documentation can’t prove it.
Continuous documentation, integrated into your normal engineering workflow, is the most effective audit preparation. And it costs far less than reconstructing documentation when CRA comes calling.
Want to make sure your SR&ED documentation holds up under review? Talk to our team about continuous, automated SR&ED capture from your development tools.