R&D tax relief for software teams
UK R&D tax relief was not written for any single industry, but software teams are squarely inside it - most of the qualifying spend is engineers' salaries. The tests are the same as everywhere else: a technical advance, and uncertainty a competent professional couldn't readily resolve. Here's how they apply to software work specifically.
The advance and uncertainty tests, applied to software
An advance in the field, not the product
Shipping a new feature is not, by itself, an advance. The test asks whether you sought an appreciable improvement in a field of technology - distributed systems, machine learning, compilers, performance engineering - beyond what was publicly known or readily available. Novel scaling work, new algorithmic approaches and systems that push past documented limits are where software claims live.
Uncertainty a competent professional couldn’t resolve
A matter is a qualifying uncertainty only if a competent professional in the field couldn’t readily work it out from public knowledge without significant effort. “Our team found it hard” is not the bar; “an expert couldn’t have looked up the answer” is. Stack Overflow having the solution is usually a bad sign; your team running structured experiments because nobody had the answer is a good one.
For the full breakdown of both tests - and the five things every claim narrative must show - read what counts as R&D
Qualifying work vs routine development
- Novel scaling or performance work - holding latency targets at orders-of-magnitude more load
- Algorithmic, ML and pure-maths work (pure mathematics is in scope from April 2023)
- Distributed-systems consistency, concurrency and fault-tolerance problems
- Work constrained by hardware, real-time or resource limits with no known solution
- Standard CRUD apps, websites and cosmetic UI
- Routine bug fixes and configuration
- Integrating documented, off-the-shelf APIs and SDKs
- Commercial (non-technological) uncertainty - e.g. “will it sell?”
Real projects are usually a mix: a product build that is mostly routine can contain a genuinely qualifying core - the part where the team hit a wall no documentation could get them over. The claim covers that part, apportioned honestly, not the whole roadmap.
Common misconceptions
“We don't do R&D - we just build software.”
The definition doesn't require lab coats. If your engineers sought an advance in a field of technology and faced unknowns a competent professional couldn't readily resolve, that work can qualify - whatever your product is.
“It was new to us, so it qualifies.”
The opposite trap. The advance must be in overall capability in the field, not just new to your company. Learning an existing technique - however painful - is not R&D.
“It was really hard, so it qualifies.”
Effort is not uncertainty. The bar is whether a competent professional in the field could readily work out the answer from public knowledge without significant effort - not whether it was hard for your team.
“We'll write it up at claim time.”
You can, but a write-up assembled from memory is much weaker than the contemporaneous record your team created while doing the work - and contemporaneous records are what an HMRC compliance check asks for.
The evidence a software team actually needs
The record you already created
Software teams have a structural advantage: the work leaves a contemporaneous trail by default. Commits, pull requests, tickets, design docs and test logs are timestamped, attributable records created while the uncertainty was live - exactly the class of record an HMRC compliance check requests. What counts as a contemporaneous record
Organised around HMRC’s own structure
Since August 2023 every claim needs the Additional Information Form: a project-by-project account of the field, baseline, advance, uncertainty and approach. Aven reads your engineering history read-only - never your source code - and assembles it into an AIF-aligned evidence pack, with every narrative statement linked to the record that evidences it, for your accountant or R&D tax firm to review and file from.
Common questions
Does ordinary software development qualify for R&D tax relief?
Routine development - standard CRUD apps, websites, cosmetic UI, bug fixes, configuration and integrating documented APIs - doesn't qualify. Work qualifies where you sought an appreciable advance in a field of technology and faced uncertainties a competent professional couldn't readily resolve from public knowledge.
Do machine learning and algorithmic work qualify?
They can, provided the advance and uncertainty tests are met. Pure mathematics has been within the R&D definition since April 2023, which matters for ML, AI and algorithmic work.
What costs do software teams typically claim?
For most software teams the bulk is staff costs - salaries, employer NIC and pension for engineers doing or directly supporting R&D, apportioned to the R&D. Externally-provided workers and subcontractors are restricted (generally only 65% of unconnected payments), and data-licence and cloud-computing costs qualify from 1 April 2023.
What evidence does a software team actually need?
Contemporaneous records: the commits, pull requests, tickets, design docs and test logs your team created while doing the work. HMRC's compliance checks ask for exactly these - version-control records and ticket threads are on its request list - so a claim whose narrative traces to that record is far stronger than one written from memory.
Aven assembles R&D evidence packs for accountant review; Aven Reviewed adds expert review. Aven does not file with HMRC, determine your liability, select your scheme (merged vs ERIS), sequence loss relief, or guarantee any amount - those are your accountant or R&D tax firm's responsibility. Figures are indicative and conservative. Nothing here is tax advice. UK only.
Your engineers solved the hard problems. Evidence it.
The Eligibility & Readiness assessment is free, takes a few minutes, and tells you honestly whether Aven is the right fit.
Check your eligibility - free