Developer working on R&D software project

Typical claim values for software businesses

Software and technology companies typically claim between £18,000 and £85,000 per year under the Merged RDEC Scheme, depending on team size, the proportion of time spent on qualifying development, and whether subcontractor costs are included. Businesses with 5–15 developers working on genuinely novel products or systems are often in the £30,000–£60,000 range.

£18k–£85k
Typical annual claim range for software & technology businesses under the 2026 Merged RDEC Scheme. Actual figures depend on qualifying spend and team size.

Three qualifying activity examples

The following are examples of activities that typically qualify for R&D relief in software businesses. In each case, the key is that the technical outcome was uncertain and required experimentation — it was not simply a matter of applying known techniques.

1. Building a real-time data processing system with novel performance requirements

A SaaS business needed to process and analyse high-volume event streams with sub-100ms latency — a requirement that existing off-the-shelf message queue architectures could not reliably meet at scale. The team spent six months experimenting with custom partitioning logic, novel caching strategies, and bespoke indexing approaches before arriving at a working architecture. The uncertainty was genuine — the final approach was not known at the outset and several early attempts were abandoned. This is qualifying R&D: a specific technical problem, genuinely uncertain outcome, systematic investigation.

2. Developing a machine learning model for a domain with no existing labelled dataset

A software company building a legal document analysis tool needed to train a classification model on a corpus of UK contract language — for which no pre-existing training data existed. The team developed a novel data synthesis approach, iterated on model architecture across multiple approaches, and resolved multiple technical uncertainties around domain-specific tokenisation before achieving acceptable accuracy. Training costs, staff time, and cloud compute costs all qualify. The novelty of the problem — and the iterative, uncertain nature of the solution — is exactly what the R&D test is designed to capture.

3. Solving a compatibility and integration problem with no documented solution

A developer tools business built an integration layer between two enterprise systems whose APIs were poorly documented, frequently changed, and had never been officially connected before. The team spent several months reverse-engineering undocumented behaviour, developing workarounds for edge cases, and building a novel translation layer. While this may look like "just integration work" on the surface, the genuine technical uncertainty involved — and the absence of any known solution path — makes it qualifying R&D. The technological uncertainty test does not require ground-breaking science, it requires a genuine technical problem where the answer was not already known.

HMRC scrutiny level — medium

Medium scrutiny — software claims are examined carefully but not in the highest-risk category

Software is one of the most common sectors for R&D claims, which means HMRC has significant experience reviewing them. Claims from software businesses receive medium-level scrutiny — higher than life sciences (where the R&D is typically well documented) but lower than digital agencies or construction, where overclaiming has been most prevalent.

The main trigger for elevated scrutiny in software claims is vague project descriptions. A claim that describes development work in generic terms — "we built a new feature," "we improved our platform's performance" — without articulating the specific technical challenge and why it was uncertain will attract follow-up questions. Specific, technical language in the claim narrative significantly reduces this risk.

Common mistakes software businesses make

Claiming for routine development alongside genuinely novel work. Many software businesses include all their developer time in an R&D claim, when in reality only a portion of that time was spent on work involving genuine technological uncertainty. The rest — building features using established frameworks, fixing bugs in standard ways, maintaining existing systems — does not qualify. An HMRC enquiry will ask for project-by-project breakdowns, and a claim that cannot demonstrate clear delineation between qualifying and non-qualifying work is vulnerable.

Treating subcontractor costs as fully claimable without checking the 65% restriction. Under the Merged Scheme, payments to unconnected subcontractors are capped at 65% of the actual cost for R&D relief purposes. A business that includes £100,000 in contractor costs can claim on a maximum of £65,000. This cap is frequently missed, particularly by businesses that rely heavily on freelance developers.

Not maintaining contemporaneous records. Code commits, sprint retrospectives, technical design documents, and Slack threads from the time of development are far more convincing evidence of R&D activity than a retrospective claim narrative. Software businesses typically have a wealth of this documentation already — it just needs to be organised and referenced in the claim.

If your business has been developing novel software for more than 12 months and has not yet claimed R&D relief, there is likely a significant unclaimed amount sitting in your prior year accounts. Claims can be made within two years of the end of the accounting period — meaning prior year claims may still be available.

Find out what your software business could claim

Free eligibility grader — 7 questions, personalised result, no registration required.

Check eligibility free →