Two ways to arrive at a narrative
Written at the time, or reconstructed afterwards: only one holds up under questions
Every claim ends up with the same thing on paper: a description of the technical uncertainty and how it was resolved. But there are two very different ways to get there. One is writing it up as the work happens, or shortly after, from notes, decisions and results that already exist. The other is sitting down once someone decides to claim and reconstructing what probably happened from memory. Both can produce a narrative that reads fine. Only one of them holds up if HMRC asks questions.
What HMRC actually says
Record-keeping is meant to happen alongside the work, not afterwards
HMRC's own compliance guidance for R&D claims is direct about this, and adds that there's no requirement to use a specific template or system, just to be able to identify the qualifying projects and the qualifying costs from what exists (see HMRC's Guidelines for Compliance, GfC3, part 5, on claims and record-keeping). The guidance is also explicit that a bare assertion isn't enough on its own. A claim that simply states the project qualified, without explaining the extent of the work, the specific uncertainty and how it advanced things, doesn't meet the bar. Retrospective identification is acknowledged as something that happens, but the same guidance is honest that without contemporaneous records, it's harder to show a project existed and harder to show the expenditure behind it qualifies.
What good evidence actually looks like
Most of it already exists inside normal project work
None of this requires a formal R&D log kept for its own sake. It just needs keeping rather than throwing away:
- Project notes and decision logs from when the work was happening, not summarised weeks or months later.
- Records of approaches that didn't work. Failed attempts and dead ends are often the clearest evidence that genuine uncertainty existed. A smooth, linear account with no false starts can read as reconstructed even when it isn't.
- Who was involved and what they actually did: roles and expertise that connect specific people to the qualifying work, not just a team name.
- Test results, version history, meeting notes, email threads: whatever ordinary project documentation already captures the reasoning, rather than a purpose-built claim document.
Where reconstructed narratives fall down: a summary written after the fact tends to smooth the story out. The uncertainty gets described as more obviously "a problem to solve" than it actually felt like at the time, and the eventual solution starts to read as the only path that was ever considered. That's a natural effect of hindsight, not dishonesty, but it's exactly what makes a reconstructed narrative read as generic under scrutiny. Genuine uncertainty usually left a messier trail than the tidy version suggests.
Generic versus specific, on the page itself
"We tried several approaches" tells HMRC nothing. Specificity is what protects a claim
The difference shows up directly in how a narrative reads. "We investigated several approaches before identifying a solution" could describe almost any project and tells HMRC nothing. "We tried X, which failed because of Y, then tested Z, which addressed Y but introduced a new problem with performance under load that we hadn't anticipated and had to resolve separately" is specific enough to only describe one actual piece of work. The Additional Information Form asks for exactly this level of detail, project by project (see what it requires for the full breakdown).
Decision helper
Alternatives and limitations
This page covers what evidence needs to look like, not how to write the claim narrative itself or work out qualifying costs. See filing your own R&D claim for the full process, or R&D claim services if you'd rather have specialist help. If your concern is that a small claim won't get taken seriously because of size rather than evidence, that's a separate question, covered in is my R&D claim too small.
