How Bristol and Cambridge deep-tech firms document R&D tax credit claims

What to take away

Why Bristol and Cambridge deep-tech clusters attract HMRC scrutiny

Both cities host unusually dense concentrations of research-heavy companies. The Office for National Statistics tracks this concentration through its business activity, size and location data, which shows how many firms in each region sit in science, engineering and software sectors. High claim density invites attention.

Bristol's cluster spans aerospace around Filton, clean-tech and a growing software base. Cambridge's spans life sciences, software, semiconductors and instruments. HMRC sees repeated claim patterns from these postcodes and tests them harder than claims from sectors where R&D is rare.

A second factor is claim size. Deep-tech firms often claim six-figure sums because staff costs are high and projects run for years. Large claims are reviewed more closely, and the burden of proof sits with the claimant.

HMRC's compliance checks examine whether the work meets the statutory definition of R&D, whether costs are allowable, and whether the technical narrative matches the underlying records. The definition is set by CTA 2009 Part 13 and explained in the DSIT/HMRC Guidelines on the Meaning of R&D for Tax Purposes. HMRC's CIRD manual and Compliance Handbook set out how officers approach that assessment, including what they ask for and how they weigh evidence.

None of this means Bristol or Cambridge firms should claim less. It means the documentation standard is higher, and the firms that treat record-keeping as part of the project rather than an afterthought are the ones that get paid without a fight.

Project records HMRC expects from software, aerospace and life sciences claimants

HMRC does not prescribe a single record format. It expects records that show what was attempted, what was uncertain, how the uncertainty was resolved, and who did the work. The claim process guidance confirms that companies must be able to support the claim with evidence, and that the burden falls on the claimant.

Software claimants in Bristol and Cambridge should keep version control history, ticket trails, architecture decision records, sprint notes and deployment logs. A commit history that shows failed approaches and rewrites is strong evidence of uncertainty. A polished final repository is not.

Aerospace claimants should keep test logs, design review minutes, stress and fatigue calculations, materials certificates and iteration records. Around Filton, where supply chain work is common, the boundary between a customer-funded development and an internally funded R&D project matters, and the records must show which is which.

Life sciences claimants should keep protocol versions, lab notebooks, batch records, assay results, ethics submissions and clinical or regulatory correspondence. On the Cambridge Biomedical Campus, where many firms run both research and routine testing, the records must separate genuine R&D from standard service work.

A useful discipline is to run grant-funded and tax-credit-funded work through the same evidence pipeline: a single file for the project, the cost records and the technical evidence. The quality gates that apply to grants — eligibility, costs, milestones, evidence and sign-off — apply equally to an R&D tax credit claim, because both depend on records created while the work happens. For grant-funded work, the same quality checks between application and close-out can be used as a template.

For a worked example, consider a Bristol software firm building a machine learning pipeline for defect detection. The team tries three model architectures, two of which fail on the client's data. The failed experiments, the reasons they failed, and the engineering time spent on them are the R&D.

If the firm only keeps the final model and a summary slide, the claim is weak. If it keeps experiment logs, evaluation results and time records, the claim stands.

Staff time evidence: timesheets, contracts and apportionment

Staff costs usually dominate a deep-tech claim, so staff time evidence is where most disputes start. HMRC wants to see how much time each person spent on R&D, how that time was recorded, and why the apportionment is reasonable.

Contemporaneous timesheets are the strongest evidence. Weekly or monthly entries that name the project and the activity are far better than a year-end estimate. Where a firm uses project management software, exported time reports can serve the same purpose if they are complete and dated.

Contracts and job descriptions matter too. They show what a person was hired to do and whether their role plausibly involved R&D. A principal engineer's contract supports a technical claim. A sales director's usually does not, however many meetings they attended.

Apportionment is the hard part. Most deep-tech staff split their time between R&D, production support, client work and administration. A defensible method assigns a percentage based on recorded time, not on a round number chosen for convenience. If a developer spends two days a week on R&D, the records should show those two days, week by week.

A simple worked example: a Cambridge life sciences firm employs a scientist at a known annual cost. Her timesheets show 60 per cent of her time on R&D projects and 40 per cent on routine sample processing. The claim uses the R&D share, supported by the timesheets and the project records that show what she did.

That is a defensible position. A claim that uses 100 per cent because she is a scientist is not.

Firms that already run funded projects often have this discipline in place. A reporting dashboard that connects money, milestones and evidence gives finance and technical teams the same view, and that money, milestones and evidence maps closely onto what an R&D claim needs.

Writing the technical narrative that supports an R&D tax credit claim

The technical narrative is the document that explains the project to a non-specialist reader at HMRC. It must describe the scientific or technological uncertainty, the work done to resolve it, and why the outcome was not readily deducible by a competent professional.

Write it in plain English. Name the project, the period, the team and the technical baseline. Explain what was known at the start, what was uncertain, and what alternatives were considered. Then describe the work, the failures and the eventual advance.

Avoid marketing language. HMRC is not assessing whether the product is innovative in a commercial sense. It is assessing whether the company faced genuine technical uncertainty. A narrative that reads like a pitch deck undermines the claim.

Tie every assertion to a record. If the narrative says a modelling approach failed, the experiment log should show it. If it says a material did not meet a specification, the test report should show it. Cross-references make the narrative verifiable.

Software narratives should explain the algorithmic or architectural uncertainty, not the business problem. Aerospace narratives should explain the engineering uncertainty, not the customer requirement. Life sciences narratives should explain the biological or chemical uncertainty, not the clinical need.

Keep the narrative under review. A multi-year project will need an updated narrative for each accounting period, even if the underlying project continues. Reusing last year's text without checking it against this year's records is a common cause of failed claims.

Advance notification and the additional information form for these claimants

For accounting periods beginning on or after 1 April 2023, companies must notify HMRC of an intention to claim R&D tax relief before they submit the claim. The notification is made through HMRC's Claim Notification Service. The notification guidance explains the deadline and the information required. A company that has not claimed in the previous three years must notify within six months of the end of the period of account.

For accounting periods beginning on or after 1 April 2023, claims must also be accompanied by an additional information form. The form captures details of the project, the costs, the qualifying expenditure categories and the named senior officer who approves the claim. It must be submitted through HMRC's online service before the company files its CT600 company tax return. The claim itself is made in the CT600, and both the claim and the additional information form must be delivered within two years of the end of the accounting period to which they relate.

In practice, the form forces firms to assemble the narrative and the cost breakdown earlier than they might otherwise. Bristol and Cambridge firms with in-house finance teams can manage this. Smaller firms often need their adviser to prepare it, and the adviser will need the project records to do so.

A checklist for the notification and form stage:

If HMRC opens a compliance check, the compliance check guidance explains what to expect and how to respond. Firms should treat the first information request as the moment to produce the full evidence pack, not to negotiate scope.

Keeping records audit-ready across a multi-year project

Deep-tech projects often run for three to five years, and HMRC can open a compliance check well after the accounting period closes. Company tax law requires records to be kept for six years from the end of the accounting period under FA 1998 Sch 18, and a multi-year project can push that window beyond the point when the last claim is filed.

A practical approach is to treat each project as a funded programme with its own file. The operating discipline for a grant — award pack to close-out — works equally well for an R&D claim: a single place where the narrative, the cost records and the technical evidence live together.

Retention matters. Store records where they can be found without the person who created them. Staff leave, systems change, and a claim from three years ago should not depend on someone's memory or a laptop that has been wiped.

Review the file annually against the claim. If the narrative says one thing and the timesheets say another, fix the narrative or the claim, not the timesheets. Retrospective edits to time records are the fastest way to lose credibility in a check.

Finally, plan the paperwork at the same time as the project plan. A reusable planning record, covering everything from eligibility to claims, gives a deep-tech firm a single structure for grants and tax credits alike. The firms that do this in Bristol and Cambridge spend less time on claims and more on the work that generates them.

Common questions