Module 2: Cost capture

A claim is only as good as the costs behind it. After this module you will be able to map your ledger to the cost categories the seven schemes recognise, set up project codes so that eligible costs are pulled from the system rather than reconstructed after the year, and run a capture routine whose effort matches the size of the claim.

What this module covers

• The cost categories that recur across the seven schemes, and where each scheme draws its own line.
• Mapping the chart of accounts to those categories.
• Project codes as the join between the technical record and the ledger.
• A capture routine that runs during the year, with a year end reconciliation.
• Keeping the effort proportionate to the value and risk of each category.

The cost categories

Every scheme starts from the same idea: the cost of the people who did the work to resolve the uncertainty, the people engaged to do part of it, and the materials and services consumed in doing it. The differences are at the edges, which is where reviews concentrate.

Capture every category at full value and apply the scheme's percentage, cap or exclusion as a separate step.

Mapping the chart of accounts

The mapping is a one page document listing every expense account and how it relates to the claim, prepared once, reviewed each year and kept with the claim file. For each account record:

1. Scope. Always in scope (direct engineering payroll), in scope when apportioned (power, cloud, shared technical staff), or never in scope (marketing, entertaining, interest).
2. Capture basis. Direct coding, where every transaction carries a project code, or apportionment, where a share of the account is allocated by a stated method. Prefer direct coding wherever a cost can be coded at source.
3. Evidence. What supports amounts drawn from the account: timesheets, contracts and invoices, stock issue records, licence agreements, the apportionment working.

Errors the mapping prevents: capturing by vendor name rather than by account and project; assuming capitalised development costs are outside the claim; omitting employer contributions the scheme includes; and counting agency workers twice.

Project codes

The technical narrative describes projects and the uncertainty each set out to resolve. The ledger records transactions. Project codes join the two. Set codes at the level the scheme tests, the project or the activity, not the department. Open a code when the uncertainty is identified and close it when it is resolved or the work stops, so the time boundary of the eligible work is built into the ledger rather than argued later. Give routine work on the same product its own code, so that it is visibly excluded.

Codes must appear wherever cost arises: timesheets, purchase orders, expense claims, stock issues and intercompany charges. Where the system cannot carry a project dimension, keep a mapping table from cost centres to projects. One catch-all R&D code is the most common weakness in an in-house claim: it mixes eligible and routine work, hides timing, and forces a reconstruction at year end.

The capture routine

Capture during the year is cheaper and stronger than capture after it: the people who can explain a transaction are still available and the records are made at the time. At each month end or quarter end:

• Extract costs by project code and category, and file the extract.
• Add new vendors and accounts opened in the period to the mapping.
• Confirm that time records for the period are complete and approved (module 3).
• Note any grant, subsidy or customer contribution against each project (module 5).
• For contractor invoices, check that a contract and the place of work are on file (module 4).

At year end: reconcile the total captured to the trial balance; run the shared cost apportionments once, using the stated method; prepare the cost schedule by project and category; and read it against the technical narrative so that every project with costs has a description and every described project has costs. Good looks like a schedule that reconciles to the accounts in one step, where every line names its source and evidence.

Keeping the effort proportionate

Effort should follow value and risk. Staff costs are usually the largest category and carry most of the review risk, so they justify timesheets or a structured allocation (module 3). Contractor costs justify a contract review per vendor. Consumables are best coded at source. Shared costs justify one documented apportionment a year, where the scheme allows them. Small amounts can be left out if the decision is written down: a documented exclusion is a strength under review, an unexplained gap is not.

Illustrative example

Illustrative example. Harbour Robotics Ltd, a hypothetical company, has two projects its engineers have identified as resolving technical uncertainty. Its ledger shows engineering payroll of 600,000, contractor invoices of 100,000, materials of 80,000, cloud services of 30,000 and rent and administration of 200,000. Capture by project code gives: staff 300,000 (half of engineering time, from time records); contractors 100,000 at full value, with the scheme's percentage and location rules applied as a separate step; materials 50,000, after excluding 30,000 of components built into units that were sold; cloud 12,000, apportioned by compute hours logged to the project codes; and overheads 40,000 on a floor area and headcount apportionment, held on a separate line because some schemes exclude it. The base before scheme specific rules is between 462,000 and 502,000, and the benefit is calculated at that country's rate.

Across the seven countries

Each row gives the cost categories in the scheme's own wording; the linked page holds the definitions and exclusions in full.

Where to go next

• Module 1: Scheme mechanics: how the captured base turns into a benefit.
• Contemporaneous documentation: what reviewers actually look for: the records behind each cost line.
• R&D incentives by country: the seven schemes side by side.
• In-House Finance Team Program: the overview and module list.