Record-keeping & evidence

What records do I need to keep to support an R&D tax relief claim?

Reviewed 2 September 2026

Knowledge bank Record-keeping & evidence

Short answer

No record-keeping rule is written specifically for R&D tax relief. The general Corporation Tax duty to keep records sufficient to deliver a correct and complete return applies, and HMRC expects those records to cover two separate things: the technical case for each project, and the figures behind the cost categories claimed. In practice, an R&D claim is judged on whether that evidence exists and was made close to the time the work happened — not on whether the return itself was filed correctly.

Applies to

Schemes
Merged scheme · ERIS · Legacy SME · Legacy RDEC · All periods
Periods
1 April 2000 onwards
Claimants
All

Why there’s no separate rule for R&D

Companies claiming R&D tax relief are not subject to a bespoke record-keeping regime. They are subject to the same duty as every other company: to keep and preserve whatever records are needed to deliver a correct and complete Corporation Tax return, for as long as HMRC might still enquire into it. HMRC’s own manual makes the same point about R&D claims specifically — there is no special rule, so officers are told to be flexible about what a particular company can reasonably be expected to have, and to discuss with the company or its adviser up front what records exist before deciding what more is needed.

That flexibility cuts both ways. It means a small company without a formal project-management system is not automatically at a disadvantage. It also means there is no checklist you can tick off and call the job done — the standard is simply whether what you kept is enough to show HMRC, if asked, that the figures in the claim are right.

What HMRC actually wants to see

Two different things need supporting, and companies often keep evidence for only one.

The first is the technical case: what advance in science or technology the project was seeking, what made it uncertain, who was competent to judge that, when the work to resolve the uncertainty started, and when it ended or stopped. This does not need to be a formal report. HMRC’s guidance is explicit that for smaller companies “not all of this may be formally documented,” and that officers should look at whatever contemporary evidence is actually available — meeting notes, version control history, correspondence with a client or funder, dated technical decisions — rather than insisting on a document that was never going to exist. See How do I know if I’m doing R&D? and What is a competent professional? for what the technical case actually has to establish.

The second is the cost record: the figures behind each category of expenditure claimed. For staffing costs this means payroll records, a list of who worked on the project, and — for anyone not engaged on it full time — something that shows how their time split between R&D and everything else. For subcontractor and externally provided worker costs, it means invoices and something showing what the work actually was, not just what it cost. For software, data and cloud costs, it means the contracts or bills, plus whatever internal coding shows how much of the spend relates to the R&D project rather than the business generally. Which staff costs can I include in an R&D claim? And what costs qualify for R&D tax relief? Set out the categories this evidence has to support.

Financial records alone do not cover the first. Accounts and VAT records show that money moved and roughly what for; they do not show what proportion of an employee’s time was spent directly and actively on R&D, which is usually the figure the claim actually turns on.

This is not a theoretical checklist. HMRC’s compliance check letters on R&D claims routinely ask, project by project, for exactly this: when each scientific or technological uncertainty was identified, when work to resolve it began, when it was overcome, and for any documents — progress reports, correspondence about individual milestones — that support that timeline. Where those documents don’t exist, HMRC’s own instruction is to say so plainly and explain why, rather than treating the gap alone as fatal. That is a close description of what a genuinely contemporaneous project record looks like: an uncertainty dated when it was identified, work dated when it started, and a resolution dated when it was reached.

Contemporaneous records carry more weight than reconstructions

The closer a record was made to the work it describes, the more it is worth. A technical note written while a problem was live, or a timesheet completed the week it covers, is direct evidence. A narrative or a percentage worked out for the first time when a claim is being prepared — or worse, after an enquiry has opened — is a reconstruction, and reconstructions are inherently harder to rely on: nobody can now check them against anything, including the person who wrote them.

This is not a technicality. A tribunal found against a claim specifically because the estimates behind it — of staff time, materials, and subcontractor costs — were not clearly apportioned and came with no explanation of how they were arrived at, on top of invoice trails that were effectively missing. The problem was not that the company’s work failed the science and technology test; it was that nothing on file could show the figures were right.

There is also another cost, short of losing anything. Reconstructing a project’s history from memory, emails and whatever documents survive — after HMRC has asked for it, project by project and milestone by milestone — routinely takes far longer than logging the same information as it happened would have. A system that captures the timeline once, at the time, spends that effort a single time; reconstruction spends it under enquiry pressure, months or years later, and often more than once as HMRC’s questions narrow.

If your company doesn’t keep formal project records

Most companies that qualify for R&D relief don’t run a document-controlled R&D function — they build something and keep the kind of records an operating business naturally generates. That is workable. The exercise is to identify what already exists that is dated and was created at the time — calendar entries, drawings, test results, git history, emails discussing a technical problem, a manager’s notes from a project meeting — and use that as the backbone of both the technical narrative and the cost apportionment, rather than starting from a blank page once the claim is being written.

What doesn’t change is where the burden sits. The duty to have records that support the return is the company’s, whoever prepares the claim, and “we’ve always claimed and never had a problem” is not itself evidence of anything.

Ways to keep records going forward

A dated note from whoever is technically responsible for the project, written at the point a problem is tackled and again whenever the approach changes materially, is the single most useful habit — it fixes the “when did this start and when did it end” question that the rest of the claim depends on, without needing to be written for an audience.

For time spent, anything that produces a contemporaneous, project-coded record works: a timesheet, a ticketing system with project tags, or a manager’s weekly note of who worked on what. See How do I work out how much of an employee’s time counts as R&D? for how that record is turned into a qualifying figure. Some companies use software built specifically for this — Cadence is one example, aimed at recording R&D time and project activity as it happens — as an alternative to a spreadsheet or a manual timesheet. The requirement is the same regardless of the method used: the record must be made at the time, not reconstructed for the claim.

Worked example

Illustrative. A software company has two developers on a qualifying project for the accounting year.

DeveloperEngagementRecord keptWhat it shows
Developer AFull time on the project, all yearConfirmation of what they worked on and when, cross-checked against the technical narrativeNo apportionment to evidence — the record just needs to confirm the engagement
Developer BSplits the week between the project and unrelated client support workA project-coded time-tracking system, logged weekly, reviewed by their manager and closed once each week endsA contemporaneous 58% split for the year, built up week by week rather than decided once when the claim was drafted

The figure that goes on file for Developer B is the system that produced 58%, not a single number worked out in April when the claim was being written.

Where claims go wrong

  • The technical narrative and the cost apportionment are built for the first time when the claim is drafted, or when an enquiry letter arrives — sometimes a year or more after the work. What results is an estimate produced under time pressure, from memory, with no way to check it against anything made at the time. A tribunal has found against a claim on precisely this basis: the underlying figures were not clearly apportioned and nobody could explain how they had been reached.
  • Financial and accounting records are treated as if they were sufficient evidence on their own. They aren’t. Accounts and VAT returns show that costs were incurred; they do not show what an employee actually did with their time, which is usually the fact the claim depends on.
  • Nobody can say when the project the claim is about actually started or finished, because nothing was dated at the time. A technical narrative written months later that asserts a start date is not evidence of that date — it’s an assertion, and it can’t be tested against anything if HMRC asks.

Last reviewed 2 September 2026

Get in touch

Want this checked against your own project?