First merged-scheme claim: the 8 things to get right.

1) Start with scope, not costs

The biggest error is trying to “reverse-engineer” a claim from timesheets or expenditure reports. Under the merged scheme, a clean narrative around qualifying R&D activities must be at the forefront of the process, supplemented with a solid, suitable claim methodology specific to the claimant company, and the industry itself.

Get right: firmly establish what it is the competent professionals did, what uncertainties existed, and what was attempted to resolve them.

2) Clearly defined baseline and advancement

Weak claims often describe activity but don’t establish what was not readily deducible at the time.

Get right:

• Baseline state of knowledge/technology within the company/industry

• The advancement you were seeking (not simply “a new feature”)

• Why it required experimentation or iterative development

3) Evidence has to be enquiry-ready now, not “nice to have”

HMRC scrutiny is increasingly evidence-led. The aim isn’t perfect documentation; it’s credible, contemporaneous signals.

Get right:

• Architecture decisions and trade-off notes

• Experiment logs / test results / performance benchmarks

• Git history + tickets that show iteration, failure states, and resolution

4) Split “R&D” from “delivery” early (especially in software)

Many companies have mixed workstreams: some genuinely uncertain, others BAU.

Get right: a defensible method for separating:

• Experimental / problem-solving work (R&D)

• Implementation, configuration, rollout, and support (non-R&D)

5) Treat contractor/EPW eligibility as a first-class workstream

This is one of the most common “quiet failure” points, claims are often prepared correctly overall but become vulnerable due to weak contractor categorisation or insufficient contract clarity.

Get right:

• Who controlled the work and bore risk

• Whether individuals are EPWs and how they’re paid

• Whether the work is UK-based / overseas (and how that affects eligibility)

6) Present the credit consistently across accounts and tax comp

Even when a claim is technically correct, mismatches in where the credit appears can trigger processing friction (or at least a question).

Get right: consistent treatment of the gross credit (and its tax effect) across your computations and financials.

7) Don’t underestimate group/offset interactions

Group position, surrender of losses, and timing all influence the real cash impact.

Get right: model the expected benefit early so you’re not surprised late in the process by a restriction, offset, or treatment issue.

8) Make the Additional Information Form frictionless

The AIF is not just an admin task, it’s effectively the first filter.

Get right:

• Crisp project summaries aligned to the report

• Cost categories that tie back cleanly to the computation

• No unexplained anomalies in headcount/cost movements

A practical “first merged-scheme” readiness checklist

Before you finalise anything, you should be able to answer yes to the below:

• We can clearly describe the technical uncertainties and why they weren’t readily deducible

• Our narrative shows experimentation/iteration and how uncertainty was resolved

• We can show some contemporaneous evidence (tickets, commits, test results, design notes)

• We’ve separated R&D vs BAU and can explain the methodology

• Contractor/EPW treatment is documented and consistent with contracts/working practices

• Presentation in accounts and tax comp is consistent and easy to follow

• AIF aligns to the report and the numbers reconcile cleanly