Software SR&ED: what firms should document before year-end

Most software SR&ED claims that fall apart don't do so for lack of eligible work: they weaken because the evidence no longer exists by the time someone sits down to write. Developers have moved on, the key conversations happened on ephemeral channels, and nobody recorded why a given approach was abandoned. Yet that "why" is exactly what demonstrates the technological uncertainty.

As a firm, you don't have to become your clients' archivist. But a short conversation before year-end, with the right checklist in hand, dramatically changes the quality of the claim you'll build a few months later.

Why act before closing, not after

SR&ED rewards a process: a hypothesis, experiments, results, adjustments. That process is naturally documented as it happens, not from memory. Reconstructing after the fact what was attempted eight months earlier produces a smooth narrative, stripped of the dead ends and iterations that are precisely the heart of eligibility.

Documenting before closing also fixes a point in time. A code commit, a dated ticket or a timestamped email is worth infinitely more than a description written after the fact. Year-end is the natural moment to remind your clients of this reflex.

The six items to have documented

1. The list of projects and their technical intent

For each development initiative of the year, you want one clear sentence: what were they trying to achieve technically, and why was it non-trivial? Not the business value ("improve the customer experience"), but the technological objective ("reduce processing latency below a threshold the existing architecture couldn't reach").

2. The technological uncertainties encountered

This is the most valuable and most perishable item. What was not known in advance? What obstacle couldn't be resolved simply by applying standard practice or existing documentation? Ask your clients to note, even in two lines, the moments when the team said "we don't know whether this is feasible, or how."

3. The approaches tried, including the ones that failed

Unsuccessful attempts are evidence of experimentation, not wasted time. An approach tried and then abandoned, with the reason for abandoning it, demonstrates R&D better than a first-try success. Encourage clients to keep a trace of the paths they dropped.

4. Who was involved and how much time

Who worked on what, and roughly in what proportion? An approximate but honest breakdown of time per project, kept during the year, beats a single estimate made in the spring. It directly supports the calculation of eligible expenditures.

5. The technical artifacts that already exist

Good news: much of the evidence already exists with no extra effort. Version history (Git), tickets and boards (Jira, Linear, Azure DevOps), pull requests, design notes, team messages. It's less about creating documentation than about not losing it and tying it to the right projects.

6. Dated milestones and results

When was the uncertainty resolved, or the project redirected? A few key dates anchor the narrative in the right fiscal year and make it easier to split work across periods.

A simple rule to pass on to clients: if a team member ever said "we don't know how to do this yet," there's probably SR&ED there, and it should be noted while it's fresh.

A year-end email is often enough

You don't need a heavy process. A standard email sent to your technology clients a few weeks before closing, covering the six points above, triggers the right reflexes. For more complex files (AI, large platforms, projects across several teams), it's also the right time to schedule a short technical interview while developers still remember the details.

This is exactly the kind of work I can support: structuring the collection, running the technical interview, and turning raw material into documentation that's ready to defend.