How to prepare an R&D Technical Report

What is an R&D technical report?

An R&D technical report (often called a technical narrative) is the document that explains, in plain language, why your projects meet HMRC’s definition of R&D for tax purposes. It is not a sales document and it is not meant to convince HMRC through hype. Its job is to set out the technical problem, the uncertainty, the work you carried out, and what you learned.

Under the merged R&D tax relief scheme and ERIS, the reporting environment is more structured than it used to be. Companies will also need to submit an Additional Information Form (AIF) as part of the claim process, so your technical report needs to align with that submission and with the cost schedules. A good report reduces follow-up questions, shortens review time and makes it easier for someone outside your business to understand what actually happened.

What has changed under the merged scheme and ERIS

From 1 April 2024, most claims sit under the merged R&D tax relief scheme, with Enhanced R&D Intensive Support (ERIS) available for certain R&D-intensive loss-making SMEs. The core definition of R&D has not changed, but HMRC expectations around clarity, consistency and evidence have tightened. The technical report is where you show that you have applied the definition properly and drawn sensible boundaries around what you are claiming.

If your claim relies on ERIS, your technical report should still focus on the R&D definition and the project story. ERIS eligibility is usually better handled in a separate note or working paper, so the report stays readable and focused.

What HMRC needs to see in your R&D technical report

HMRC reviewers are trying to answer a small set of questions. If your report makes these easy to follow, you are doing it right.

Advance in science or technology

You need to explain what advance you were trying to achieve in scientific or technological terms. This is not the same as saying the product was new, the design was improved, or the market wanted it. The advance should be about capability or knowledge in the field, such as performance, reliability, accuracy, throughput, or a method that did not exist in your context before.

Scientific or technological uncertainty

You need to show what you could not readily work out at the start, and why the solution was not obvious to a competent professional. Uncertainty is the heart of the eligibility story. If you skip it, HMRC will often treat the work as routine development.

Systematic work to resolve uncertainty

Explain what you did to try to resolve the uncertainty. This is where you describe the iteration, testing, prototyping, modelling, trials, analysis, and the decisions you made based on results. HMRC expects that you approached the problem in a structured way, even if the project did not succeed.

Competent professionals

A competent professional is someone with the relevant skills and experience who can make informed technical judgements in that field. You do not need to write a biography, but you should name the key technical leads and briefly state why they were qualified to make the decisions. This strengthens credibility and helps HMRC understand who was responsible for technical direction.

The best format for an R&D technical report

There is no official HMRC template, but the most effective reports follow a consistent structure. This also helps when you are claiming in multiple periods, because the narrative remains repeatable without becoming copy and paste.

Start with a short overview of your business and the technical area you operate in, then present your projects as individual case studies. Each case study should follow the same headings, so the report is easy to scan.

Step-by-step: how to write the report

Step 1: Choose which projects to describe

You do not need to write a full essay on every project, but you do need enough coverage that HMRC can see how you assessed eligibility. A common approach is to describe the main projects that drive most of the qualifying spend, then briefly summarise smaller supporting projects. The key is to ensure the projects you describe match what you list in the Additional Information Form (AIF) and what you have costed.

Step 2: Write a clear baseline

Start each project with the baseline. Explain what existed at the outset, what was already known and what constraints you were working within. This sets up the uncertainty properly and stops the narrative becoming vague.

A good baseline is specific. It describes the starting point in the field and in your business, and what performance or capability you could already achieve before the R&D began.

Step 3: Define the advance you were aiming for

State the intended advance in one or two sentences. Keep it technical and measurable where possible. If you can quantify it, do so. If you cannot quantify it, describe it in terms of capability, reliability, or a scientific or engineering characteristic.

This is also the place to be honest about scope. If the advance was limited to a particular subsystem, environment, or set of constraints, say so.‍

Step 4: Describe the uncertainties

List the uncertainties as clear, specific problems, not broad statements. Avoid lines like “we were unsure if it would work”. Explain what was unknown and why it was not readily deducible. If you did literature reviews, supplier discussions or benchmarking, mention that briefly to show you checked what already existed.

Step 5: Explain the work performed and the iterations

Now describe what you actually did. This section should show the path from uncertainty to resolution, including the dead ends. HMRC does not require a successful outcome. Failed tests and discarded approaches often demonstrate uncertainty better than a neat success story.

Keep this grounded in evidence. Mention prototypes built, tests run, simulations carried out, design changes made, parameters adjusted, and why those changes were made.

Step 6: Set the R&D boundaries and timeline

Make it clear where the R&D started and ended for that period. This is especially important when projects run across multiple accounting periods. HMRC expects you to reassess each period, so explain what was still uncertain in the claim period and what had moved into routine implementation.

If you moved from experimental work into production, document that transition. It shows you understand the boundary between R&D and business as usual activity.

Step 7: Link the narrative to the people and the costs

A technical report should connect to your cost model without turning into a spreadsheet. The best way is to name the functions involved and describe their contribution. For example, “Two software engineers worked on algorithm performance testing and optimisation, supported by a test engineer running repeatability trials.” This makes your staff time allocations and third party costs more intuitive to HMRC.

You do not need to list every person and every invoice, but the reader should be able to see why the main cost categories exist.‍

How to keep the report aligned with the Additional Information Form (AIF)‍

Inconsistencies between the technical report, the AIF and the cost schedules often lead to follow-up questions and can extend HMRC’s review.

Keep the following consistent across all documents:

• Project names and descriptions
• The time period covered
• The main uncertainties
• The key contributors and how their work relates to R&D

If you update project titles for readability, update them everywhere. Consistency reduces review time and builds trust.

What to avoid in an R&D technical report

A report can be rejected in practice if it is too generic to test eligibility. The most common issues are writing that focuses on commercial goals, copying last year’s narrative without updating the technical detail, or describing routine development as if it were R&D. Another common problem is skipping the baseline and jumping straight to what you built, which makes the uncertainty hard to see.

Keep the tone factual. Avoid marketing language, avoid claims like “unique” or “world leading” unless you can evidence them and focus on the technical reality of the work.

How much detail is enough?

Aim for enough detail that a non-specialist can understand the project without a call. As a guide, most businesses do well with one to two pages per major project, plus shorter summaries for smaller projects. If your report is very long, it often becomes harder to review. If it is very short, it often becomes too vague to test.

Quality beats quantity. A clear baseline, two or three well explained uncertainties, and a traceable set of iterations is usually better than ten paragraphs of general description.

If you keep your technical story, project list and cost workings consistent, you will make the claim easier to review and put yourself in the strongest position if HMRC has questions later.