GrantUp
All insights

R&D tax

Software R&D tax credits: what HMRC accepts as qualifying work

Which software work qualifies for R&D tax relief and which does not: the advance in computer science test, technological uncertainty, and how to evidence a software claim HMRC will accept.

26 September 2026 7 min read

Why software claims attract attention

Software is the single largest category of R&D tax claims and the one HMRC checks most closely. The reason is simple: almost every software team believes its work is innovative, but the relief is not for building something new to your company. It is for resolving uncertainty that a competent professional in the field could not readily resolve.

A claim that describes features, sprints and customer value reads as product development. A claim that describes the technical problem nobody had solved, the approaches tried, and why the outcome was genuinely uncertain reads as R&D. The underlying work is often the same. The difference is whether the narrative is written in the language HMRC actually assesses.

The advance has to be in computer science, not in your product

The test is whether the project sought an advance in overall knowledge or capability in a field of science or technology. For software that means computer science or software engineering as a field, judged against what a competent professional would already know or could readily deduce from published work and standard practice.

Integrating well documented APIs, configuring a framework, rebuilding an existing system on a new stack, or adding features to a product are usually not advances, however valuable commercially. Extending an algorithm beyond its known performance envelope, achieving throughput or latency that available methods do not deliver, or making a model behave reliably where the published approaches fail usually are.

Software work that usually qualifies

Novel algorithms or data structures where the performance characteristics could not be predicted in advance. Machine learning work where the uncertainty is technical rather than a matter of tuning, such as training under severe data scarcity, achieving reliable behaviour on adversarial inputs, or compressing a model to run within hard resource limits.

Distributed systems work where consistency, fault tolerance or scale could not be achieved with standard patterns. Integration with hardware, sensors or instrumentation where the behaviour of the combined system is unknown. Security and cryptography work extending beyond established implementations.

Software work that usually does not

User interface design and improvement, routine data migration, building websites and mobile apps with established tooling, configuring off the shelf software, and cosmetic or performance tuning within known limits. Bug fixing is not R&D unless the defect itself revealed a genuine technological uncertainty.

Work can also stop qualifying partway through. Once the uncertainty is resolved and the remaining effort is implementation, that later work falls outside the claim. Getting the cut off right is one of the most common places claims go wrong.

Evidencing a software claim

The strongest evidence is created while the work happens: design documents, architecture decision records, spike and prototype branches, benchmark results, failed approaches and the reasons they were abandoned. Version control history and issue trackers are useful because they show the sequence of attempts rather than a tidy retrospective story.

Name the competent professional. HMRC expects an identifiable person with the qualifications and experience to judge what was and was not readily deducible, and their account should read as theirs, in their technical language, not as marketing copy.

Costs in a software claim

Developer, data scientist and technical lead time apportioned to qualifying work, with employer national insurance and pension. Cloud compute and data costs used directly in the qualifying work, which matters a great deal for machine learning projects. Software licences used in the R&D. Externally provided workers and subcontractors, subject to the current territorial rules restricting relief to UK based work.

Apportionment method matters more than precision. A reasoned approach backed by project records will stand up. A round percentage applied to the whole engineering team will not.

Where to go next

Our R&D tax hub compares the claim types and includes a calculator to size your entitlement. If you want an honest read on whether your software work qualifies, book a free review and we will tell you plainly, including when the answer is no.

Ready to turn this into a funded proposal?

Book a free 30-minute consultation with a senior grant consultant. We will check your eligibility, match you to the right program, and map out your submission timeline.

Learn more about our approach

Ready to get started?

Talk to us about your grant funding plans and we'll help you make it happen through effective, results-driven grant writing.