Software R&D Tax Relief
Claims & Tax Credits for UK Software Firms
Professional R&D tax relief claims for software companies. SaaS, AI/ML, real-time systems, IoT platforms and developer infrastructure.
When can software and technology work qualify?
The starting point is the scientific or technological advance being sought. It must be an advance in the overall knowledge or capability of the relevant field, not simply something new to the company.
The company must identify the scientific or technological uncertainties encountered and explain why their resolution was not readily available or deducible to a competent professional. Qualifying activities directly contribute to resolving those uncertainties, together with certain qualifying indirect activities.
A commercially unsuccessful or abandoned project can still contain qualifying R&D. Success is not the test. The purpose of the work, the state of knowledge when it began and the method used to address the uncertainty are what matter.
Projects that may contain qualifying R&D
These examples indicate where qualifying work can arise. They do not mean that every project of that type qualifies, or that every activity and cost within a qualifying project is eligible.
Performance, scale and latency limits
Work to overcome a throughput, latency, concurrency or resource constraint where established architectural patterns, database techniques and optimisation approaches could not deliver the required result, and the solution had to be found experimentally. Profiling, tuning, caching and refactoring using known techniques is standard engineering practice, however difficult the debugging.
Distributed systems and data consistency
Projects addressing consistency, ordering, partition tolerance, recovery or synchronisation behaviour where the required guarantees could not be met by existing approaches. Adopting a known distributed pattern, message broker or consensus algorithm, or moving to microservices, is architecture rather than advance.
Algorithm and model development
Developing a novel algorithm, model architecture or training approach where the outcome was not deducible from the published state of the art. Training, fine-tuning or prompting an existing model on your own data, integrating a commercial AI service, or applying a documented technique to a new domain is application of existing technology, not an advance in it.
Systems integration where the interface behaviour is unknown
Connecting systems, protocols or devices where the technical behaviour of the combination could not be predicted, for example undocumented legacy interfaces, hardware timing constraints, or reconciling incompatible data models at volume. Building integrations against documented APIs, however many of them, is routine development work.
Data engineering at the limits of existing methods
Work on ingestion, normalisation or processing where the volume, velocity, variability or quality of the data defeated established approaches and a technological solution had to be developed. Building a pipeline, warehouse or ETL process using established tooling does not qualify because the dataset is large.
Security, privacy and cryptographic engineering
Projects seeking an advance in how systems resist attack, preserve privacy or handle sensitive data, where the required properties could not be achieved using established methods. Implementing known controls, encryption libraries, authentication standards or a compliance framework is implementation, not research.
Embedded, real-time and hardware-adjacent software
Firmware and real-time work where timing, determinism, resource limits or behaviour under physical constraints could not be guaranteed in advance and had to be resolved through experimentation. Writing embedded software to a known specification using established toolchains is development.
What normally does not qualify?
- Building a product, platform or feature using established languages, frameworks, libraries and patterns, however large or complex the build.
- Work that is new to your team or your company but established in the wider field.
- Configuration, customisation, integration against documented APIs, and deployment of third-party or open-source software.
- Using AI rather than advancing it, including prompting, fine-tuning, retrieval augmentation and building on commercial model APIs.
- Migration, replatforming, cloud adoption and infrastructure modernisation using known approaches.
- User interface, user experience, accessibility and design work.
- Routine testing, QA, bug fixing, refactoring, code review, security patching and maintenance.
- Business analysis, requirements gathering, project management and work undertaken to satisfy a regulatory, certification or customer security requirement.
Commercial novelty is not technological advance. A product being first to market, technically ambitious, expensive to build or genuinely useful does not make it R&D. The question is always what a competent software professional could readily have deduced at the point the work began, and whether your team had to go beyond that.
What evidence supports a claim?
Evidence should show what was known at the start, what advance was sought and why the technical route was not readily deducible. Software teams usually hold more of this than they expect. Useful contemporaneous evidence can include:
- Commit histories, branches and pull requests showing what was attempted and abandoned.
- Architecture decision records, RFCs, design documents and spike tickets.
- The technical baseline, including the approaches, libraries or published methods considered and rejected.
- The identity and relevant experience of competent professionals.
- Benchmarks, load tests, profiling output and the constraint being worked against.
- Issue tracker history connecting work to specific technical problems.
- Contracts and client specifications, which determine who is entitled to claim.
- Time records or sprint data connecting named people to specific work.
None of this needs to have been created for the purpose of a claim. The one thing that is genuinely hard to reconstruct later is why an approach was rejected, so a short note at the time is worth a great deal at enquiry.
Which costs may be included?
The rules for contractors, externally provided workers and overseas activity require particular care. Eligibility depends on the accounting period, contractual arrangements, who decided to undertake the R&D and where the work took place.
Production and distribution costs, capital expenditure, land and the cost of patents or trademarks are not qualifying R&D expenditure under these reliefs.
Cloud computing, data licence and software costs can qualify where used directly in the qualifying R&D, but not where they support the wider business or run production workloads. Where a single subscription or environment covers both, the cost must be apportioned on a reasonable and documented basis rather than claimed in full.
See the qualifying R&D costs guideR&D Tax Relief Calculator
Fill in the boxes, your estimate updates as you type.
For financial periods starting on or after 1 April 2024
Tell us about your business
Enter your best estimate of spend on qualifying R&D activity. This is not your total development, engineering or project budget.
Qualifying spend covers only the staff time, contracted-out R&D, externally provided workers, consumables, software, data licence and cloud costs attributable to work that sought a scientific or technological advance. Most companies overestimate this figure before a technical review, so treat whatever this produces as an upper bound rather than a target.
For periods beginning on or after 1 April 2024, overseas contracted-out R&D and externally provided worker costs are generally restricted. Limited exceptions apply where necessary conditions cannot reasonably be replicated in the UK; lower costs or overseas worker availability alone are not enough.
How Lexmore helps
1. Assess the technical position
We speak with the people who understand the work and test each project against the tax definition of R&D. If we do not believe the work meets the test, we say so before recommending a claim.
2. Establish the evidence
We identify the baseline, advance, uncertainties, competent professionals and supporting records, including any gaps that should be addressed before submission.
3. Review the expenditure
We map costs to qualifying activities, consider the relevant scheme and document the basis of any apportionment and external arrangements.
4. Prepare the claim
We prepare the technical and financial support and the Additional Information Form, then coordinate the Corporation Tax return position with the company or its accountant.
5. Provide enquiry support
If HMRC opens an enquiry, we manage correspondence and defend the technical and financial basis of the claim. We cannot determine HMRC's decision or represent clients at tribunal.
If a claim is reduced or denied, the company may have to repay relief and HMRC may charge interest and, in some circumstances, penalties. Read about R&D enquiry support.
Which R&D scheme applies?
For accounting periods beginning on or after 1 April 2024, qualifying companies generally claim under the merged R&D expenditure credit scheme. Enhanced R&D Intensive Support may instead be available to a qualifying loss-making, R&D-intensive SME.
Earlier periods fall under the previous SME and R&D expenditure credit rules. The accounting period, company position, contracting arrangements and any connected companies must be considered before treatment can be confirmed.
Find out which R&D scheme applies.Could Patent Box also apply?
Patent Box is less commonly relevant to software companies than to other technology businesses, and it is worth being direct about why. Computer programs as such are excluded from patentability in the UK, so most software is protected by copyright rather than by patent. A software business with no granted patent has nothing to elect into.
It can become relevant where a company holds a granted UK or European patent covering a technical invention that a program implements, which in practice tends to mean hardware, signal processing, communications, control, imaging or embedded systems rather than a web or SaaS product. Where a qualifying patent exists, the company owns it or holds an exclusive licence, has undertaken qualifying development on it, and earns income from exploiting it, an effective 10% Corporation Tax rate can apply to qualifying relevant IP profits after the required calculation. That is a share of profit, not revenue, and usually a smaller share than the headline rate implies.
If you hold or are pursuing a patent, it is worth a review, and an election is required within a time limit. If you do not, Patent Box is unlikely to be the right conversation, and we will say so rather than run the analysis.
Explore Patent Box tax relief.R&D claim deadlines
For a period of account lasting 18 months or less, the claim deadline is generally 24 months from the final day of that period. A different 42-month rule applies where the period of account is longer than 18 months.
Some companies must also submit a claim notification within six months after the end of the period of account. Exemptions and exceptions apply, so previous claims and filing dates must be checked.
See how and when to make an R&D claim.Frequently asked questions
Does building a SaaS platform qualify?
Not because it is a platform, and not because nothing exactly like it existed before. Most SaaS development uses established frameworks, patterns and infrastructure, which is skilled engineering rather than R&D. The parts that can qualify are usually narrow and specific: a performance ceiling nobody had a known route past, a consistency problem that established patterns could not solve, an integration where the behaviour was genuinely unknown. A good claim identifies those parts and excludes the rest of the build.
Does using AI or machine learning qualify?
Using AI is not advancing it. Fine-tuning an existing model, building retrieval or agent workflows around a commercial API, or applying a published technique to your own data is application of existing technology, and HMRC treats it that way. Work can qualify where you sought an advance in the underlying technology, for example a novel training approach, a model architecture that did not previously exist, or making inference work within resource constraints that no published method addressed. The claim needs to state precisely what capability was unavailable and why.
Our developers spent months on it and it was genuinely hard. Is that enough?
No, and this is the most common misunderstanding in software claims. Difficulty, duration and cost are not the test. Plenty of hard software work is hard because of scale, legacy constraints, integration volume or deadline pressure, none of which is technological uncertainty. The question is whether a competent software professional, given the problem, could readily have worked out how to solve it. If the answer is yes and it was just a lot of work, it is not R&D.
Can we include contractors, agencies and offshore developers?
It depends on the arrangement and where the work was done. For accounting periods beginning on or after 1 April 2024, entitlement to contracted-out R&D turns in part on which party intended or contemplated that R&D would be undertaken, so if you develop to a client's specification the client may be the party entitled to claim. Separately, costs for contracted-out R&D and externally provided workers relating to activity carried out overseas are generally restricted, with limited exceptions where the necessary conditions cannot reasonably be replicated in the UK. Lower cost or availability of overseas developers is not one of those exceptions. Both points need checking against the contracts before any cost is included.
What evidence should we keep, given we do not write documentation?
Software teams usually hold better contemporaneous evidence than they think. Commit histories, pull requests and branch structure show what was attempted and abandoned. Architecture decision records, spike tickets, RFCs and design docs establish the baseline and the alternatives considered. Benchmark results, load tests and incident write-ups evidence the constraint you were working against. Sprint tickets and time tracking connect named people to specific work. None of it needs to have been created for a claim. The one thing that is genuinely hard to reconstruct afterwards is why an approach was rejected, so a short note at the time is worth a great deal later.
Discuss your software and technology projects
We will help establish which parts of your development work meet the R&D definition, what evidence supports them, and whether preparing a claim is appropriate. Software claims attract more HMRC attention than most, so the boundary between qualifying work and ordinary development is where we spend the time.
If we do not believe the work meets the test, we will tell you plainly and before you have committed to anything.