Scenario: R&D capitalisation end to end
From connected integrations to a classified, locked monthly capitalisation ledger with control checks and audit evidence.
Updated 18 July 2026
This guide takes you from synced engineering data to a monthly ledger your finance team can book against: effort classified into capitalisable and expensed work, checked, closed and locked with the evidence preserved. It's the workflow behind the R&D ledger.
Get attribution right first. The ledger is only as good as its inputs: integrations connected (getting started), identities linked, and every active person carrying an hourly rate. Effort without a person or rate shows up as hours with no cost. The readiness check below will catch it, but it's cheaper to fix now.
Write classification rules for capitalisable work. Defaults classify by issue type; real projects deserve real rules: label-based ("
cap-project-x"), component-based, or keyed to how your team marks development work. Classification rules covers the engine. The aim is that the capitalisable/expensed split rests on rules someone can explain, not on fallbacks.Drive the grey zone down. The Confidence Report scores every effort entry by how it was classified: manual and rule-based high, fallback low. The low-confidence "grey zone" is unexplained money: review those tickets, extend rules or override manually until the remainder is small enough to defend.
Close evidence gaps. The Data Quality report cross-checks logged time against code activity: worklogs with no commits behind them, commits with no logged time. Each gap is a question an auditor could ask; period-close readiness counts them.
Watch the readiness score. The Period Close report scores each month against a weighted checklist: ledger data present, no low-confidence classification, review queues clear, evidence gaps closed, rates in place, syncs fresh, period locked. Work the list until the score clears the bar. It's the pre-flight check, not a formality.
Close and lock the period. Closing takes a snapshot of the month's numbers and locks it. A locked month blocks reclassification of its work. The numbers you booked stay the numbers on record. Unlocking requires a stated reason, and every lock and unlock is written to an immutable audit trail.
Export the evidence. The audit bundle is a single archive: the period-close workbook and board pack, the ledger export, the confidence report, both evidence-gap listings, the lock history and a manifest with checksums for every file. Hand it over as-is when the auditor asks.
Month to month
After the first close, the loop is small: keep classification rules current as projects start and end, clear the review queue, watch readiness through the month rather than discovering problems at close, and close within a few days of month end. The monthly Ledger Report shows the running capitalised/expensed series that each close locks in.
Reading the two ledger views
The R&D ledger page has two tabs that answer the same question — how much of the work is capitalisable — in two different units. Reading a figure off the wrong one is the easy mistake:
| Tab | Unit | Cap rate |
|---|---|---|
| R&D Capitalisation Summary | Cost (dollars) | Capitalised cost ÷ total cost |
| R&D Technical Audit | Effort (hours) | Capitalisable hours ÷ total hours |
The Summary tab is the money view: each month's total cost split into CapEx (capitalised) and OpEx (expensed), with the cost-based cap rate overlaid and a reconciliation check — a month reads "Balanced" when CapEx plus OpEx equals the total, and flags a variance when it doesn't. The Technical Audit tab is the same split in hours, with the hours-based cap rate; it's what the capitalisation report opens to. The two cap rates can differ when high-rate people concentrate in one kind of work, which is exactly why both exist.
For the cost side of this — how labour and AI tooling combine and where CapEx and OpEx come from — see the cost report. For the month-end sign-off and locking, see reading the period close report.
What this process does and doesn't claim
The ledger records what your engineering data supports: who worked, how much, on what, classified by rules you control, with every change tracked. Where inputs are estimates (commit-session hours, modelled cost) the effort model says so plainly, and the confidence scoring keeps estimate-heavy months visible rather than blending them in. That transparency is the point: a number you can walk backwards beats a tidier number you can't.
EngLedger does not determine tax outcomes. Whether work qualifies for the R&D Tax Incentive, and how any claim is prepared, is a matter for your registered tax adviser; the ledger gives them a contemporaneous, defensible record to work from.