R&D tax credits for AI companies.

For accounting periods beginning on or after 1 April 2024, most companies now claim under the merged R&D expenditure credit scheme. This replaced the previous split between the SME R&D scheme and the large company RDEC scheme. A separate Enhanced R&D Intensive Support route — referred to as ERIS — remains for qualifying loss-making SMEs.

The standard merged scheme credit is 20% of qualifying R&D expenditure. Because the credit is taxable, the net cash value is normally 15% where the company pays Corporation Tax at 25%, or 16.2% where the company is taxed at the 19% small profits rate. Loss-making R&D-intensive SMEs may be able to claim ERIS where qualifying R&D expenditure is at least 30% of total expenditure. The enhanced payable credit rate is 14.5%.

AI companies are particularly affected because their costs often include cloud compute, API usage, datasets, annotation, subcontracted development, and loss-making growth-stage profiles. The rules now specifically bring data licences and cloud computing into scope where used directly for qualifying R&D, but those costs still need to be apportioned and linked to qualifying activity — and the apportionment is exactly where most generalist claims get into trouble.

For detailed guidance see the R&D merged scheme and ERIS overview and the ERIS intensity threshold detail on GOV.UK.

The starting point is not whether the company uses AI. The test is whether the project seeks an advance in science or technology by resolving scientific or technological uncertainty that could not readily be resolved by a competent professional working in the field.

Likely qualifying examples include custom model development where the team is attempting a genuine technical advance, novel architecture work, non-routine performance optimisation, reproducibility or latency challenges, safety and evaluation methodology, and technically difficult data pipelines.

Less likely examples include routine use of a foundation model via API, ordinary prompt writing, generic chatbot implementation, normal data cleaning, commercial dataset selection, ordinary product integration, and standard application development using existing tools.

Prompt engineering at scale may qualify only in unusual cases. Where the work is really about resolving a technical uncertainty around reliability, reproducibility, safety, automated evaluation, latency, or system behaviour, there may be an R&D project. Where it is simply testing wording, tone, output quality, marketing copy, or customer-facing instructions, it should not normally be claimed.

The competent professional test is important. For AI work, this will usually be a CTO, senior ML engineer, research scientist, data infrastructure lead, or another person with relevant specialist experience. A founder or product manager may be helpful evidence, but they are not automatically a competent professional unless they have the relevant technical expertise.

HMRC’s published software guidance, case studies on R&D in software, and DSIT Guidelines on competent professionals set out the detailed framework.

Staff costs can qualify where employees are directly or indirectly engaged in qualifying R&D. For AI companies this often includes ML engineers, data engineers, infrastructure engineers, senior technical founders, and research leads. The claim should be apportioned by time spent on qualifying R&D, not by job title. Employer NIC and employer pension contributions can usually be included where linked to qualifying staff time.

Externally provided workers and subcontractors need careful treatment because the rules changed under the merged scheme. Broadly, the claimant should identify who decided to undertake the R&D, who bore the risk, and whether the expenditure falls within the permitted qualifying categories.

Cloud compute can qualify where it is directly used for qualifying R&D — such as model training, experimentation, data processing, or evaluation. Production hosting and customer inference costs should normally be excluded unless they are part of qualifying experimentation. Self-hosted GPUs are normally capital assets, so relief is usually through capital allowances rather than revenue R&D expenditure.

API costs can qualify only where the API use is part of qualifying R&D. API costs for production inference, customer delivery, internal marketing, support, or routine product use should not be included. Software licences, datasets, annotation services, and foundation model access fees need to be reviewed line by line and apportioned where mixed use exists.

Common over-claims include claiming all cloud hosting, claiming all OpenAI or Anthropic spend, claiming all engineer salaries, claiming customer delivery as R&D, claiming routine data labelling, and claiming product management or sales engineering as technical R&D.

See HMRC’s R&D qualifying costs guidance and the draft guidance update on data and cloud apportionment.

Under the merged scheme, the basic principle is that the company that decides to undertake or initiate the R&D is normally the claimant. A subcontractor that merely performs R&D for another company will not automatically be entitled to claim. The contracts, commercial risk, IP position, and practical control over the project all matter.

Consider this worked example: a UK AI startup commissions a UK ML consultancy to solve a model latency problem that the startup has identified. The startup defines the technical objective, funds the work, owns the output, and bears the commercial risk. The startup is likely to be the party that initiated the R&D and should consider claiming the qualifying subcontracted cost, subject to the detailed rules. If instead the consultancy independently develops its own generic tooling to solve problems across its wider customer base, that separate internal project may belong to the consultancy.

Common traps include customer contracts that make the customer the true initiator of the R&D, US parent companies directing UK subsidiary research without proper recharge or risk allocation, overseas subcontractors, vague statements of work, and the assumption that the party doing the coding is automatically the claimant.

See HMRC’s contracted-out R&D guidance for the detailed rules.

AI R&D claims should be built from contemporaneous evidence, not reconstructed after the year end. Good evidence includes architecture decision records, experiment plans, failed training logs, benchmark comparisons, evaluation reports, model cards, incident logs, data pipeline diagrams, safety testing notes, and written explanations from the competent professional.

Cost apportionment should be documented. Practical methods include timesheets, sprint allocation, project tagging in engineering tools, cloud billing tags, separate API projects, separated production and R&D environments, and written allocation assumptions reviewed by the technical lead and finance team.

Companies must submit an Additional Information Form for R&D claims. HMRC can reject or remove claims where the required additional information is not submitted in the required way. See the Additional Information Form guidance for what must be included and when.

Claiming prompt engineering or output tuning as R&D without a real technological uncertainty.

Treating all API spend as R&D rather than separating production, internal, development, and qualifying R&D usage.

Claiming all engineering time rather than apportioning by project and activity.

Assuming cloud compute automatically qualifies because it is expensive.

Missing qualifying data and cloud costs where there is clear R&D use and good apportionment — the inverse of over-claiming, and equally damaging because it leaves real money on the table.

Weak competent professional evidence, especially where the narrative is written by finance or marketing rather than the technical team. HMRC is particularly attentive to who actually wrote the technical justification and whether they have the credentials to make those claims.

Claim where the company has a genuine technical uncertainty, material qualifying costs, and evidence that the uncertainty could not readily be resolved by a competent professional. Do not claim simply because the product uses AI, LLMs, automation, or data science.

Loss-making companies should compare the merged scheme and ERIS carefully — the cash value and timing differ, and the right route depends on the company’s specific profile. Multi-year strategies should be consistent: a project may have qualifying phases and non-qualifying phases, and the claim should reflect when uncertainty starts and ends.

A specialist is advisable where the claim includes foundation model API costs, subcontracting, cross-border teams, significant cloud spend, or complex customer-funded development. Most generalist accountants are not equipped to navigate the apportionment, contracted-out rules, and competent professional evidence requirements that distinguish a survivable AI R&D claim from a precarious one.