Eight mistakes that get UK software companies' R&D tax credit claims rejected

HMRC compliance checks on R&D claims were relatively rare before August 2023. Today the rate sits between 17% and 20%. Of those compliance checks, 77% result in an adjustment to the claim. In 2023-24 alone, HMRC recovered £441 million.

If you are a CTO or founder of a UK software company, those numbers should change how you think about your next claim. This is not a paperwork exercise you can hand off to a junior accountant and forget about. Get it wrong and you are looking at an average 246-day compliance check, frozen cash flow, and in the worst cases, criminal prosecution.

One startup had two consecutive claims of £70k and £90k rejected outright. They laid off three employees while waiting for the outcome. They eventually won on appeal after 14 months, but by then the damage was done. Some investors now advise portfolio companies not to factor R&D credits into cash flow projections at all. That is an overreaction, but it tells you where the market's confidence has landed.

Here is the thing worth knowing: 90% of non-compliance is misinterpretation, not fraud. These are fixable problems. The overall error and fraud rate for 2023-24 was 7.8%, but for SMEs specifically it hit 14.6%. And 46% of first-time submissions were found to be entirely non-compliant.

These are the mistakes that catch software companies most often.

The procedural traps that kill claims before anyone reads them

The most frustrating rejections have nothing to do with whether your R&D qualifies. They are purely procedural, and they are permanent.

The Claim Notification Form (CNF) deadline. Since April 2023, first-time or lapsed claimants who have not claimed in the previous three accounting periods must submit a CNF within six months of the end of the relevant accounting period. Miss this deadline and you cannot claim. There is no appeal, no extension, no workaround. HMRC has been clear that this is a hard bar.

If your company's accounting period ended 31 March 2026 and you have never claimed before, your CNF must be submitted by 30 September 2026. Put it in the calendar now. Not in a Notion doc. In an actual calendar with a reminder four weeks before.

The AIF sequencing problem. The Additional Information Form (AIF) became mandatory in August 2023. It must be submitted before the CT600 (your corporation tax return). Submit the CT600 first and your claim is automatically invalid. This catches more companies than you would expect, particularly those whose accountants file the CT600 on a routine schedule without checking whether the AIF has gone in yet.

The fix is simple: make your accountant confirm the AIF is submitted before they touch the CT600. But "simple" and "actually happens" are different things when your accounting firm is handling dozens of clients on the same filing deadline.

Vague AIF project descriptions. Even when the AIF is filed on time, a generic description is one of the strongest signals HMRC uses to select claims for enquiry. "We developed a new platform using React and Node.js" tells them nothing. They want to see what scientific or technological uncertainty you faced, what a competent professional in the field could not readily deduce, and what you tried that did not work.

Three procedural errors. None of them are about whether your work qualifies. All of them can permanently bar or delay your claim.

Where HMRC draws the "routine development" line

This is where software companies get into the most trouble.

HMRC's definition of R&D requires an advance in science or technology. Building a product is not enough. Using new-to-you technology is not enough. The test is whether a competent professional in the field would regard the problem as having a solution that was not readily deducible.

For software, that line is blurry. But HMRC has been drawing it more sharply since the merged RDEC scheme launched in April 2024, and their compliance staff, now 500+ people, are getting better at spotting weak claims.

What typically does not qualify:

• Integrating third-party APIs, even complex ones
• Building a CRUD application, regardless of scale
• Migrating between frameworks or cloud providers
• Implementing well-documented algorithms in a new context
• Front-end development and UX work (almost never qualifies)

What can qualify:

• Novel data processing approaches where existing methods failed at your specific scale or constraints
• Custom ML model architectures where off-the-shelf models could not meet quantifiable performance requirements
• Systems requiring real-time processing under constraints where no known solution existed
• Distributed systems solving consistency or fault-tolerance problems not addressed in the literature

The distinction HMRC cares about is between system uncertainty and technological uncertainty. System uncertainty is "will these components work together?" Technological uncertainty is "can this be done at all with current knowledge?" Only the latter counts. Wiring up microservices is system uncertainty. Solving a problem where you genuinely did not know if a technical approach would work, and neither did anyone else in the field, is technological uncertainty.

The AI and LLM trap

This is the freshest wound. If your company builds on top of large language models, HMRC's default position is sceptical.

In a case documented by Williamson & Croft, an AI company had their entire claim rejected on the basis that they were using "publicly available technology." They eventually got it upheld, but only because they had detailed technical documentation showing the specific architectural challenges they solved beyond prompt engineering and fine-tuning.

If your R&D claim boils down to "we used GPT-4 in a novel way," expect scrutiny. The qualifying work, if it exists, sits in the infrastructure around the model: custom retrieval systems, novel evaluation frameworks, latency optimisation under constraints no one has published solutions for. The model API call itself is not R&D.

The overseas developer blind spot

Since April 2024, qualifying R&D expenditure for work done by overseas contractors and externally provided workers is severely restricted under the merged scheme. The work must be done in the UK unless there are qualifying conditions that make UK-based work impractical for reasons specific to the research itself: regulatory, geographical, or environmental. Cost savings do not count.

If your development team is partly offshore, which is common for UK software companies, any staff costs or subcontractor payments for overseas work are almost certainly excluded. This catches companies that claimed perfectly legitimately under the old rules and assumed nothing changed.

Review your claim line by line. If 40% of your qualifying expenditure was overseas developer costs last year, that 40% is gone under the merged scheme unless you can demonstrate one of the narrow exceptions. This is not a grey area. HMRC has been explicit about it.

Time apportionment and the director salary trap

HMRC expects honest time apportionment for everyone included in a claim. "Honest" means defensible, not optimistic.

The 100% problem. Claiming that any employee spends 100% of their time on qualifying R&D activities is a red flag. Even dedicated researchers attend meetings, do admin, handle support queries, and work on non-qualifying tasks. A claim where multiple staff are listed at 90-100% R&D time will almost certainly trigger an enquiry.

Reasonable time apportionment for a software engineer actively working on qualifying projects is typically 50-70%. For a CTO or technical director, 20-40% is more realistic once you account for management, hiring, investor relations, and everything else that fills a founder's week.

The director salary and dividends issue. Many owner-directors of small companies pay themselves a minimal PAYE salary, often at the NI threshold around £12,570, and take the rest as dividends. Only the PAYE salary element counts as qualifying R&D expenditure. If your director's PAYE salary is £12,570 and you claim 60% R&D time, the qualifying expenditure is £7,542 per director. Not the £80,000 they actually took home through dividends.

The PAYE cap further limits claims to the total PAYE and NIC paid by the company. If you run a lean company with low PAYE salaries, your R&D credit will be correspondingly small. This is not a loophole you can work around. It is a structural feature of the scheme.

The evidence you already have (and the reason HMRC never sees it)

Here is the irony of most software R&D claims: the best contemporaneous evidence already exists in your development tools. HMRC wants evidence created at the time the work was done, not retrospective write-ups produced when the accountant asks for them six months later.

Your git commit history is a timestamped, tamper-resistant record of what was built, when, and by whom. Pull requests with technical discussions show the uncertainty and iteration that HMRC looks for. Jira or Linear tickets with descriptions of technical problems, spike investigations, and failed approaches are exactly the kind of contemporaneous evidence that survives a compliance check.

The problem is that nobody packages this evidence properly. Your accountant does not know what a pull request is. Your R&D adviser glances at a spreadsheet of project names and writes generic descriptions. The actual evidence, the commit messages saying "third attempt at distributed cache invalidation, previous approach failed under load testing at 10k concurrent connections," never makes it into the claim.

One climate tech startup had a clawback that halted new claims and forced them into alternative dispute resolution. The technical work was genuinely qualifying. But their claim documentation was so thin that HMRC could not distinguish it from routine development. The evidence existed in their GitHub repositories. Nobody thought to include it.

Choosing the right approach

You have three realistic options for preparing an R&D claim.

DIY with your accountant. Works if your accountant genuinely understands software R&D (most do not) and if you have the time to write detailed technical narratives yourself. The risk is that you either under-claim because you do not know what qualifies, or over-claim because nobody pushes back on your descriptions. Cost is your time plus whatever your accountant charges for the CT600 and AIF.

Specialist R&D consultancy. The traditional route. A good consultancy will interview your technical staff, write the narratives, and handle the AIF. The problem is variability. The sector attracted a wave of aggressive advisers working on percentage fees, often 25-30% of the claim value, who inflated claims to maximise their cut and left clients holding the bag when HMRC came knocking. September 2024 saw 11 arrests including raids on tax consultancies. August 2025 brought the first corporate charges under the Criminal Finances Act, against the accountancy firm Bennett Verby.

If your adviser is pushing you to claim more than you are comfortable with, that is not ambition. That is risk transfer.

A good adviser charges fixed fees, tells you when something does not qualify, and makes your claim smaller rather than larger when the evidence is thin. They are worth the money. They are also hard to find.

Automated tooling that connects to your engineering data. Instead of retrospective interviews and generic write-ups, tools that pull directly from your repositories and project management systems can identify potential qualifying activities based on the actual technical work, produce draft reports with real evidence attached, and flag areas that need human judgement. The advantage is speed and evidence quality. The limitation is that no tool can make the final judgement on whether something constitutes an advance in the field. That still requires a qualified professional reviewing the output.

How CodeClaim fits

CodeClaim connects to your GitHub repositories, analyses commit history and code changes, and produces a draft R&D report structured around HMRC's requirements. It flags potential qualifying activities based on the technical work in your codebase and provides the contemporaneous evidence trail that most claims lack.

The output is a draft report for your accountant or adviser to review. The tool handles the extraction and structuring of technical evidence. A qualified professional makes the final call on what qualifies.