Time tracking for R&D staff

Staff costs are the largest line in most R&D claims, and the share of each person's time spent on the qualifying work is the one figure in the claim that no ledger holds. Payroll shows what people were paid. Nothing in the accounts shows how much of the year an engineer spent resolving a technical uncertainty rather than fixing production faults. That share is an estimate unless it was recorded as the work happened, and reviewers know it.

The principle is simple to state and hard to keep: choose the method before the year starts, record time against named projects as the work happens, apply the method to everyone in the same way, and reconcile the result to payroll before filing. Time records built after the year are a reconstruction, and a reviewer will treat them as one.

What this guide covers

• Why the time apportionment is the number reviewers challenge first, and how it fails.
• The methods available, from daily timesheets to monthly confirmation, and what each can support.
• Project codes, and how they connect the technical record to the cost schedule.
• Capturing time for managers, testers, operators and others outside the core team.
• What a reviewer tests when the apportionment is questioned.

Why time is the most challenged number

Every scheme covered here apportions staff costs by the share of the person's time spent on the qualifying work, and every scheme expects that share to be supported by records. The apportionment therefore carries the most money on the thinnest evidence, which is exactly where a reviewer goes first. Four patterns draw attention.

• Round numbers. A team allocated at 50 percent, or a department at 75 percent, tells the reviewer that nobody counted.
• Whole departments. One percentage applied to everyone with "engineer" in their title ignores the people who spent the year on maintenance, support or production.
• People missing from the technical record. If a person is in the cost schedule at 60 percent but never appears in a ticket, a test log, a commit or a meeting record, the reviewer will ask what they did.
• Time outside the R&D boundary. The qualifying work starts when the uncertainty is identified and ends when it is resolved or abandoned. Time on the same product before or after that window is not qualifying, and a code that runs for the whole commercial project cannot separate it.

In each case the figure was produced for the claim rather than captured during the work, which is the distinction the guide to what reviewers look for turns on.

Methods from timesheets to monthly confirmation

No scheme prescribes a single method. Several name timesheets in their guidance; all accept a reasonable method that is applied consistently and supported by records. The best method is the one the team will keep up for twelve months.

Timesheets with project codes

Each person records hours against project codes daily or weekly. This is the strongest evidence because it is granular, dated and attributed. It fails when treated as a chore: sheets completed in batches at month end, or every day booked to one code, are weaker than they look.

Sprint or ticket allocation

Software and product teams already assign people to tickets and tickets to epics or sprints. If each epic is tagged as R&D or not when it is opened, the ticketing system becomes the time record. Ticket counts or story points need converting to hours on a stated basis, and the tag must be set by someone who understands the definition.

Monthly confirmation

Where timesheets are not realistic, each technical lead confirms in writing, every month, the share of each team member's time spent on each open R&D project, with a sentence on what they did. Twelve dated confirmations from the person who managed the work are records made at the time. One confirmation at year end is not.

Project codes and the cost schedule

Whatever the method, it depends on project codes that engineering, finance and the claim all share. Three rules make codes useful under review.

1. Open the code when the uncertainty is identified, in the same document that records what is not known, so that the start note, the code and the first time entry carry the same date.
2. Separate the R&D phase from the rest of the project. Give the R&D phase its own code or sub-code, and close it when the technical lead records that the uncertainty was resolved.
3. Use the same names everywhere. The code, the technical narrative, the cost schedule and any registration or form should carry one project name. A reviewer who meets three names for one project will ask whether there are three projects or one.

The staff time apportionment module works through how the codes feed the calculation and the reconciliation to payroll.

Capturing time for people outside the core team

The disputed time rarely belongs to the research engineers. It belongs to people whose jobs are mostly something else: the manager who planned the experiments, the quality technician who ran the tests, the operators who ran a trial batch. Each scheme has its own wording for which of these activities count; the country rows below link to it. The common principles are these.

• Record the activity, not just the person. "Supervised trial 14 and reviewed results" supports a claim; "management, 20 percent" does not.
• Claim the hours, not the role. A manager who spent four days in the quarter on the project has four days of time to consider, whatever the title.
• Keep general management out. Budgets, hiring, strategy and customer relationships are not work on the technical uncertainty, whoever does them.
• Treat trial production separately. Operators' time during an experimental run may be qualifying where the run was the experiment; routine production is not. The trial log is the record that separates them.
• Let the technical lead confirm. Time for people outside the team should be confirmed by the person who directed the R&D, not self-reported.

What reviewers test

When a reviewer questions the apportionment, the questions follow a predictable order. Prepare the answers before filing.

1. When was the allocation made? The reviewer asks for the records behind the percentages and looks at their dates. Records created during claim preparation are discounted.
2. What was the basis? Hours, tickets, confirmations or estimates, and who produced them.
3. Was it applied consistently? The same method for everyone in the year, and year to year unless a change is documented.
4. Does it reconcile? Hours against contracted hours, apportioned cost against payroll, the sum against the cost schedule.
5. Do the people appear in the technical record? Names in the cost schedule are cross-checked against tickets, logs, commits and meeting notes.
6. Does the technical lead agree? In an interview the reviewer asks who was on the work and for how long, and the answer should match the schedule.

Illustrative example

Illustrative example. Corran Castings Ltd, a hypothetical company, has ten technical staff each paid 60,000, a payroll of 600,000. Its first draft claim applied 50 percent to the whole team, giving staff costs of 300,000. Before filing, the finance lead went back to the trial logs and the foundry manager's monthly confirmations. Three metallurgists had spent about 90 percent of the year on the two projects with open uncertainties (162,000). Three process engineers had spent about 40 percent, the rest on commissioning a purchased machine (72,000). Two technicians had attended trials for about 15 percent of their time (18,000). Two draughtsmen had done no work on either project. The supportable staff cost was 252,000, and the benefit at that country's rate was lower than the first draft. Every figure, however, traced to a dated record and a named person.

Country differences

Related pages

• Contemporaneous documentation: what reviewers actually look for
• Writing a technical narrative that survives review
• In-House Finance Team Program, module 3: staff time apportionment
• Technical Teams Program, module 3: recording as you go
• Documentation and compliance hub

Educational material, not advice. Which activities count toward staff time, and the records required, depend on the scheme and the facts.