Software R&D Tax Credits Under HMRC Scrutiny: What HMRC Actually Looks For

Software R&D claims attract close attention from HMRC, and the questions asked in an enquiry are technical and specific. If you are a software company preparing a claim, defending one, or working out why a recent claim attracted attention, this is the inspector's lens you need to understand.

The pattern we see is consistent. HMRC does not challenge software claims because software is not innovative. It challenges them where the documentation supplied with the claim too often fails to demonstrate that the work crosses the boundary between commercially valuable engineering and a genuine advance in computer science. That distinction is the single most important thing to understand.

Why HMRC Targets Software R&D Tax Credit Claims So Heavily

Software claims are often challenged for three reasons.

1. The number of software claims grew quickly, and some were prepared by advisers using templated narratives that could be applied to almost any company.
2. Software work is highly susceptible to confusion between commercial uncertainty and technological uncertainty. The DSIT Guidelines require an advance in the overall knowledge or capability in a field of science or technology, not an advance in a particular company's product roadmap.
3. The DSIT Guidelines apply the same criteria to software as to any other field, and a great deal of software work is routine adaptation or assembly to an established pattern rather than an advance. UI refinement, sprint planning, deployment automation, cloud configuration, and integration of well-documented libraries are routine. In our experience, enquiry letters often carve these activities out first and ask the company to justify what is left.

The Software-Specific Tests HMRC Applies

Inspectors apply the same statutory test as for any other R&D claim, but with a sector-specific lens. Three tests dominate.

1. The competent professional test asks whether a competent software engineer in the relevant field, equipped with the current state of knowledge, could readily deduce the solution. HMRC's GfC3 (published 31 October 2023, last updated 23 January 2025) expects a competent professional to be suitably qualified or experienced in the field, knowledgeable about the relevant principles, aware of the current state of knowledge in the field as a whole, and to have a track record. Having worked in a field, or an intelligent interest alone, is not enough. The evidence you keep should show who that person is and record their technical reasoning. A founder-developer with no externally recognised expertise should expect a higher evidence bar, and GfC3 gives an example of an inexperienced IT team that could not identify any qualifying uncertainty without speaking to a competent IT professional. The competent professional may work for the company or may be external.
2. The advance test asks whether the work sought to extend overall knowledge or capability in computer science, not merely apply known techniques in a new commercial context. Inspectors increasingly ask claimants to articulate the advance in the language of computer science: a new algorithm, a new architecture, or a measurable improvement in throughput, latency, accuracy or capability that was not previously achievable.
3. The uncertainty test asks whether the resolution of the technical problem was uncertain at the start, and whether the uncertainty was resolved through systematic investigation rather than trial-and-error coding. AI coding tools bear on this test. Where a developer can describe an integration problem in plain English and receive a working answer in seconds, the problem is more likely to have been readily deducible. GfC3 treats "readily deducible" as workable from existing knowledge without significant effort, so that is the question to ask of any AI-assisted work.

Common Software R&D Claim Mistakes That Trigger HMRC Enquiries

Generic narratives are the single biggest trigger. Where a claim describes the project in marketing language rather than technical specifics (no named technologies, no version numbers, no architectural diagrams, no mention of the competent professional's reasoning), HMRC reads this as a sign that the technical narrative was written by an adviser rather than the engineering team.

Inclusion of non-qualifying activity is the next most common cause of challenge. UI/UX work, sprint ceremonies, project management, DevOps and CI/CD configuration, integration of documented APIs, cloud configuration, and SaaS implementation are routinely included in claim cost schedules. Most of this is not R&D. A claim that allocates 100 per cent of a developer's time to R&D over a full year is likely to be questioned.

Confusion between technological uncertainty and business uncertainty is the third trigger. "We did not know whether the customer would like it" is not a qualifying uncertainty. "We did not know whether our chosen approach would scale to one million concurrent connections within our latency budget, and we had to test three competing architectures to find out" is closer.

Overreach on AI and machine learning claims has become a sector of its own. Companies fine-tuning a foundation model, integrating an off-the-shelf large language model, or training a model on their own data using established frameworks are often performing implementation, not research. GfC3 gives the example of a company adapting published open-source natural language processing methods to modernise its website, which was routine use of existing knowledge and not R&D. The evidence needed to distinguish frontier work from commercial application is demanding.

The final trigger is failure to capture the trail of the investigation. Software development happens fast, often without the deliberate documentation that you would see in a physical engineering project. Issue trackers, commit messages, architecture decision records, design documents, peer review notes, and failed branches are all useful. Together they form the audit trail HMRC expects.

What HMRC Asks For in a Software R&D Enquiry

Software enquiry letters tend to follow a recognisable structure. In our experience inspectors ask for:

• the competent professional's identity, qualifications and direct involvement;
• a precise description of the public knowledge baseline at the start of each project;
• the specific scientific or technological uncertainties resolved, expressed in technical language;
• the alternatives considered and rejected;
• contemporaneous engineering artefacts including code repositories, branch histories and benchmark logs;
• and a reconciliation of qualifying time and cost against total project effort, distinguishing analysis and experimentation from non-qualifying implementation.

References such as "improving performance" are routinely rejected. A reference such as "achieving sub-50ms p99 latency under 100,000 concurrent connections on a single node, where the documented throughput limit of the chosen runtime is 35,000" (an illustrative example only) is far stronger.

Key takeaway: HMRC is not asking software companies to prove they are 'innovative'. It is asking them to prove that the specific work they are claiming for crosses the threshold from skilled engineering into the resolution of genuine technological uncertainty, and to do so with the precision and contemporaneous evidence that any competent professional would expect to see.

How to Build a Software R&D Claim That Survives HMRC Scrutiny

Software R&D claims now need to be built as if an enquiry is the default expectation. That means doing five things differently.

1. Identify and document the competent professional at the start of every project, not at claim preparation time. Capture their qualifications, their reasoning, and their assessment of the public baseline of knowledge in writing.
2. Build the technical narrative from engineering artefacts. Issue tracker entries, design documents, architecture decision records, commit messages, and benchmark results should be the source material. The narrative should read as a technical document, not as marketing copy.
3. Carve out non-qualifying work explicitly. Where a developer's role spans qualifying analysis and non-qualifying implementation, allocate hours accordingly and explain the methodology. Claims that volunteer the boundaries are more credible than claims that hide them.
4. Treat AI tooling honestly. Where AI-assisted development has reduced the time required to produce known patterns, that is not R&D. Where it has been used as a sounding board on a problem the model could not actually solve, capture that fact.
5. Document the failures. The most powerful evidence in any software R&D enquiry is the path that did not work. Failed prototypes, abandoned branches and rejected architectures are the proof that the answer was not readily deducible at the start.

For software companies in regulated environments, defence applications, frontier AI research or genuinely novel computational work, the threshold remains more comfortably within reach. For SaaS companies building features that customers want, the threshold has moved up, and the claim approach must move with it.

What to Do If HMRC Has Already Opened an Enquiry

If a software R&D claim is already under enquiry the priorities are different.

• Read the inspector's letter line by line and identify exactly what is being challenged. A request for "details of the technological uncertainty" is not a request for a paragraph; it is a request for evidence that an advance was sought against a defined baseline.
• Involve the competent professional immediately, before issue tracker exports, commit history, design documents and contemporaneous emails are lost. Then assess whether the claim, as filed, is defensible in its current shape or whether parts should be conceded to focus the defence on the strongest qualifying activity.
• A focused, technically precise response will almost always produce a better outcome than a comprehensive defence of every line of the original claim.

We have set out the wider process in our guide to how to respond to an HMRC R&D tax credit enquiry letter.

Software R&D Tax Credit HMRC Scrutiny: FAQ

Why are software R&D tax credit claims under HMRC scrutiny more than other sectors?

Software claims grew quickly, much software work is routine adaptation or assembly rather than an advance in the field, and templated narratives produced by some advisers invite challenge. The DSIT Guidelines apply the same tests to software as to any other field.

What does HMRC mean by a "competent professional" in a software R&D claim?

A competent professional is a software engineer in the relevant field who has the qualifications, experience and recognition needed to assess what is and is not readily deducible at the current state of knowledge. HMRC's GfC3 expects this person to have professional expertise relevant to the advance being sought, usually through direct involvement in the project, and to be able to judge what is and is not an advance on the current state of knowledge. Good evidence includes high level qualifications with continuing professional development, many years' experience at a high level in the field, a publication record, industry awards or public recognition.

Can I claim R&D tax credits for AI-assisted software development?

Yes, but only where genuine technological uncertainty remained after the AI was used. Where AI-assisted coding produced the answer, the work is implementation, not R&D. Where AI-assisted exploration failed to resolve the problem and your team had to design and test alternatives, that work may qualify. Documentation of the failure is essential.

What evidence does HMRC ask for in a software R&D enquiry?

Identity and qualifications of the competent professional, the public baseline of knowledge at the start of the project, the specific technological uncertainties resolved, the alternatives considered and rejected, contemporaneous engineering artefacts (issue tracker, commit history, design documents, benchmarks), and a reconciliation of qualifying hours and costs against total project effort.

Does UI/UX work qualify as R&D for software claims?

UI/UX work is almost always non-qualifying. The DSIT Guidelines exclude commercial and financial steps and routine adaptation, and require a scientific or technological advance. Where work involves a novel computational method (for example a new accessibility algorithm or a genuinely novel rendering approach) qualifying activity may exist, but standard interface design, layout, branding and usability optimisation does not qualify.

How long does an HMRC enquiry into a software R&D claim usually take?

There is no fixed timetable. Enquiries can run for many months, and contested cases that escalate to statutory review or to the First-tier Tribunal can take considerably longer. In our experience the biggest determinant of timeline is the quality and timeliness of the technical evidence the company can produce.

What should I do if I think my software R&D claim could be challenged?

Carry out an independent technical review against the DSIT Guidelines and HMRC's GfC3 before any further claims are submitted. Identify weak points in the narrative, the cost schedule, and the supporting evidence. Pre-submission review is generally cheaper than enquiry defence.

Where to Go From Here

Software claims face close questioning, and that is unlikely to ease. Companies that build claims as if an enquiry is the default expectation, that document the competent professional's reasoning at the time of the work, and that keep the engineering audit trail intact will continue to claim with confidence. Companies that rely on retrospective narratives and templated advisers will not.

If your software R&D claim is under enquiry, has been rejected, or you want it reviewed before submission, our specialist R&D tax credit defence service is built for exactly this work. Get in touch to discuss how the principles set out above apply to your position.