How to allocate staff time in an R&D tax claim

Why staff time allocation matters

Under the merged R&D tax relief scheme (and ERIS where relevant), you can only claim the portion of staffing costs that relates to qualifying R&D activity. HMRC is not looking for perfection, but they do expect your approach to be:

• Reasonable and based on how work was actually done
• Consistent across the business and across periods
• Supported by records that make your numbers credible

If your staff time is unclear, everything downstream gets harder. Cost schedules stop reconciling, project narratives feel generic and enquiries get more likely.

Who can be included in staff costs

You can include employees and directors who spend time on qualifying R&D activity, including people who do R&D part time.

Roles commonly included

• Engineers, developers, scientists, technicians
• Product and test engineers
• R&D team leads and technical project managers (where the work directly supports R&D)
• Directors who actively contribute to the technical direction or resolution of uncertainties

Roles that are often overstated

These roles are not automatically excluded, but the bar is higher and you need to show a direct link to qualifying R&D:

• General operations management
• Sales, marketing, customer success
• Finance, HR, admin
• General IT support

What staff activities qualify

The simplest way to think about staff time is to split it into qualifying and non-qualifying activity.

Qualifying direct R&D activity

Time spent directly on resolving scientific or technological uncertainty, such as:

• Designing and running experiments or trials
• Building, modifying, and testing prototypes
• Developing new or appreciably improved processes, products, or software where there is genuine technical uncertainty
• Modelling, simulation, performance testing, failure analysis
• Solving technical problems where the solution is not readily deducible by a competent professional

Qualifying indirect activity

Indirect activity can qualify if it directly supports qualifying R&D work. Examples include:

• Technical project management directly tied to R&D tasks
• Planning and coordinating tests or prototypes
• Maintaining and calibrating equipment used specifically for R&D trials
• R&D-specific QA and test setup related to resolving uncertainty

Non-qualifying time

Just as important as capturing the right R&D time is being clear about what should stay out of the claim. HMRC will often test whether everyday delivery and overhead time has been incorrectly included, especially where roles span both R&D and business-as-usual work. Being disciplined here strengthens credibility and reduces the risk of challenge.

Common exclusions include:

• Routine production and standard operational work
• Pure business-as-usual bug fixes and maintenance
• General admin, HR, payroll tasks
• Commercial activity like marketing, customer demos, pricing, business planning
• Routine quality control that is not linked to resolving uncertainty

Step-by-step: how to allocate time fairly

This is a practical, repeatable approach you can run each claim period to produce time apportionments that are consistent, easy to explain and straightforward to evidence. It’s designed to work whether you have detailed timesheets or not, as long as you can show who worked on what, when they did it and why that work relates to qualifying R&D.

Step 1: Define your R&D project scope

Start with a clear project list for the period and confirm:

• The scientific or technological uncertainties being addressed
• The R&D activities carried out to resolve them
• The start and end dates for when the work was active

If your project scope is vague, time allocations will look vague too.

Step 2: Identify who contributed and how

For each project, list the people involved and the type of contribution:

• Direct technical work
• Supporting technical work
• Non-qualifying work

Do not include someone just because they attended a meeting. Tie their contribution to R&D activity.

Step 3: Choose an allocation method that fits how you work

HMRC does not require one specific way to measure time. Use the approach that best reflects how your team actually works and that you can repeat each year. The aim is simple: you should be able to show how you arrived at each percentage, using records you already have where possible.

Method A: Timesheets or time tracking

Best where teams already log time by project or ticket:

• Allocate hours to R&D tasks
• Keep the definition of “R&D task” consistent
• Avoid tagging everything as R&D

Method B: Work breakdown structure and role based apportionment

Useful when teams do not track time but work is structured:

• Map deliverables and milestones to R&D tasks
• Apportion by role involvement in those tasks
• Support with sprint plans, project plans and test schedules

Method C: Sampling and extrapolation

Useful for busy teams with repeating cycles:

• Sample representative weeks or sprints
• Calculate R&D percentage for each person
• Apply the percentage across the period, adjusting for known changes (project start, pause, role change)

Method D: Ticket based allocation (software teams)

Often the most defensible for software claims:

• Tag tickets as R&D or non-R&D
• Use story points or hours consistently
• Keep notes on why a ticket is R&D, focusing on uncertainty and advance, not features

Step 4: Calculate each person’s R&D percentage

Keep it simple:

1. Total working time in the period (after leave if you are adjusting for it)
2. R&D qualifying time in the period
3. R&D percentage = qualifying time ÷ total time

Then apply that percentage to qualifying staff cost categories for that person.

Step 5: Apply the percentage to the right cost base

Staff costs typically include:

• Gross salary
• Employer NIC
• Employer pension contributions
• Certain bonuses where they relate to R&D activity and are paid through payroll

Avoid applying an R&D percentage to costs that do not exist in payroll, or to contractor invoices that should sit under different cost categories.

Handling common edge cases

People split across multiple projects

Do not force one percentage for the entire year if reality changed. If someone moved from R&D to delivery, split the period and apply different percentages.

Directors

Director time can be included when it is genuinely technical and tied to uncertainty resolution. Board level strategy and investor activity are not qualifying.

Meetings

Meetings can qualify when they are directly about resolving technical uncertainty, planning tests, reviewing results, or making technical decisions. General project updates and commercial meetings do not.

Leave, sickness and training

Be consistent. Either include them in total time and accept a slightly lower R&D percentage, or adjust total time for long periods of leave if your method supports it. What matters is that your approach is applied consistently and is easy to explain.

What evidence should you keep

You do not need a perfect evidence pack, but you do need enough to show your percentages are not guesswork.

Good supporting records include:

• Timesheets, time logs, or ticket reports
• Sprint plans, backlogs, and release notes
• Test plans, trial reports, lab notes, simulation outputs
• Design reviews, technical meeting notes, decision logs
• Project plans and milestones that show when R&D work was active
• Role descriptions and org charts that explain who did what

A simple “time allocation file” is often enough

For each person, clarify:

• Role
• Projects worked on
• Method used
• R&D percentage for the period
• One or two supporting references (ticket report link, sprint export, test plan)

Common mistakes that lead to challenge

These are the issues HMRC tends to question because they can indicate the time split is estimated too broadly or the claim hasn’t been tied back to real project activity and costs. A quick check against the points below can prevent avoidable follow-up questions and rework later:

• Using a single blanket percentage for everyone
• Including large amounts of general management time
• Claiming routine production, QA, or maintenance as R&D
• Failing to explain why a person’s role relates to uncertainty resolution
• Percentages that do not match project timelines (for example, claiming R&D time before the project started)
• Totals that do not reconcile back to payroll and the ledger

Example allocation in practice

A developer worked across two streams in a 12-month period:

• 60 percent on experimental work resolving performance uncertainty in a new algorithm
• 40 percent on feature delivery and routine bug fixes

You would claim 60 percent of their qualifying staff costs for the period, supported by ticket tags, sprint exports and test results linked to that algorithm work.

Key takeaway

Aim for a method that is honest, repeatable and easy for someone outside the business to follow. If you can show how the R&D work happened and how you translated that into percentages, your claim is in good shape.