R&D Tax Credits for Software Companies: What Actually Qualifies in 2025

Software companies are among the most frequent R&D tax credit claimants in the UK — and among the most frequently challenged by HMRC. The line between routine software development and qualifying R&D isn't always obvious, and getting it wrong can mean an enquiry, a reduced claim, or penalties.

Here's what software companies need to understand about qualifying R&D activities under the current rules.

The Core Test: Technological Uncertainty

The same test applies to software as to any other sector. Under the BIS Guidelines and CTA 2009 s1042, qualifying R&D must seek an advance in science or technology by resolving scientific or technological uncertainty.

For software, this means the work must go beyond what a competent professional in the field could readily achieve. HMRC's guidance at CIRD81900 is specific: routine software development, even if complex, does not qualify. The key question is whether the solution required genuine investigation and experimentation because the outcome was uncertain.

R&D tax relief for software companies under the merged scheme (from 1 April 2024)

1. The core test: technological uncertainty

For software, the statutory test is the same as for any other field:

• Source law: CTA 2009 s1042 and the DSIT Guidelines (formerly BIS Guidelines)
• Requirement: The project must seek an advance in science or technology by resolving scientific or technological uncertainty.

In practice for software:

• The work must go beyond what a competent professional in the field could readily achieve using existing knowledge, tools, and techniques.
• HMRC (CIRD81900) is clear that routine software development, even if complex or time‑consuming, does not qualify.
• The uncertainty must be technical, not just:
• Commercial (e.g. will customers buy it?)
• Organisational (e.g. can we deliver this by the deadline?)
• Team‑specific (e.g. we’ve never done this before)

Example contrast:

• Not R&D: Building a standard e‑commerce site using a known framework, patterns, and infrastructure.
• Likely R&D: Developing a novel real‑time pricing engine that required solving a previously unsolved computational or systems problem, where competent engineers could not predict in advance whether the chosen approach would work.

2. Software activities that typically qualify

HMRC has become more prescriptive, especially since the Additional Information Form (AIF) became mandatory. Activities that often support successful claims (when they genuinely involve technological uncertainty) include:

a. Novel algorithm development

Qualifying where:

• Existing algorithms or approaches were demonstrably insufficient for the required outcome.
• A new or materially modified algorithmic approach had to be designed, tested, and validated.
• There was genuine uncertainty about whether a workable algorithm could be found.

Adapting a known, published algorithm to a new business context, without solving a new technical problem, is usually not R&D.

b. Performance at scale

Qualifying where:

• The challenge is not simply scaling infrastructure, but achieving specific, demanding performance characteristics (throughput, latency, reliability, consistency) under real‑world load.
• Existing distributed systems patterns could not be straightforwardly applied, and required fundamental architectural experimentation.
• There was uncertainty about whether the required performance envelope was technically achievable with available technologies.

c. Advanced machine learning / AI work

Qualifying where:

• The work involves novel architectures, training regimes, optimisation methods, or data handling techniques that go beyond standard practice.
• The team is addressing documented limitations of existing methods (e.g. few‑shot learning, extreme class imbalance, domain shift) and must experiment with new techniques.
• There is evidence of systematic experimentation and failure before reaching a solution.

Examples that may qualify:

• Designing a new loss function or training curriculum to handle a data distribution that breaks existing methods.
• Developing a bespoke architecture to meet strict constraints (e.g. on‑device inference with tight latency and memory limits) where standard models fail.

d. Security and cryptography

Qualifying where:

• Off‑the‑shelf protocols, libraries, or tools cannot meet the required properties.
• The team must design or materially extend cryptographic or security mechanisms, with uncertainty about feasibility or robustness.
• Work includes rigorous analysis, modelling, and testing of security properties, not just implementation.

e. Integration of disparate systems (when the difficulty is technical, not logistical)

Qualifying where:

• The core challenge is not simply wiring APIs together, but solving a non‑trivial technical problem such as:
• Real‑time synchronisation across systems with incompatible data models or semantics
• Achieving strong consistency or correctness guarantees at scale where no standard solution exists
• The team must experiment with new data models, synchronisation strategies, or consistency mechanisms.

3. Software activities that do not qualify

HMRC is explicit that the following are not R&D for tax purposes, even if they are complex or business‑critical:

• Porting existing software to a new platform or language (e.g. .NET Framework to .NET Core, on‑prem to cloud) using known techniques
• Routine testing, debugging, and quality assurance
• Adding features to existing software using established patterns and tools
• Developing business logic or rules, however intricate
• UI/UX design, front‑end work, and styling using existing frameworks and libraries
• Implementing third‑party APIs or integrations using documented interfaces
• Standard database design, schema evolution, indexing, and querying, even at large scale

The decisive question is not whether the work was hard, expensive, or novel to your business, but whether the technical outcome was genuinely uncertain to a competent professional at the outset.

4. AI and machine learning: how HMRC is looking at claims

AI‑related claims have attracted a high volume of enquiries since 2023. HMRC is not opposed to AI R&D, but is challenging:

• Claims that re‑label standard application of ML libraries as R&D
• Projects that use foundation models or APIs without genuine technical uncertainty

The same test applies:

• Not R&D:
• Using OpenAI or similar APIs to build a chatbot or content tool
• Training or fine‑tuning standard models (e.g. transformers, CNNs, gradient boosting) on proprietary data using established techniques
• Potentially R&D:
• Developing a novel few‑shot or zero‑shot learning method that overcomes a documented limitation of existing techniques
• Creating new optimisation, regularisation, or data‑handling methods where it was unclear whether a workable solution existed

HMRC’s software guidance at CIRD82000 is particularly relevant for AI and should be read alongside the DSIT Guidelines when preparing claims.

5. The merged R&D scheme: impact on software companies

For accounting periods beginning on or after 1 April 2024, most software companies fall under the merged R&D scheme.

a. Main merged scheme

• Relief is given as an above‑the‑line credit of 20% of qualifying expenditure.
• After corporation tax at 25%, the net benefit is roughly 15% of qualifying costs.

This applies by default unless the company qualifies for and elects into the ERIS regime.

b. Enhanced R&D Intensive Support (ERIS)

For loss‑making companies that are R&D‑intensive:

• R&D intensity test: qualifying R&D expenditure is at least 30% of total expenditure.
• If met, the company may access a more generous payable credit of up to 14.5% of the surrenderable loss.

This is particularly relevant for:

• Early‑stage software start‑ups with heavy R&D spend
• Deep‑tech, AI, or infrastructure‑focused businesses

Companies should model both regimes (merged vs ERIS) to determine the optimal outcome for each period.

c. Overseas costs restriction

From April 2024, the location of the work is critical:

• Subcontractor and externally provided worker (EPW) costs are only qualifying where the R&D activities are physically carried out in the UK.
• Cost or availability of overseas staff is not accepted as a reason for exemption.

For software companies using offshore or near‑shore development teams, this can materially reduce qualifying expenditure unless key R&D activities are brought onshore.

6. Documentation and the Additional Information Form (AIF)

For all claims submitted on or after 1 August 2023, the AIF is mandatory. For software projects, a robust AIF narrative should clearly set out:

1. The specific technical uncertainty

• What exactly was not known or not achievable at the outset?
• Why was it uncertain to a competent professional, not just your team?

1. Why existing solutions were inadequate

• What published methods, libraries, or architectures were considered?
• Why could they not be readily applied or adapted?

1. The approaches tried (including failures)

• Experiments, prototypes, architectural options, and iterations
• Evidence of trial‑and‑error and learning from negative results

1. How you determined whether the uncertainty was resolved

• Measurable criteria (e.g. latency thresholds, accuracy metrics, reliability targets)
• How you validated that the solution worked (or concluded it could not be achieved)

Software R&D tax relief: what actually qualifies (and what doesn’t)

Software businesses are among the heaviest users of the UK R&D tax relief regime – and among the most frequently challenged by HMRC. Under the merged R&D scheme for periods beginning on or after 1 April 2024, the core eligibility rules have not changed, but the economics and the level of scrutiny have.

Below is a practical summary of how HMRC currently views software R&D, what typically qualifies, what does not, and how to reduce enquiry risk.

1. The core test: technological uncertainty

Under the DSIT Guidelines and CTA 2009 s1042, R&D for tax purposes must:

• Seek an advance in science or technology, and
• Do so by resolving scientific or technological uncertainty.

For software, this means:

• The work must go beyond what a competent professional could readily achieve using existing knowledge, tools, and techniques.
• The uncertainty must be technical, not just:
• Commercial (e.g. will customers buy it?)
• Organisational (e.g. can we deliver on time?)
• Internal (e.g. our team hasn’t done this before).

HMRC’s CIRD81900 guidance is explicit: routine software development, even if complex or time‑consuming, is not R&D.

Example – non‑qualifying:

• Building a standard e‑commerce platform using a known framework, patterns, and libraries.

Example – potentially qualifying:

• Developing a novel real‑time pricing engine where:
• Existing algorithms or architectures could not meet latency/throughput constraints.
• Competent engineers could not predict in advance whether the proposed approach would work.
• You had to design, test, and iterate on genuinely uncertain technical solutions.

2. What typically qualifies in software

HMRC has become more prescriptive, especially since the Additional Information Form became mandatory. The following types of work often support successful claims, provided you can evidence genuine technological uncertainty and systematic experimentation.

2.1 Novel algorithm development

Qualifying where:

• Existing algorithms were demonstrably insufficient for the required performance, accuracy, or constraints.
• A new or materially modified algorithmic approach had to be designed, tested, and validated.

Key point: “novel” means more than adapting a published algorithm to a new business context. You need to show that:

• Known algorithms could not meet your requirements, or
• You had to resolve non‑trivial technical questions about feasibility, stability, or performance that were not already solved in the field.

2.2 Performance at scale

Qualifying where you are pushing technical boundaries on:

• Throughput
• Latency
• Concurrency