The 5 most common mistakes in software SR&ED technical reports

The technical report is where real development work becomes a defensible claim, or weakens. The mistakes below have nothing to do with the underlying eligibility of the project: they're problems of wording and structure that make the eligible work hard to see. The good news: they're all avoidable.

Mistake 1: describing the product, not the uncertainty

By far the most common. The report tells what the software does for users instead of explaining the technological problem that had no known solution. The CRA doesn't fund a feature; it recognizes a technological uncertainty and the process used to resolve it.

The fix: for each piece of work, state explicitly what was uncertain at the outset, why existing approaches fell short, and what technical result you were aiming for. The business value can stay in the background; the technical obstacle must be front and center.

Mistake 2: confusing difficulty with uncertainty

"It was a very complex project, with many hours" is not an eligibility argument. Work can be long, demanding and costly without any technological uncertainty. Conversely, a tightly bounded problem can be highly eligible.

The fix: replace the vocabulary of effort ("complex," "ambitious," "a lot of work") with the vocabulary of uncertainty ("we didn't know whether," "no known approach allowed," "it had to be determined experimentally").

Mistake 3: hiding the failures and iterations

By reflex, people present a clean narrative where everything worked. But the discarded hypotheses, abandoned prototypes and rewrites are the very evidence of systematic experimentation. Hiding them strips the report of its best arguments.

The fix: document the approaches tried, the reason they were abandoned, and what each attempt revealed. It's this path that distinguishes R&D from routine development.

Mistake 4: jargon with no anchors (or the opposite, too vague)

Two extremes hurt equally. A report drowning in technology names and acronyms, without explaining where the problem was, is unreadable to a reviewer. At the other end, a report so generic it could describe any project proves nothing.

The fix: aim for a precise but explained level of technical detail. Name the real constraint (a latency threshold, an accuracy limit, an incompatibility), then show how it resisted standard solutions. Concrete and specific, without being impenetrable.

Mistake 5: a narrative the evidence doesn't support

The report describes work that doesn't match the dates, the version history or the people claimed. In a review, this gap between the narrative and the artifacts is what derails a file.

The fix: anchor the report in verifiable elements (version history, tickets, dated milestones) and make sure the period, the contributors and the claimed effort line up with the expenditure calculation.

A good test before filing: can a reviewer who doesn't know the project identify, just by reading the report, which technological uncertainty existed and how it was addressed? If it isn't obvious, the report needs more work.

A technical eye before filing

In peak season, these mistakes creep in mostly through lack of time, or because no one on the team has the developer background to reframe the technical side. That's where I come in: writing or reviewing technical reports, in support of your firm, so the file faithfully reflects the work and stands up to scrutiny.