Contemporaneous records: what HMRC expects, what counts
A contemporaneous record is one created while the work happened - a commit, a pull request, a ticket, a design doc. When HMRC checks an R&D claim, these records are what it asks for, and they carry far more weight than a narrative written months later. Here's what counts, and why software teams usually have more of it than they think.
Contemporaneous vs retrospective - why the difference decides claims
Created at the time
A contemporaneous record is timestamped, attributable and written while the uncertainty was still live - before anyone knew a tax claim would depend on it. That is exactly what makes it credible: it shows what your team actually did and thought, not what a claim needed them to have done.
Reconstructed afterwards
A retrospective write-up is assembled from memory, months or years later - often in a workshop, sometimes only after HMRC’s letter arrives. It can still be accurate, but it is an assertion rather than a record, and in a compliance check a narrative with nothing contemporaneous underneath it is what HMRC probes hardest.
What HMRC expects you to keep
HMRC’s published compliance guidance encourages companies to keep records of their R&D as the work happens rather than reconstructing it at claim time. And when HMRC opens a compliance check into an R&D claim, contemporaneous records are on its request list explicitly: project plans, technical notes, test logs, version-control records and ticket or email threads. There is no prescribed format - what matters is that the records were created at the time and can be tied to the advance and uncertainty being claimed.
The records software teams already have
Most software teams never keep an “R&D log” - and mostly don’t need to. Your normal engineering workflow produces contemporaneous records as a by-product.
Commit messages
Timestamped, attributable statements of what changed and why - written while the problem was live, not recalled later.
Pull requests and code review threads
Discussion of approaches tried, trade-offs weighed and dead ends abandoned - the resolution of uncertainty, recorded as it happened.
Tickets and issue threads
The problem as it was actually framed at the time: what was blocking, what was attempted, what failed and what finally worked.
Design docs, RFCs and technical notes
Baseline research, rejected options and architecture decisions - evidence that the answer was not readily available at the outset.
Test logs and experiment results
Benchmarks, load tests and failed runs that show a systematic attempt to resolve a technical unknown, not routine development.
Why retrospective write-ups struggle in a compliance check
A narrative is a claim, not proof
The claim narrative asserts an advance and an uncertainty. HMRC’s check asks for the records behind those assertions. If the only material is a document written after the event, the response rests on recollection - and the quality of the first response to an enquiry matters most.
Records anchor every statement
When each statement in the narrative traces to a commit, pull request or ticket created at the time, the response is verification rather than persuasion. That is also far more comfortable for the person who signs their name to the claim.
How Aven assembles the contemporaneous trail
Aven connects to your tools read-only - GitHub, GitLab, Linear - and reads the contemporaneous record your team already created: commit messages, pull-request and ticket text, and metadata. Never your source code. It then wires each narrative statement in an AIF-aligned evidence pack to the specific records that evidence it, while the work is still fresh - so if a compliance check ever comes, the contemporaneous trail already exists and your adviser isn’t reconstructing anything. See how the pack comes together
Common questions
What does contemporaneous actually mean?
Created at the time the work happened. A commit message, pull request, ticket or technical note written while the problem was live is contemporaneous. A project summary written months later - or after HMRC's letter arrives - is retrospective reconstruction, and carries much less weight.
Does HMRC actually ask for these records?
Yes. When HMRC opens a compliance check into an R&D claim, its requests include contemporaneous records: project plans, technical notes, test logs, version-control records and ticket or email threads. HMRC's published compliance guidance also encourages keeping records of R&D as the work happens.
We didn't keep a separate R&D log. Are we stuck?
Probably not. Software teams generate contemporaneous records as a by-product of working: commits, pull requests, code reviews, tickets and design docs. You rarely need a separate log - you need the records you already have organised so each one evidences a specific statement in the claim.
Does Aven need access to our source code to do this?
No. Aven connects read-only and ingests only metadata and commit, PR and ticket text - never your source code. Each narrative statement in the evidence pack links to the record that evidences it.
Aven assembles R&D evidence packs for accountant review; Aven Reviewed adds expert review. Aven does not file with HMRC, determine your liability, select your scheme (merged vs ERIS), sequence loss relief, or guarantee any amount - those are your accountant or R&D tax firm's responsibility. Figures are indicative and conservative. Nothing here is tax advice. UK only.
Your contemporaneous record already exists. Put it to work.
The Eligibility & Readiness assessment is free, takes a few minutes, and tells you honestly whether Aven is the right fit.
Check your eligibility - free