Does software development qualify for R&D tax relief?

This note covers software houses, SaaS and platform businesses, fintech, data and AI companies, and any company whose R&D is a development team.

What usually qualifies

The work that qualifies is work where the outcome was not deducible in advance from what is publicly known. In practice that tends to mean:

• Algorithms and architectures built to solve a technical problem, where the question was how to make something perform, scale or hold together in a way that was not obvious.
• Integration that creates real uncertainty, where it was not clear whether disparate systems, legacy platforms or data sources could be made to work together reliably. The guidelines allow this explicitly, but set the bar at whether a competent professional “cannot readily deduce how the separate components or sub-systems should be combined” — and it is also where most claims fail.
• Processing, securing or analysing data at a scale or speed existing tools were not built for.
• Software controlling new hardware, sensors or physical processes, where system behaviour is not predictable from documentation.
• Approaches that were abandoned or substantially reworked. A project need not succeed. The guidelines are explicit that what counts is the intention to achieve an advance, “not whether ultimately the associated scientific or technological uncertainty is completely resolved”, and HMRC’s own software case studies include a project that qualified right up to the point it established the thing could not be done.

One thing helps more than people expect: an advance is still an advance where several companies are working at the edge of the same field independently, or where the result is known but the method is a trade secret.

What usually does not

• Using existing tools, frameworks and platforms as documented, however demanding they are to implement well.
• Routine bug fixing, maintenance and configuration. HMRC puts “maintenance activities or minor fault fixing where no technological uncertainties arise” outside the claim in terms.
• Applying established practice to a new context, where a competent developer would know how to get the result.
• Front-end and UI work that is about design, usability or commercial appeal rather than a technical problem.
• Requirements gathering, deployment and user acceptance testing. HMRC names these specifically — “business requirement gathering”, “deployment or release activities that transfer software to production systems” and “functional user acceptance testing” are outside, while unit testing, early integration testing and performance and security testing that feed back into the uncertainty are inside.

The line is uncertainty, not effort. A project can be large, slow and strategically vital without qualifying, and a small one can qualify because it went past what was known. The general limits are in what does not qualify.

Content is not technology

This catches digital businesses more than any other sector, and it has a tribunaldecision behind it. Information or content delivered through a technological medium is not itself technology — but improvements in the technological means of creating, manipulating or transferring that content can be an advance.

So a publisher digitising an archive, a media business building a content platform, or a marketplace whose value is its listings is not doing R&D by virtue of what the product contains. The question is whether handling it required something the field could not already do. The same applies where the innovation is in the business model or the user proposition: the guidelines exclude the arts, humanities and social sciences from “science” altogether, so a genuinely novel product can rest on no technological advance.

Three decisions in one year, and what separated them

Software is unusual in having real authority, and 2024 produced three First-tier Tribunal decisions within three months. Two claims failed, and one succeeded. The technology was not what divided them.

In Get Onbord the claim succeeded. The company was automating know-your-clientverification and risk profiling, and HMRC argued it had merely applied existing tools. Two findings matter to every software claimant: the person directing the work counted as a competent professional despite having no formal IT qualifications, on the strength of his experience and current knowledge; and the tribunal declined to require contemporaneous documentation, accepting his oral evidence alongside written reports.

In Tills Plus, two days later, the claim failed. The work was combining existing modules into an integrated platform, and the tribunal held that “simply taking existing technology or products and combining them to provide an integrated system” is not an advance. It also found the company’s own accounts of the project impossible to reconcile — an early description of one product, a later report describing something different — and the author of that report was not available to be cross-examined.

In Flame Tree Publishing the claim failed on the people. A publisher had digitised its archives, and the tribunal found that neither the founder nor the production manager qualified as a competent professional in software or computing. Claimed time allocations were estimated in discussion rather than recorded, so the costs failed too.

Read together the message is practical. Integration claims are live but fragile. The competent professional needs no certificate, but does need to exist, be identified and be able to answer questions. And an account that changes between the telling to HMRC and the telling to a tribunal is worse than a thin one.

Where the project starts and stops

R&D starts when work to resolve the uncertainty starts and ends when it is resolved or work on it ceases. In a software build, that boundary rarely matches a sprint, a release or a budget line, which is why claims drift.

HMRC’s own worked examples are blunt about it. In a machine learning project, choosing between approaches and evaluating existing solutions did not qualify; building a network structure that pre-selected processing pathways did; and the project ended once outputs matched the previous version, because everything after that was “optimisation and fine-tuning”. In a cloud migration, selecting middleware did not qualify, while building a certificate authority to pass data between public and private clouds without a performance penalty did.

The practical consequence is that the claim is almost never a whole product, a whole release or a whole team. It is a subset, and it has dates.

Software, data and cloud costs

Software licences have long been a qualifying cost. For expenditure incurred on or after 1 April 2023, data licences and cloud computing services became qualifying categories too, which matters more in this sector than any other — for many companies compute is the largest single line in a development budget.

The condition is the one that catches people. These costs qualify where they are employed in activities directly contributing to resolving the uncertainty. Where the spend is attributable to qualifying indirect activities, or to running the production service, it does not. A cloud bill is therefore not a claimable total; it is something to apportion, and the apportionment needs a basis you could show someone. The same applies to a data licence bought for the business generally and used in part for the project.

The general position on costs is in what costs qualify. If you are a games studio, note that the interaction with the creative industry reliefs is its own question and the answer is less flexible than it looks — see claiming R&D relief alongside a creative industry relief.