What HMRC expects: the purpose of R&D documentation (and what it’s not)
HMRC expects R&D documentation to show, in plain English, that your claim is grounded in genuine technical work and that the costs you’re including relate to that work. The aim isn’t to produce a perfect “audit file”; it’s to provide a clear trail that links (1) the project’s technical uncertainty, (2) the work done to resolve it, and (3) the qualifying expenditure you’re claiming.
At a practical level, your documentation should help an HMRC reviewer answer: What was the scientific or technological advance you sought? Why wasn’t the solution readily deducible by a competent professional? What alternatives did you try, what failed, and what did you learn? Evidence can include project notes, design iterations, test plans and results, bug/issue logs, lab notebooks, prototypes, architecture diagrams, commit history, and meeting decisions that show the technical direction.
HMRC also expects a sensible cost narrative: how staff time was allocated, why certain subcontractor or externally provided worker costs relate to the R&D, and how consumables or software were used in the experimental work. Timesheets can help, but aren’t mandatory if you have other credible allocation methods (for example, sprint records, tickets, or work logs that map to named staff).
What it’s not: a marketing brochure, a sales pipeline, a business plan, or a “we built a new feature” story without uncertainty and experimentation. It’s also not a requirement to disclose trade secrets in full—focus on enough detail to demonstrate the uncertainty and the systematic approach taken to resolve it.
R&D project evidence checklist: proving the advance, uncertainty, and the work done
Use this checklist to gather clear, contemporaneous evidence that your project sought an advance, faced genuine uncertainty, and involved systematic work. Aim to collect items as you go, not after the fact.
- Baseline and “advance” statement: a short note describing the current state of the art in your field (what competent professionals could already do) and what capability, performance, or knowledge your project aimed to improve.
- Uncertainty log: dated entries explaining why the solution wasn’t readily deducible, what options were considered, and what made each uncertain (technical constraints, conflicting requirements, unknown behaviour).
- Project plan and iterations: sprint plans, Gantt charts, tickets, or research plans showing hypotheses, tasks, and decision points—plus updates when the plan changed.
- Design and architecture records: diagrams, interface specs, schematics, data models, and design reviews that show evolving technical choices.
- Experiment and test evidence: test plans, protocols, lab notebooks, QA results, benchmarks, simulation outputs, A/B test summaries, and acceptance criteria, including failed tests.
- Prototypes and build artefacts: version control history (commits, branches, pull requests), build logs, release notes, and prototype photos/videos where relevant.
- Technical meeting notes: stand-ups, engineering reviews, incident post-mortems, and decision logs capturing reasoning and trade-offs.
- Outcome summary: what worked, what didn’t, and what knowledge was gained—linking back to the original uncertainties.
- Cost linkage: timesheets or time estimates mapped to R&D tasks, payroll records, subcontractor statements of work, invoices, and consumables logs tied to specific experiments.
Cost documentation checklist: payroll, EPWs, subcontractors, consumables, and cloud/software costs
Use this checklist to gather evidence that links each cost to qualifying R&D activity and shows how you calculated the claim.
- Payroll (employees on PAYE)
- RTI submissions, payslips, P60s, and payroll reports showing gross pay, employer NIC, and employer pension.
- Employment contracts and job descriptions for staff involved in R&D.
- Time evidence: timesheets, Jira/Asana logs, Git commits, lab books, or sprint reports mapping tasks to R&D projects.
- Your apportionment method (e.g., % of time on R&D) and a worked example per role.
- Externally Provided Workers (EPWs)
- Agency contracts, statements of work, and invoices showing worker name/role, dates, and rates.
- Proof of payment (bank statements) and supplier details (UK/overseas).
- Evidence of direction/control by your company (task briefs, tickets, meeting notes).
- Subcontractors
- Signed contracts defining deliverables, R&D scope, and IP/ownership terms.
- Invoices and payment proof, plus correspondence showing the technical work performed.
- Project records linking outputs to your R&D uncertainties (reports, test results, prototypes).
- Consumables and materials
- Purchase invoices, delivery notes, stock records, and usage logs tied to experiments/builds.
- Notes separating items used up in R&D from capital items or resale stock.
- Cloud/software costs
- Supplier contracts, monthly bills, and usage reports (e.g., compute hours, storage, CI/CD minutes).
- Cost allocation workbook showing how you split shared environments between R&D and non-R&D.
- Access logs or project tags demonstrating which teams/projects consumed the services.
Documentation approaches compared: lightweight vs audit-ready (and what’s realistic for SMEs)
Most UK SMEs land somewhere between “enough to support the claim” and “full audit-ready pack”. The right approach depends on claim size, complexity, staff time, and how repeatable your process is.
Lightweight (pragmatic) approach suits smaller or first-time claims where projects are clear and costs are straightforward. Typical evidence includes: a short project summary explaining the technical uncertainty and advances; a simple timeline of key experiments/iterations; links to tickets, commits, lab notes or test results; and a cost workbook showing how staff time and consumables were calculated. It’s faster to assemble and easier to maintain, but it relies more on clear narrative and consistent cross-references.
Audit-ready approach is closer to a “case file” per project and is more realistic for larger claims, multiple projects, or where the technical story is nuanced. Expect: contemporaneous records (meeting notes, design decisions, test protocols, failure logs); versioned technical documents; traceability from each cost line to source data (payroll reports, invoices, timesheets or time apportionment rationale); and internal sign-offs showing who approved assumptions. It’s more resilient if HMRC asks follow-up questions, but it takes discipline and may require process changes.
What’s realistic for SMEs? Aim for “lightweight plus”: keep evidence you already produce, add a one-page project log updated monthly, and ensure every cost has a clear source and a brief explanation. If you can’t justify something simply, treat it as a prompt to tighten the record rather than stretching the claim.
UK R&D tax credit documentation FAQs (software/tech SMEs)
What documents do we actually need for a UK R&D tax credit claim?
Keep a clear narrative plus evidence. Typical items include: project summaries (aim, uncertainties, outcomes), technical notes (design decisions, test results, failures), version control history (commits, branches, pull requests), tickets/roadmaps (Jira/Azure DevOps), architecture diagrams, and time/cost records supporting the figures in the CT600 and computations.
Do we need “lab notes” if we’re building software?
No, but you do need a reliable trail showing experimentation and learning. For software/tech SMEs, Git logs, ADRs (architecture decision records), incident post-mortems, test reports, and sprint retrospectives can serve a similar purpose when they show what was uncertain and how you resolved it.
How should we evidence staff time?
Use timesheets if you have them. If not, document a reasonable methodology (e.g., role-based allocation by sprint, sampled weeks, or ticket-based tagging) and retain the underlying sources (tickets, calendars, release notes) so the approach is repeatable and consistent.
What costs need backup?
Payroll reports (gross pay, employer NIC, pension), invoices for subcontractors/externals, cloud and software invoices, and payment evidence. Keep contracts or SOWs to show who did what and where the work happened.
How long should we keep records?
As a practical minimum, retain claim support for the relevant accounting period and for several years after filing, in line with normal company record-keeping. If you’re unsure, align to your statutory retention policy.
What’s the most common documentation gap?
Linking costs to specific R&D activities. A simple project-to-cost mapping (people, suppliers, cloud) usually fixes this.