Contemporaneous documentation: what reviewers actually look for

Reviewers of R&D claims, whatever the country, are trying to answer a short list of questions. Was there a real technical unknown? Did the people claimed actually work on it? Do the costs reconcile? Is the story the same in every document? Records that answer those questions quickly end reviews quickly. Records assembled to look impressive do not.

The first thing a reviewer reads

Usually the technical narrative, then the earliest dated document for the project. The reviewer is checking whether the narrative was written from the evidence or the evidence was arranged to fit the narrative. A design note, ticket or meeting record that predates the work and states the unknown is the single most persuasive item in a file. If the earliest document is dated after the claim period, the reviewer will assume reconstruction and test everything else harder.

What convinces

• Dated statements of uncertainty. "We do not know whether approach A can meet the latency target" written in March beats a polished explanation written in December.
• Evidence of alternatives and failures. Branches abandoned, prototypes that did not work, test runs that failed. Success alone proves nothing about experimentation; failure proves a great deal.
• Names attached to work. Commit authors, ticket assignees, lab notebook signatures, sprint records. The reviewer wants to see that the people in the cost schedule appear in the technical record.
• Numbers that reconcile. Wages that tie to payroll, allocations that tie to time records, supplier invoices that tie to the ledger. A reviewer who finds one figure that does not reconcile will check all of them.
• Consistency. The narrative, the registration or form, the cost schedule and the underlying documents tell one story with the same project names and dates.

What raises doubt

• Narratives that describe the product rather than the problem.
• Round-number time allocations applied to whole departments.
• Identical wording across several projects, or across several years.
• Technical documents with no dates, no authors, or file metadata showing they were created during claim preparation.
• Claims for the entire cost of a commercial project with no attempt to carve out routine work.
• A technical lead who, when interviewed, does not recognise the narrative.

How a review typically runs

Reviews commonly begin with a written request for project descriptions, cost schedules and supporting evidence. Answer the questions asked, in order, with references to specific documents. Do not send everything. A well-indexed response of thirty pages is read; a data dump of three thousand is sampled, and the sample is chosen by the reviewer.

If the review proceeds to interviews, the reviewer wants to speak to the people who did the work. Prepare them by walking through the narrative and the evidence, not by scripting answers. A technical lead who explains the uncertainty in their own words, refers to real documents, and concedes the parts that were routine is the best asset a claim has.

The records that settle questions quickly

Question	Record that answers it
Was the outcome uncertain at the start?	Dated project note, design document or kickoff record stating the unknown
Was the work systematic?	Plans, hypotheses, test logs, tickets showing what was tried and why it changed
Who did the work?	Version control, timesheets, sprint allocations, lab notebooks
What did it cost?	Payroll, allocation schedules, supplier invoices, ledger extracts
Where did the R&D end?	A milestone or release note recording that the unknown was resolved

Building the habit

None of this requires new systems. It requires that the records engineers already create are dated, attributed, kept, and linked to a project name that finance also uses. Our guide to documenting R&D as you go sets out a routine for the year. The documentation module in the academy programs covers how to build and keep these records.

Educational material, not advice. Review practice varies by authority and case.