Evidence Before Entitlement: The R&D Claim File UK SMEs Should Build in 2026
R&D tax relief remains one of the more valuable reliefs available to UK SMEs, but it is not a reward for innovation in the abstract. It is a statutory relief that must be evidenced, apportioned and described in a way that HMRC can test. As 2026 draws to a close, the practical risk for owner-managers is not simply whether the calculation is right. It is whether the claim file can support the calculation when questions arrive.
A recurring reason claims falter is that the business treats the tax return as the starting point. The stronger approach is to treat the claim as an auditable file that happens to end in a CT600 entry. Whether you claim under the merged scheme or the enhanced support route for loss-making R&D-intensive SMEs, the same discipline applies: the evidence should exist before the claim is submitted, not after HMRC asks for it.
The claim is not the calculation
Advisers can usually make the numbers add up. The harder question is whether the numbers can be tied to projects, people and technical uncertainty. HMRC compliance teams are not simply checking arithmetic. They are checking whether the company can show what was uncertain, what was attempted, who did the work and why the cost belongs to the claim.
That distinction matters for SMEs because the people closest to the technical work are often not the people preparing the tax return. By the time an accountant or adviser asks for supporting material, memories have faded and project records have been scattered across email, chat, code repositories and personal notebooks. A file assembled retrospectively is not automatically invalid, but it is far easier to challenge.
The three records that should exist before you file
There are three records that should be in place before a claim is submitted. They do not need to be elaborate, but they do need to be consistent and contemporaneous enough to withstand scrutiny.
1. A project record that shows the uncertainty
The first record is a project-level log. It should identify the technical or scientific uncertainty, the baseline position, the alternatives considered and the work actually carried out. Dates matter. So do the names of the people involved and the outcomes, including failed tests and abandoned lines of enquiry.
A useful test is whether the record would make sense to a technical reviewer who was not in the room. If it reads like a sales brochure, it is not a project record. If it describes a routine upgrade, a standard integration or a known solution applied in the usual way, it is unlikely to support an R&D claim. The record should show why the answer was not readily deducible to a competent professional at the outset.
2. A cost trail that links money to projects
The second record is the cost trail. Payroll, contractor invoices, consumables, cloud capacity, software licences and other qualifying costs should be capable of being traced to the projects claimed. Time records do not need to be perfect, but the method of apportionment should be documented and applied consistently.
This is where many SME claims become vulnerable. A director may know that a developer spent most of a year on a particular programme, but if the payroll records show only a job title and the contractor invoices show only a monthly retainer, the link is weaker than it needs to be. The same applies to costs that have been included by estimate without a clear basis. HMRC is entitled to ask why a cost is qualifying, why it is attributable to R&D and why the apportionment is fair.
3. A competent-professional record and decision trail
The third record is the competent-professional evidence. Someone with the relevant technical knowledge should be identifiable, and their involvement should be evidenced. That may be an internal engineer, a technical director or an external specialist, but the file should show who assessed the projects and why they considered the work to involve uncertainty.
A signed summary is useful, but it should not be the only evidence. It should sit alongside the project log and cost trail, not replace them. If the competent professional was not involved until the claim was being prepared, that should be addressed honestly. Retrospective sign-off is not fatal, but it is more persuasive when it is supported by records created at the time.
Project descriptions that invite questions
Some narratives almost invite a query. Descriptions that rely on phrases such as ‘improving an existing product’, ‘developing a new website’ or ‘using AI to streamline operations’ rarely do enough on their own. They describe activity, not uncertainty. They do not explain what could not be readily worked out by a competent professional.
Routine software development is a common pressure point. Building a feature, integrating an established API or migrating to a new platform may be commercially important, but it is not automatically R&D. The claim needs to identify the technical advance sought and the uncertainties that stood in the way. If the project succeeded first time using known methods, the file should say so plainly rather than dress it up as experimental.
Copy-and-paste narratives are another warning sign. If three projects are described in almost identical language, the reviewer will reasonably ask whether the company has actually distinguished them. Cost figures that seem disproportionate to the technical narrative can also trigger questions. So can a sudden increase in claimed staff time without a corresponding change in project records.
A pre-submission audit any SME can run
Before filing, run a red-team review of the claim file. Ask a colleague who was not involved in preparing the claim to test it against a simple question: could a sceptical reviewer follow the story from uncertainty to work done to cost claimed?
Start with the project descriptions. Remove marketing language and check that each description explains the baseline, the limitation and the advance sought. Confirm that the projects are not routine work that happens to be technically demanding. Check that connected projects are not double-counted.
Next, test the cost trail. Pick a sample of employees and contractors and trace their time and invoices back to project records. Confirm that the apportionment method is documented and that excluded costs have genuinely been excluded. Check that overseas expenditure, if any, has been treated correctly and that grant-funded work or subcontracted work has been considered.
Finally, check the administrative position. Confirm the accounting period, the claim notification deadline if this is a first claim or a new claimant, and the company’s eligibility for the route used. Make sure the figures in the claim agree with the statutory accounts and the payroll records. If there are inconsistencies, resolve them before submission rather than explaining them later.
The file is the claim
R&D tax relief rewards uncertainty, but the claim file must remove uncertainty for HMRC. The businesses that fare best are not necessarily the most innovative. They are the ones that can show, with dated records and a coherent narrative, why the work qualified and how the costs were calculated.
For UK SMEs, the practical message for 2026 is straightforward. Build the evidence file before the claim is filed. If the file is thin, fix the process before the deadline, not after the enquiry letter lands.
