Navigating HMRC R&D Inquiries: Building Defensible Technical Narratives for the AIF
Find out more
HMRC’s approach to R&D Tax Relief compliance has become increasingly focused on the quality of the information supporting each claim.
The introduction of mandatory Additional Information Forms (AIFs) means that businesses must provide more detail about the projects included in their claims, including the scientific or technological uncertainties being addressed and the work undertaken to resolve them.
For businesses claiming R&D Tax Relief, this makes the technical narrative more than a formality. It should provide a clear, evidence-based explanation of why the work qualified as R&D and how the project progressed.

What Makes a Strong AIF Narrative?
A useful technical narrative should allow someone with relevant technical knowledge to understand:
- What the business was trying to achieve
- What was already known or available within the relevant field
- What technological or scientific uncertainty existed
- Why that uncertainty could not readily be resolved using existing knowledge
- What systematic work was undertaken to investigate or overcome it
- What the business learned as a result
The narrative should tell the story of the R&D without relying on vague descriptions or marketing language.
A simple way of thinking about the progression is:
Existing Knowledge → Technical Uncertainty → Investigation → Testing and Iteration → Resolution or Further Understanding
Not every project will follow exactly this sequence, but the underlying reasoning should be clear.
Start With the Technological Baseline
One of the most important parts of an R&D narrative is explaining what was already known before the project began.
Simply stating that a product, process or software system was “innovative” is not enough.
The business should explain the relevant baseline and identify what could not be achieved using readily available knowledge, techniques or solutions.
For example, rather than saying:
“We developed a new custom client portal.”
A stronger explanation would describe the specific technical problem encountered and the development work required to overcome it.
The objective is to demonstrate what was technically difficult about the project, not simply what the finished product looked like.
Explain the Uncertainty
The technological or scientific uncertainty is the centre of the R&D narrative.
This should describe the problem that a competent professional could not readily resolve using existing knowledge or established approaches.
For example:
Less useful:
“We needed to make the system faster.”
More informative:
“The existing architecture experienced database locking and throughput limitations under the required level of concurrent processing, and the team investigated alternative approaches to determine whether the required performance could be achieved within the existing technical constraints.”
The second description gives context around the technical challenge without relying on promotional language.
Show the Investigation
A strong narrative should explain what the development team actually did.
Depending on the project, this might include:
- Developing and testing different technical approaches
- Creating prototypes or experimental builds
- Modelling or simulation
- Physical testing
- Performance benchmarking
- Material or formulation trials
- Software architecture experiments
- Analysing test results
- Iterating on unsuccessful approaches
The important point is to connect the activity to the uncertainty.
For example, rather than:
“We tried different materials until one worked.”
The narrative could explain:
“The team evaluated the thermal and mechanical performance of three candidate alloy compositions to investigate deformation under the required operating loads.”
This provides a clearer connection between the technical uncertainty, investigation and outcome.
Building the Narrative From Existing Records
A strong AIF does not necessarily require a business to create a large amount of new documentation from scratch.
The key is ensuring that these records support the story being presented in the claim.
Where the technical narrative and underlying evidence tell the same story, it becomes much easier to explain how the project developed and why the expenditure was incurred.
Existing project records can provide valuable evidence, including:
- Engineering notes
- Design iterations
- Test results
- Technical specifications
- Project plans
- Software development records
- Prototype documentation
- Laboratory results
- Meeting notes
- Internal technical discussions
Case Study: Defending a Software R&D Claim
A commercial software business received an HMRC inquiry into an R&D claim relating to a substantial software development project.
The initial project description provided limited detail about the underlying technical challenges. SeederHeights worked with the company’s technical lead to understand the development process in greater depth.
The revised narrative focused on the specific technical uncertainties surrounding memory management and database locking, together with the investigation and optimisation work undertaken by the development team.
This provided a clearer explanation of the technological challenges behind the project and the work undertaken to address them.
Following the inquiry, HMRC accepted the claim without requiring an adjustment to the amount claimed.
The Bottom Line
The strongest R&D narratives do not rely on complicated language. They explain the technical problem clearly, establish the relevant baseline, demonstrate the uncertainty and show how the development team systematically investigated it.
For businesses submitting an R&D claim, the AIF is an opportunity to present that story clearly and connect the technical work to the expenditure being claimed.
A well-supported narrative should be specific, evidence-based and consistent with the underlying project records.
Reviewing an R&D Claim?
If you’re unsure whether your technical narrative adequately explains the R&D undertaken by your business, the SeederHeights team can review the underlying project information and help identify where further technical detail or supporting evidence may be required.