When the CRA selects an SR&ED claim for review, the first thing the Research and Technology Advisor reads is the technical narrative: the project descriptions in Part 2 of the T661. Long before anyone looks at your payroll records, the narrative has already framed how defensible your claim looks.

Reviewers read for three things

The SR&ED legislation asks a deceptively simple question: did you attempt to resolve a technological uncertainty through systematic investigation, seeking a technological advancement? A narrative survives review when those three elements are unmistakable:

  • Technological uncertainty. What could you not predict or resolve using standard practice? “It was hard” is not uncertainty. “Publicly available knowledge and our own experience could not tell us whether X was achievable within constraints Y and Z” is.
  • Systematic investigation. What did you hypothesize, attempt, measure, and conclude? Reviewers look for iteration, a sequence of experiments or analyses, not a description of the finished product.
  • Technological advancement. What do you now know that you didn’t? An advancement can be modest, and a failed experiment still qualifies, you advanced knowledge by ruling something out.

The most common failure mode

Most rejected narratives fail the same way: they describe the business project instead of the SR&ED project. A new product launch is a business outcome. The SR&ED project is the subset of work where your team confronted a problem standard engineering practice couldn’t solve. Write about the struggle, not the feature list.

Write it from the evidence, not from memory

A narrative reconstructed from memory ten months after year-end reads like marketing. A narrative assembled from commit messages, test logs, design revisions, and meeting notes reads like engineering, because it is. This is also why the strongest claims come from companies that document as they go: the narrative practically writes itself, and every sentence has a record behind it.

Three structural habits that help

  1. One uncertainty per project description. If you tackled several distinct uncertainties, describe them as distinct lines of investigation rather than blending them into one vague story.
  2. Chronology over abstraction. “We hypothesized A, built B to test it, observed C, and revised our approach to D” is the shape reviewers trust.
  3. Plain language. The reviewer may not share your exact specialty. Jargon hides the logic of the investigation; clarity exposes it, in your favour.

The narrative is the claim. Costing gives it a number, but the narrative decides whether that number gets defended in an afternoon or argued over for a year.