- By Michelle Giuricich | Lead Technical Consultant, Catalyst Solutions
Somewhere at HMRC, a caseworker is reading your R&D claim. They weren’t in the lab, they didn’t sit in your sprint reviews, and they may not be a specialist in your field. What they have is your technical narrative: the part of the claim that explains, in your own words, why your project counts as R&D. Since 8 August 2023, every claim has needed one, submitted through the Additional Information Form (AIF). So what does that narrative need to say, how do you make it clear, and who should be writing it?
An R&D technical narrative is the written explanation of the scientific or technological work underlying an R&D tax relief claim. It sets out what was already known or possible, the advance the project sought to achieve, the scientific or technological uncertainties encountered and the work undertaken to address them.
Its role is to translate the work carried out during the project into a clear technical account that HMRC can assess against the R&D tax relief requirements.
It is not a marketing description of the project or finished product.
HMRC requires the project information submitted with an R&D claim to address five areas:
Identify the relevant scientific or technological discipline. This should describe the field in which the advance was sought, rather than simply the company’s industry, product or commercial market.
Set out the baseline that existed before the project began. This gives HMRC a point of comparison for understanding what the project was seeking to advance beyond.
Explain what the project aimed to achieve beyond that existing knowledge or capability. The advance needs to relate to the wider field of science or technology, rather than simply being something new to the company.
Describe what could not readily be worked out at the start of the project and why the solution was not readily deducible by a competent professional in the field.
Explain the work carried out to try to resolve them. This could include the development, testing, experimentation or analysis undertaken, including relevant successes and failures along the way.
Together, these elements should give HMRC a clear account of the starting position, the advance being sought, what stood in the way and what the project did to address it.
Even where a project meets the qualifying criteria, the technical narrative needs to explain that work clearly. Certain words commonly used to describe R&D can leave important questions unanswered if they are not supported by specific technical detail.
The words below are not necessarily incorrect. The issue is when they replace the explanation of the advance being sought, the uncertainty encountered or the work undertaken to address it.
| If your narrative says… | HMRC may be left asking… | What to explain instead |
|---|---|---|
| Innovative | Innovative compared with what? | What existing technology could or could not do, and where the project sought to go beyond it |
| Cutting-edge / state-of-the-art | What was the state of the art? | The baseline in the field before the project started |
| Complex / technically challenging | Was this difficult, or genuinely uncertain? | What a competent professional could not readily work out, and why |
| Bespoke / tailored | Was this customising known technology? | Why existing methods could not simply be adapted to meet the requirement |
| New / for the first time | New to the company, or new to the field? | How the advance relates to the wider field, not just to the company |
| Improved / optimised | Improved from what, to what, and how? | The measurable starting point, the target and the obstacle in between |
| Seamless integration | Was combining these systems actually uncertain? | The specific technical problem the integration raised, if there was one |
| Market-leading / commercially important | Is this a commercial point or a technical one? | Leave the commercial case aside and focus on the scientific or technological uncertainty |
The technical narrative should be specific, factual and clear enough for someone outside the project to understand.
The difference between a broad description and a useful technical explanation is best illustrated through an example.
Too vague
We developed an innovative automated inspection system that presented significant technical challenges and required extensive development and testing.
This tells HMRC that the project was difficult, but it does not explain what existing technology could not achieve or what scientific or technological problem the team was trying to address.
More useful
Existing machine-vision systems could not reliably identify defects at the required production speed because variations in surface reflectivity reduced image consistency. The development team investigated whether changes to the imaging configuration and processing approach could achieve the required detection accuracy without reducing line speed.
The second version gives HMRC the context needed to understand the technical problem and the work undertaken to address it.
This does not mean that every technical narrative should follow a rigid template. The detail required will depend on the project itself. The important point is that the explanation makes the scientific or technological basis of the R&D clear, rather than expecting HMRC to infer it from a description of a difficult or innovative project.
The project team is essential to the technical narrative because they understand the work undertaken, the problems encountered and the approaches considered during the project.
However, knowing the project in detail and being able to communicate it effectively within HMRC’s R&D framework are different skills.
The person preparing the narrative needs to understand the R&D requirements, have enough scientific or technological knowledge to follow and question the work being described, and be able to translate specialist project knowledge into clear technical writing.
An engineer, scientist or developer may understand the project completely but have little experience presenting that work in the context of an R&D tax claim. Equally, someone with tax knowledge but limited understanding of the underlying science or technology may struggle to ask the right questions or recognise which technical details are significant.
The strongest approach therefore brings those skills together: the scientific or technological expertise needed to understand the R&D itself, and the R&D tax and technical writing expertise needed to communicate it accurately to HMRC.
This is important because the quality of the explanation can affect how easily HMRC can understand the basis of the claim. If the baseline, advance or uncertainty is unclear or important technical information is poorly explained, HMRC may need further information. Incomplete or improper responses in the Additional Information Form can also increase the likelihood of enquiry or other compliance activity.
This is where specialist support comes in. Preparing a technical narrative can take considerable time from internal teams, particularly where the R&D is complex or several team members need to contribute information.
Specialist support can make the process more focused, accurate and time-efficient. The role of an R&D tax adviser is not to replace the scientists, engineers, developers or other professionals who carried out the work. Their knowledge remains essential.
Instead, an adviser can lead focused discussions with the project team, ask the questions needed to understand the R&D and translate that information into a clear technical narrative aligned with HMRC’s requirements.
This reduces the need for technical teams to spend their time interpreting tax guidance or determining how their project should be presented.
Ultimately, the technical narrative should allow someone outside the project to understand where the project started, what scientific or technological advance was being sought, what uncertainty stood in the way and what the team did to address it.
ABOUT THE AUTHOR
Michelle Giuricich is the Lead Technical Consultant at Catalyst Solutions. She works across industries, overseeing the technical assessment on every R&D project the firm takes on. Her background as a chemical engineer at Sasol shapes how she reads complex technical work and what she looks for when assessing whether a project meets the uncertainty test.