Software work qualifies for UK R&D tax relief when it is part of a project that seeks an advance in science or technology, and when the activity directly helps resolve a technological uncertainty. Building a product is not enough. Building something that a competent professional could not have worked out in advance is. This guide shows where that line sits for software, which activities and costs count, which ones HMRC treats as routine, and what to write down while the work happens.

Priceandaccountants
priceandaccountants.com
Make Your Software R&D Claim Count
Price & Accountants helps innovative companies with R&D tax claims, bringing specialist support to software projects tackling technological uncertainty.
Explore R&D tax support

TL;DR

Table of Contents

The test HMRC applies to software

HMRC does not have a separate definition of R&D for software. The same two-part idea applies to every sector. First, the project must seek an advance in a field of science or technology. Second, the work you claim must be activity that directly contributes to resolving the scientific or technological uncertainty in that project, or a recognised qualifying indirect activity.

Software sits in the field of computer science and information technology. That is why so many claims come from software companies, and also why so many are challenged. A SaaS roadmap full of customer features is mostly product development. A project that tries something the field has not yet shown to be possible is R&D.

What counts as an advance

The GOV.UK guidance on R&D relief describes an advance as an increase in overall knowledge or capability in a field, not only your own company’s knowledge. It can be something new that raises overall capability, or an appreciable improvement to something that already exists.

The HMRC manual adds the other side. The advance must not be routine analysis, copying or adaptation of existing work. Rebuilding a known feature in a new framework because your team has not done it before may be a hard job, but it is not an advance in the field if other competent professionals would know how to do it.

A useful self-test: could a skilled developer outside your company, with access to public knowledge, have specified the solution at the start? If yes, the project probably does not meet the threshold.

What technological uncertainty looks like in code

An uncertainty exists when a competent professional could not readily work out whether the goal is technologically possible, or how to achieve it. HMRC’s guidance asks you to show that an expert could not have determined the answer after considering the available evidence, and to explain the work done, including the failures as well as the successes.

The competent professional is judged against what was in the public domain or readily deducible. HMRC’s older BIS guideline material says that the competent professional should be able to explain how the project is new or appreciably improved relative to that baseline.

Examples of the kind of problem that usually points to a real uncertainty (these are illustrations, not a list HMRC publishes):

Examples that usually do not: adding a payment provider through its documented API, building a dashboard with a standard charting library, or migrating a database with well-known tools.

Software activities that can qualify

The HMRC manual at CIRD81910 says qualifying activities include creating or adapting software to resolve the uncertainty, and the scientific or technological planning, design, testing and analysis that go with it. Training needed to directly support an R&D project can qualify as an indirect activity.

In practice, for a software project that passes the advance and uncertainty test, the following are usually part of the claim:

Activity Typically qualifies? Why
Prototyping an unproven architecture Yes Directly tests whether the approach is feasible
Writing and revising code to resolve the uncertainty Yes Creating or adapting software is named as qualifying
Designing experiments, benchmarks and test harnesses Yes Testing and analysis directly resolve the uncertainty
Integration work where the interface is itself the unknown Yes, if the interface problem is the uncertainty Integration is only R&D when it is not a routine assembly
Fixing failed tests and iterating Yes Failures are evidence of the uncertainty being worked on
Training needed for the R&D project Possibly, as an indirect activity Only where required to directly support the project
Routine assembly of components or sub-programs No Excluded as routine
Market research, pricing, launch and sales No Commercial steps do not resolve technological uncertainty
Deployment, hosting at scale, ongoing production support No Production and distribution are outside direct R&D

Tools built to support a bigger project

There is one point founders often miss. Software created or adapted solely as a tool for direct use in a larger R&D project can qualify, even if the larger project seeks an advance in another field. A custom simulation environment built for a hardware or biotech project is the usual example. For a fintech, a bespoke testing rig built to resolve a modelling uncertainty may fit.

Integration and testing are not automatically routine

Integration and testing are the two activities most often argued over. Testing that checks whether the uncertainty has been resolved is core R&D. Testing that checks a finished feature works before release is quality assurance on a product, and it sits on the commercial side. Integration is the same: wiring up two documented systems is routine assembly, while making incompatible systems work together where no known method exists can be the very uncertainty you are investigating.

The practical way to separate them is to ask what question each task answers. If the answer is “will this work at all, and how?”, it belongs in the claim. If it is “is this ready to ship?”, it generally does not.

What stays out, even on a qualifying project

A project can qualify while parts of the work around it do not. The manual states that commercial and financial steps, non-technological work, and production and distribution do not directly contribute to resolving uncertainty, although qualifying indirect activities may still count as R&D.

For a software business, the exclusions usually include:

Splitting the project cleanly is also what makes a claim defensible. HMRC’s expectation is that you define each project by the specific advance sought and the uncertainties to be resolved, then count only activities that connect directly to those uncertainties, or are recognised indirect activities. A vague project called “platform v2” invites trouble. A project called “real-time reconciliation across three ledgers with sub-second consistency” can be assessed.

Software costs that can be claimed

Qualifying activity is only half of the picture. The cost must also be a qualifying category and relate to the R&D.

Staff costs. Time spent by developers, engineers and others on the qualifying activities, apportioned sensibly. Our guide to R&D staffing costs and payroll evidence covers how to tie payroll to project time.

Cloud computing and data licences. For accounting periods starting on or after 1 April 2023, data licence and cloud computing service costs can be qualifying R&D expenditure when they directly contribute to resolving the scientific or technological uncertainty. Test environments, training runs for a model and licensed datasets used in experiments are the typical cases. Production hosting for paying customers is not.

Shared software. Where one product is used by R&D and non-R&D staff, HMRC recommends a pragmatic approach to apportionment, such as using staff numbers. Keep the method simple and write it down.

Subcontractors. Subcontracted R&D can qualify, but for unconnected subcontractors the claim is generally restricted to 65% of the payment made. If you use an outside dev shop, our subcontractor costs guide walks through it.

Four categories of qualifying software R&D costs

Expenditure must also be revenue in nature, deductible for corporation tax, and incurred on R&D relevant to your trade. For a broader view of eligible spend, see our piece on R&D eligible costs for UK SMEs.

How to define a software R&D project

Most weak claims fail at the definition stage, not the maths. A workable approach:

  1. Name the field and baseline. What did the best publicly known approach look like when you started?
  2. State the advance you sought. What would be better, or newly possible, if the project worked?
  3. List the uncertainties. Write each as a specific technical question, not a business goal.
  4. Record what you tried. Hypotheses, experiments, results, dead ends.
  5. Mark the end point. When the uncertainty was resolved, or the attempt abandoned. Work after that point is usually development of a known solution.
  6. Map the people and costs. Who worked on which uncertainty, and for how long.

HMRC’s own guidance for claimants says each project summary should state the field, baseline, intended advance, uncertainties and how you sought to overcome them. If you write your internal notes in that shape from the start, the claim writes itself.

Why failed tests matter

Failure is evidence. A branch that did not work, a benchmark that missed its target and a model that overfitted all show that the answer was not obvious. Teams delete these. Do not. Our article on R&D record keeping for tech startups explains how to keep that trail with the tools you already use, such as issue trackers, pull requests and experiment logs.

Claim requirements to check for your period

Qualifying activity gets you to the claim. The procedure then decides whether it is accepted. These rules apply to accounting periods starting on or after 1 April 2023.

The rules have changed more than once in recent years, so confirm the current position on GOV.UK for your own accounting period before filing. We cover the deadlines in more detail in R&D claim deadline: statutory limits and the ANF gateway, and the consequences of getting a submission wrong in amending or disclosing R&D claim errors.

Our view on software R&D claims

We see the same pattern with tech founders. The product is genuinely hard, the team is excellent, and the claim is still weak, because nobody wrote down what was unknown at the start. The technical work is rarely the problem. The paper trail is.

Our advice is to treat the claim as a by-product of engineering practice. Agree the project boundaries with your CTO at the beginning of the year, tag tickets by project and uncertainty, and keep experiment notes. Then review once a quarter, not once a year in a panic when the accounts are due. We also tell founders when a project is not R&D. A claim that overreaches costs more in time, enquiries and credibility than the relief is worth, and a clean, modest claim is easier to repeat every year as the company moves from pre-seed towards Series A.

The second point is that R&D should sit inside your wider finance picture. Your accounting period, payroll records, cloud bills and funding plans all feed into the claim, and into investor due diligence. When those records are kept in one cloud ledger, the claim is a report, not a project.

— Rahamut

Working with us on your claim

If you run a UK tech or fintech limited company and want a second pair of eyes on whether your software work qualifies, our R&D tax credit service is built around exactly this: scoping projects, mapping costs and preparing the information HMRC now asks for. Ongoing accounting, payroll and finance director support are on the pricing page, with plans starting at £249 per month for Core Services, £549 per month for the Blue Plan and from £1,999 per month for the Black Plan.

FAQ

Does all software development qualify for R&D tax relief?

No. Only work in a project that seeks an advance in science or technology, and that directly tackles a technological uncertainty, qualifies. Routine assembly of components, copying and adapting existing solutions, and commercial or production activity are excluded.

Can cloud hosting and testing environment costs be claimed?

For accounting periods starting on or after 1 April 2023, cloud computing and data licence costs can qualify when they directly contribute to resolving the uncertainty. Costs of running the live product for customers do not. Keep invoices that show which environments were used for the R&D.

Can an agile team that never wrote a specification still claim?

Yes, the method of working does not decide eligibility. What matters is that you can show the uncertainty, the experiments and the outcomes. Tickets, commits and test results kept as you go are usually enough to rebuild that story.

Do I need to tell HMRC before I claim?

Some companies do. For periods starting on or after 1 April 2023, first-time claimants and companies whose last claim was more than 3 years earlier must submit a Claim Notification within 6 months after the period ends. Every claim also needs an Additional Information Form.

Sources