Knowledge & Insights
Merged scheme & compliance: building a clear, consistent claim under the new regime
Many businesses are now reaching their first claim under the merged scheme. The underlying principles of UK R&D tax relief haven’t changed, you still need genuine technological advance, uncertainty and a systematic programme of work, but the compliance expectations around disclosure, consistency, and traceability have stepped up.
This piece covers what “good” looks like under the merged scheme, where claims often lose clarity, and a practical way to make your submission easy to follow across the Additional Information Form (AIF), R&D report, accounts and tax computation.
1) What’s changed in practice under the merged scheme
The merged scheme hasn’t introduced “new science” requirements, but it has pushed the market towards a more compliance-led submission style. In simple terms, HMRC expects the claim to be: consistent across documents, traceable back to schedules and records, and clear enough that someone unfamiliar with the business can follow the narrative.
What this means for you
Your submission should read like a single package: AIF summary → report explanation → schedule build-up → computation reconciliation.
2) Think “claim pack”, not “claim documents”
Most avoidable issues arise when each component is prepared in isolation. Under the merged scheme, you want a single “source of truth” that flows into every document.
AIF
Project list + totals by cost category that match your master schedule.
R&D report
The narrative: uncertainty, advance, iterations, and rationale for cost approach.
Accounts & computation
Where the numbers land: reconciliations and the credit presentation pathway.
If one element changes late (e.g., project list, category totals), you should assume all other elements must be checked for alignment.
3) Lead with the R&D story (then cost it)
A common mistake is trying to reconstruct a claim from timesheets, invoices, or cost reports. Under the merged scheme, your claim should start with a clean technical narrative: what problem you were solving, what uncertainty existed, what advance was sought, and what systematic work was done to resolve it. Costs should then be mapped to that activity.
A practical order of operations
- Define the projects: stable names and clear boundaries.
- Write the narrative first: uncertainties, hypotheses, iterations, outcomes.
- Map roles to activity: who contributed to the qualifying work and how.
- Apply a methodology: apportionments and assumptions that fit your operating model.
- Build one master schedule: every qualifying line mapped to an AIF category and project.
4) AIF: how to keep disclosures clean and consistent
The AIF is effectively the structured index of your claim pack. It should match the report project list and the schedule totals exactly. You don’t need to over-explain in the AIF, you need it to be specific enough to trace and consistent enough to reconcile.
Common alignment checks
- Project list: names and count match the report headings.
- Category totals: match the master schedule totals (and the computation inputs).
- Externally provided work: disclosures align with the report description and the cost schedules.
Tip
Prepare a one-page “AIF alignment matrix” that maps each AIF line to: report section → schedule tab → computation line item.
5) Presenting the credit: accounts vs computation
Under the merged RDEC model, the credit is generally treated as a taxable receipt. The key compliance point is that the presentation should be obvious and traceable for anyone reviewing the pack.
What “good” looks like
- Clear location: the gross credit is clearly identifiable in the accounts and/or the computation.
- Reconciliation: schedules show how the gross credit is derived from qualifying expenditure.
- Consistency: the figure and label are used consistently across documents (no “gross” vs “net” confusion).
The goal is not a particular presentation style, it’s reducing ambiguity. Choose a method and apply it consistently.
6) Red flags that tend to trigger questions
These don’t automatically mean a claim is incorrect, but they commonly lead to additional queries if the pack is not clear.
- Mismatched totals: AIF totals don’t tie to schedules or computation.
- Unstable project naming: project list changes significantly year-on-year without explanation.
- Generic narratives: report reads like a template rather than company-specific technical detail.
- Externally provided work ambiguity: lack of clarity on who did what and how it relates to qualifying activity.
- Weak methodology notes: apportionments applied without rationale or evidence basis.
7) Evidence that makes claims easier to process
Evidence doesn’t have to be heavy or burdensome. It should be credible, contemporaneous, and traceable. In practice, you want evidence that supports the narrative and the methodology rather than trying to “prove” every hour.
Technical artefacts
Design notes, architecture diagrams, test results, iteration records, defect logs.
Delivery trail
Backlog history, sprint goals, change notes, decision records, experiment outcomes.
Methodology support
Role descriptions, allocation logic, and rationale for apportionments or assumptions.
8) A simple workflow for compliance-led delivery
If you want this to be repeatable each year, build a lightweight process that gathers the right inputs throughout the year, not just at year-end. The key is a stable project list, consistent allocations, and evidence capture that mirrors how the team works.
Want us to sense-check your first merged-scheme claim?
We’ll review your draft claim pack for alignment, clarity, and defensible methodology, and provide a clear punch-list of improvements.
Request a call back