Most SR&ED filers think of CRA reviews as document requests. The reality is that a technical review is closer to a structured engineering interview — and understanding how CRA technical reviewers are trained and what they’re actually looking for can significantly change how you prepare.
Who technical reviewers are
CRA’s SR&ED technical reviewers are credentialled engineers, scientists, or technologists — not generalist tax auditors. They hold degrees in fields relevant to the industries they review: software engineers reviewing tech claims, chemists reviewing materials science claims, mechanical engineers reviewing manufacturing claims. Many have industry experience before joining CRA. They’re trained to spot the difference between genuine experimental development and the application of known techniques.
The review structure
A technical review typically proceeds in three phases. First, the reviewer reads your T661 technical narratives and supporting documentation before making contact. They form an initial hypothesis about eligibility based on the written record alone. Second, they request a meeting — usually a site visit or video call — with the people who actually did the work. Third, they issue a preliminary technical review report with their eligibility conclusions, which you can respond to before the report is finalized.
What they’re actually looking for in the meeting
- Can the engineer or scientist explain the technological uncertainty in specific, technical terms — not business terms? “We needed a faster checkout” is a business objective. “We didn’t know whether the latency target was achievable using standard caching approaches at our data volume” is a technological uncertainty.
- Was the investigation systematic? The reviewer will probe whether the team formed hypotheses, tested them, and drew conclusions — or whether they just tried things until something worked.
- Are the records consistent with the narrative? If your T661 describes a two-year investigation but your version control history shows the solution was committed in week three, that inconsistency will be noticed.
- Does the technical person know the claim? When engineers are surprised by what’s in the T661 — because the narrative was written by a consultant without their input — that’s a credibility problem. The technical team should be able to speak fluently to the claim.
💡 The most common technical review failure: a strong written claim supported by an engineer who can’t explain the uncertainty in plain technical terms. Prepare your technical team before the review — not to script their answers, but to help them articulate what they actually did and why it was uncertain.
How to prepare effectively
Walk your technical team through the claim before the review. For each project, they should be able to answer: What was uncertain? What approaches did we try? What failed and why? What did we learn? What was the outcome? These are not trick questions — they’re exactly the four-part eligibility test, restated conversationally.
Make sure your documentation is organized and accessible. Reviewers appreciate teams that can pull relevant records quickly. Scrambling to locate files during a review undermines confidence in the underlying documentation.
After the preliminary report
If the reviewer proposes to disallow some or all of your claim, you have the right to respond in writing before the report is finalized. This is a genuinely useful step — reviewers sometimes misunderstand technical nuance, and a well-crafted written response addressing their specific concerns can change the outcome. Engage your consultant at this stage if you haven’t already.
