Sectors •8 min read

R&D tax relief for software development

MJ

Matthew Jones ACA CTA

Last reviewed August 2026 · Editorial standards

Software development qualifies for R&D tax relief when it seeks an advance in the underlying technology, not just a new product built with existing tools. That distinction excludes a large share of commercial development work, and HMRC applies it strictly. The question is always whose knowledge ran out. The advance has to lie in the field’s overall knowledge or capability, not the company’s own, and HMRC’s software guidance is explicit that building a software product is not an advance in science or technology simply because software technology was used to create it. This page sets out where software claims stand up, where they do not, and what the relief is worth when they do.

When does software development qualify as R&D?

When a competent software professional, armed with published knowledge and established techniques, could not readily resolve the technical problem you faced. The Guidelines put the test as knowledge of whether something is scientifically possible or technologically feasible, or how to achieve it in practice, being neither readily available nor readily deducible by a competent professional in the field — and “the field” means knowledge publicly available or readily deducible from it, which in software is a large and well documented body. Unfamiliarity with a technique is not uncertainty. Its absence from the field is.

Qualifying work typically involves:

  • Constraint sets that published approaches cannot satisfy together. Scale, latency, accuracy and concurrency rarely bind one at a time, and the uncertainty sits in the trade-off rather than any single target. An indexing scheme with known behaviour at one data volume and a consistency model that holds under one set of failure assumptions are each documented alone; whether they hold together at the operating point the project needs often is not.
  • Processing data at volumes or speeds where established architectures demonstrably fail. “Demonstrably” carries the weight: the baseline should be a measured limit of a known approach, not a later assumption that it would not have coped.
  • Integration where the combined behaviour of systems is genuinely uncertain. The Guidelines describe system uncertainty as uncertainty that results from the complexity of a system rather than uncertainty about how its individual components behave. They go further: work on combining standard technologies, devices and/or processes can involve scientific or technological uncertainty even if the principles for their integration are well known, and there will be uncertainty where a competent professional working in the field cannot readily deduce how the separate components or sub-systems should be combined to have the intended function. The caveat sits alongside it: assembling components, or software sub-programs, to an established pattern, or following routine methods for doing so, involves little or no uncertainty. “Every part of it already existed” does not close the question; nor does “we integrated many parts”.

Work can be new to your company, commercially valuable and technically demanding, and still not qualify. Our guide to what counts as qualifying R&D covers the test in full, and what a scientific or technological uncertainty is takes the uncertainty limb on its own.

What software work does not qualify?

Most of it, honestly. The following are routine development, however skilled:

  • Building applications with established frameworks, languages and APIs used as intended.
  • Configuring or customising existing platforms to a specification.
  • User interface and user experience work.
  • Porting a working system to a new platform, language or hosting provider by documented means, where the outcome was never in doubt.
  • Replicating functionality well understood in the field, even if it is new to your business. HMRC’s guidance for compliance puts routine analysis, copying or adaptation of an existing process or product outside the definition, even where the work is well planned and resource-intensive.
  • Routine testing, debugging and maintenance, including testing that runs after the uncertainty is resolved and only confirms what is known.

The Guidelines also exclude, in terms, improvements, optimisations and fine-tuning which do not materially affect the underlying science or technology. Making something faster is not automatically R&D. Making it faster by a route the field could not readily deduce may well be.

Where a genuinely qualifying core sits inside a larger commercial build, the project boundary matters. The R&D project is almost always narrower than the release: it begins when work on the identified uncertainty starts and ends when that uncertainty is resolved or abandoned, which puts requirements gathering, user acceptance testing, deployment and maintenance outside it whatever the sprint board says. The claim covers the work that resolved the uncertainty, not the whole product, and drawing that boundary carefully is what keeps a software claim defensible.

Why does HMRC guidance matter so much for software claims?

Because software is where HMRC has concentrated much of its compliance effort, and its guidance is specific about the difference between advancing software technology and using it. HMRC checked around one in six claims in 2023-24, its latest published figure, and has over 500 people working on R&D compliance. The claims that fail tend to be written in product language, listing features rather than uncertainties.

That guidance is granular about activities. Technical design and development aimed at the uncertainty can qualify, as can unit, integration and performance testing where the results feed back into resolving it; requirement gathering, configuring software to a customer’s specification, user acceptance testing, deployment and maintenance do not. A claim built on it names the field, states what was already publicly achievable, and records the experiments, including the ones that failed. We go further into this in why following HMRC’s guidance decides software claims. Our page on HMRC R&D enquiries covers what happens when a claim is checked.

What records does a software claim need?

Better ones than most development teams keep by default, though rarely more than good engineering practice produces anyway. Every claim is made through the company tax return with an Additional Information Form describing the projects, so the technical account has to exist and has to hold up. HMRC’s expectation is proportionate: its guidance for compliance says the records you normally create while running the business are often enough, and lists designs, test results and email exchanges among what it may ask to see. In a development team’s artefacts, that means:

  • The technical lead’s statement of the uncertainty at the outset, and why existing approaches were insufficient, written while it was still uncertain.
  • Design documents and architecture decision records, particularly those recording options considered and rejected.
  • Tickets, commits and branch history showing which approaches were tried and in what order.
  • Benchmark and test results, including the failures, and incident or post-mortem records where production behaviour drove the work.
  • A sensible basis for apportioning staff time between qualifying and routine work.

Version control history is often the most persuasive evidence a software company already holds: it timestamps the iterations and shows the dead ends that a tidy retrospective write-up would hide. What a repository cannot supply is the question each iteration was asking, which is why a short running note alongside it earns its keep in a claim.

What about machine learning and AI?

AI development raises the same test with different facts, and we treat it separately. The fine-tuning exclusion above is the line that recurs: adapting a documented model to your own data by the vendor’s route rarely affects the underlying technology, whereas pushing past what published architectures, training regimes or toolchains can demonstrably do often involves genuine uncertainty. The added difficulty is the baseline, which in machine learning moves quickly enough that a capability genuinely open during the accounting period may be settled by the time the claim is written. See when machine learning development qualifies as R&D for the field-advance analysis, and our AI and robotics sector page for the wider claim picture.

What is a software claim worth?

Under the merged scheme, £100,000 of qualifying spend gives a £20,000 gross credit: £15,000 net at the 25% corporation tax rate, £16,200 at the 19% rate or for loss-making companies. A loss-making SME whose relevant R&D expenditure is at least 30% of its total relevant expenditure can instead claim up to £26,970 on the same spend through ERIS. That denominator is broadly the trading costs in its accounts for the period, not just the R&D ones.

Qualifying costs include apportioned staff time, cloud computing and data licences, and payments to unconnected subcontractors at 65%, subject to the UK-only rules on where the work is done. The compute line is often the one nobody has interrogated: training runs, simulation and the environments used to test an unproven architecture belong in the claim; the production cluster serving live customers does not. Which software and cloud costs qualify works through the categories. Grant funding no longer reduces relief under the current schemes; the position is explained in grant funding and R&D tax relief. The claim value calculator gives an estimate on your own numbers, and the ERIS intensity calculator works the 30% test.

A measured word on our approach

Software claims built on weak foundations were a large part of the mis-selling era, and they remain a focus of HMRC’s checks. We would rather tell you a project does not qualify than file a claim that will not withstand scrutiny. LimestoneGrey is a firm of chartered tax advisers and chartered accountants specialising in R&D tax relief regulated by ICAEW; every claim is signed off by a chartered adviser, and enquiry support is included as standard. If an earlier adviser filed software claims you are no longer comfortable with, we can review the position, and where HMRC has already opened an enquiry we can take over the defence.

If you want an honest view on whether your development work qualifies, talk it through with a chartered adviser.

Sources