Token metering and observability
The data engineers already emit
A metering layer, whether a gateway, a proxy or provider usage records, already captures the fields finance needs. For each request it records when the call was made, which model and endpoint served it, how many input and output tokens were consumed, and what the request cost at the applicable price. This is operational telemetry, but it is also, unusually, a transaction-level cost record. Most cost categories reach finance as an invoice; token spend can reach it as a metered ledger.
The fields that matter for the ledger
- Timestamp, so spend can be assigned to a reporting period and to a phase of the build.
- Model and endpoint, so run-phase inference can be distinguished from build-phase fine-tuning or evaluation.
- Input and output token counts and priced cost, so the amount is measured rather than estimated.
- A build or project identifier, without which the row cannot be attributed to a recognised asset.
Metering feeds the measurement test
IAS 38 will only allow development expenditure to be capitalised where the entity can measure it reliably IAS 38 §54-62. Most internally generated intangibles struggle here because staff time and shared infrastructure must be allocated. Token spend is different: metering produces a priced figure per request, so the capitalised amount can be built bottom up from tagged rows. That is the measure phase's central advantage, and the rest of the phase is about preserving it.
Retention as audit evidence
Telemetry is often kept for weeks; audit evidence must survive for the life of the asset and the audit period. Metered records that support a capitalised amount should be retained accordingly, because if the detail is purged the amount reverts to an assertion. Retention is what turns metering from an engineering convenience into the token ledger the auditor can test.