This paper is written for chief financial officers, chief information officers, FinOps leaders and AI product owners. Read Parts I and II for the unit-economics argument, Part IV for the invoice-resolution example, and Part V for the deployable ledger and reconciliation query.

Glossary

• Attempt: one admitted workflow instance, whether it completes, escalates, fails or is abandoned.
• Accepted result: an output that passes its defined technical, business and policy checks and can proceed to action.
• Verified outcome: an accepted result whose intended external effect is confirmed in the authoritative business system.
• Route: the complete event sequence from task admission through context, reasoning, tools, review, action and readback.
• Exception path: a route that leaves straight-through processing and requires alternate logic or human work.
• Failure cost: consumed route cost plus containment, correction, customer remedy, incident response and attributable loss.
• Allocation key: the published rule that assigns shared platform, control and change cost to an outcome unit.
• Reconciliation: the process that joins technical events, human work and the business effect into one auditable cost record.

Part I: If model inference became free

Suppose model inference becomes free at midnight. Every input token, output token and cached prefix costs nothing. The following morning, an invoice-resolution agent still has to receive a document, extract its fields, retrieve the purchase order, query the supplier master, compare tax and tolerance rules, request approval where authority is missing, write to the finance system, confirm that the write succeeded and deal with cases that do not reconcile. Engineers still operate the service. Reviewers still inspect riskier cases. Product teams still update prompts, policies, evaluations and integrations when suppliers, regulations or enterprise systems change.

How much of the task cost disappeared? The answer could be material for a long-context, reasoning-heavy route. It could also be a small fraction. The thought experiment exposes the category error in many AI cost discussions. Model pricing is an input price. A business task is a production route. An accepted business outcome is the economic unit.

This distinction is not a plea to ignore token efficiency. Inference spend is directly measurable and often volatile, so it deserves hard budgets, routing policies and optimisation. The error is allowing the most observable cost to stand in for the whole cost. A model invoice measures purchased computation, not completed business work.

AWS now frames agentic economics around task suitability, risk impact and return on investment rather than model use in isolation. Its guidance explicitly asks organisations to distinguish work that warrants contextual, adaptive reasoning from work better served by deterministic automation, and to establish the hidden cost and failure rate of the existing process before comparing alternatives (AWS Prescriptive Guidance). That system boundary is more useful than a rate-card comparison because it places AI beside the available operational alternatives.

Microsoft’s published ROI framework also begins with current process cost and identifies infrastructure, development, deployment, maintenance, retraining and integration as part of investment cost, not just model consumption (Microsoft ROI framework). The categories are directionally right. The harder problem is assigning those costs to an outcome without turning allocation into arbitrary accounting.

The market evidence explains why the pressure to simplify is strong. Google Cloud reported that 74 per cent of surveyed executives said their organisations achieved ROI within the first year, and that 52 per cent reported deploying agents in production (Google Cloud’s 2025 survey summary). These are source-reported executive perceptions from a vendor-sponsored study. They do not establish the cost of a verified outcome. Salesforce’s August 2026 study of 2,025 agentic-AI leaders similarly reported an average of about eight months to meaningful ROI and argued that preparation mattered more than being first (Salesforce survey report). It is useful adoption evidence, but it remains a survey, not an event-level cost ledger.

The appropriate response is neither disbelief nor uncritical acceptance. It is measurement at the route level. Survey evidence can show where executives perceive value. Finance still needs to know which costs entered the denominator, which outcomes entered the numerator and how a technical event was reconciled with a business effect.

Three denominators that must not collapse

Cost per attempted task answers an engineering and capacity question: what did the system consume for everything it admitted? Cost per accepted result answers a production-quality question: what did it cost to generate an output safe and correct enough to act on? Cost per verified outcome answers the economic question: what did it cost to produce and confirm the intended business effect?

If 10,000 tasks are attempted, 8,100 results are accepted and 7,400 effects are verified, the same monthly cost produces three different unit costs. None is inherently deceptive. Each describes a different boundary. The deception begins when the cheapest denominator is labelled as the most complete one.

The total attributable route cost must include both direct and allocated cost for the measurement period. Direct cost follows an event: model calls, retrieval, a paid tool, an individual review or a remediation action. Allocated cost supports many routes: observability, evaluation suites, control testing, platform engineering, change delivery and shared licences. Unallocated cost remains visible until a defensible key exists. It should not vanish because allocation is inconvenient.

Part II: Build the ledger around an outcome state

A decision-useful cost ledger begins with a route identifier created when work is admitted. Every subsequent event carries that identifier or a deterministic link to it. The route also carries task class, complexity segment, risk tier, product version and the outcome definition in force at admission. Without versioned definitions, a rising success rate may reflect an easier denominator rather than a better system.

The route is not just a trace. It is a typed economic record. An event says what happened, who or what performed it, when it began and ended, what resource it consumed, how much cost was direct, which allocation pool applied and what evidence supports the amount. Human events use measured handling time where possible, with a loaded role rate stored separately. Tool events use invoices or metered usage. Shared cost events enter pools and are assigned later by a documented key.

The terminal state is equally important. A route can end as rejected at admission, abandoned, technically failed, policy-blocked, accepted without external action, action-pending, outcome-verified, outcome-reversed or outcome-disputed. These states stop teams from treating a fluent answer as a completed task. A result becomes an economic outcome only when the authoritative system confirms the intended effect.

For an invoice agent, that readback might be a posted invoice with the expected supplier, amount, tax, purchase-order link and approval evidence. A successful API response is not sufficient. The write could be accepted asynchronously and later rejected, posted against the wrong record, reversed by a control or duplicated by a retry. The verifier must query the business object and test the effect.

Outcome definitions need a clock. A service answer may look resolved when the conversation ends and reopen two days later. A collections promise may be accepted but never paid. An invoice may post correctly and be reversed at month end. The verification window should match the business effect and expose later reversal. Report both provisional and durable outcomes where the delay is material.

Definitions also need exclusions. Test traffic, duplicate submissions, cases withdrawn by the customer, work outside policy and unsupported segments should not drift in and out of the denominator. Exclusion may be valid, but it must occur at admission under a versioned rule. Removing hard cases after failure converts an operating metric into a curated demonstration.

For composite work, decide whether the unit is a case, decision, action or durable effect. A case with five invoices cannot be compared with a single-invoice route unless resource use is normalised or complexity is segmented. A customer interaction that resolves two needs may legitimately create two outcomes, but only if the business values and verifies them independently. Volume inflation is easy when outcome granularity is selected after observing performance.

An accepted-result state should preserve the check set that accepted it. Quality gates change with policy, risk appetite and learned failure modes. If April’s outputs passed three checks and September’s passed seven, a trend line without gate version is not comparable. Store the test-suite version, threshold and relevant policy version beside the terminal event.

Finally, readback can fail even when the outcome occurred. A broken join, delayed warehouse feed or changed identifier may create false non-success. Maintain a reconciliation status distinct from the business outcome and operate an orphan queue. Sampling unresolved joins distinguishes genuine missing effects from measurement defects. Finance should not price unverified routes as successes, but product teams need to know whether the cause is operational failure or evidence failure.

State, authority and allocation

Every route crosses three boundaries. The state boundary separates what the agent believes from what the enterprise system records. The authority boundary separates proposal from permitted action. The allocation boundary separates observable spend from cost assigned to the unit. Blurring any of them creates misleading economics.

State requires read-after-write evidence. Authority requires the identity of the human or service principal, the policy decision and the permitted action scope. Allocation requires a cost pool, a key and a reason. These can live in separate operational stores, but the ledger needs stable identifiers and reproducible joins.

Shared-cost allocation is where sensible measurement can become false precision. One team may divide platform cost by every request. Another may assign it by token volume. A third may use successful outcomes. Each answer changes product economics. The right key follows causation as closely as practical.

Compute capacity can follow measured usage. A fixed observability platform can follow active production routes or retained event volume. Product engineering can follow benefited roadmap capacity, perhaps weighted by change effort. A high-risk control team may allocate by risk-weighted outcome volume rather than raw traffic. Training can follow the population trained. Central strategy cost may remain unallocated because forcing it into a product margin would add precision without causation.

The rule should be stable within a reporting period and changed prospectively. Recasting history is appropriate only when finance explicitly requires comparability and preserves the prior view. The ledger should store both the original and revised allocation version.

Cost accounting and decision economics are related, not identical

A statutory or management-accounting view asks where expenditure belongs in an organisational ledger. A product decision asks which future costs change if a route, model or control changes. The first view is necessary for reconciliation. The second is necessary for choice. Confusing them can make an AI product appear expensive because it carries a large allocation that will not disappear if the product stops, or artificially cheap because a central team absorbs costs that will grow when the product scales.

Maintain both views. The reconciled view ties attributable spend to invoices, payroll assumptions and approved pools. The decision view separates variable, step-fixed, committed and avoidable cost. Model and tool consumption may vary with every route. A reviewer team may be fixed within a capacity band and then jump when volume crosses a threshold. A reserved compute commitment may be unavoidable this year but avoidable at renewal. Product engineering may be committed for a release and then fall sharply. These behaviours determine the incremental cost of scale, repair or retirement.

Average cost is therefore not enough for a scale decision. Suppose the current verified-outcome cost is £4.09 and the human alternative is £9.40. The apparent margin is attractive. If the next volume band requires a second specialist review shift, enhanced database capacity and a new control test, the marginal cost of the next 5,000 outcomes may be £7.80. Conversely, a platform with spare committed capacity may have a high reconciled average but a low near-term marginal cost. Both statements can be true.

Keep sunk development cost visible in the historical investment record, but do not let it dictate a future choice merely because it has been spent. Amortisation supports product profitability and portfolio comparison; it does not make an avoidable future loss rational. The decision pack should show cumulative investment, current fully loaded unit cost, short-run marginal cost, long-run avoidable cost and the cash consequence of stopping. This prevents one metric from serving four incompatible decisions.

Allocation also affects behaviour. Charging every product equally for central evaluation may encourage a high-volume, low-risk product to create a private test stack, destroying reuse. Charging only by volume may make a low-volume, high-risk workflow look artificially inexpensive. The allocation key is therefore part of the operating model. It should recover cost, preserve causation and create incentives aligned with safe reuse. When these aims conflict, disclose the policy choice.

Part III: The cheap-model paradox in production

Consider two models for the same task. Model A costs 3 pence per primary run. Model B costs 11 pence. On an inference dashboard, A wins by 73 per cent. But A requires a retry on 22 per cent of routes, while B retries 6 per cent. A’s outputs require human review on 28 per cent of cases, while B requires 12 per cent. Review takes six minutes at a loaded £38 an hour. The cheapest model can become the most expensive route before failures or customer effects are counted.

The paradox is not universal. It occurs when quality differences change downstream work. For a low-risk classification whose errors are caught automatically, model A may remain preferable. For an ambiguous supplier exception where an incorrect match causes manual investigation, delay or duplicate payment risk, model B may be cheaper in total.

The management implication is precise: compare models on the cost frontier of the route, not a leaderboard or price sheet. The frontier includes quality at the operating threshold, review yield, retry behaviour, latency, failure detectability and loss severity. A lower unit input price is valuable only when it does not purchase a more expensive exception distribution.

Retries are not merely extra calls

A retry may carry forward a longer context, repeat retrieval and tool calls, hold locks, delay the queue and produce a duplicate side effect if idempotency is weak. A fallback to a stronger model can be economically sound, but only if the system records the full branch and the decision threshold. Background subagents and evaluators also consume cost that can be missed when teams meter only the user-facing request.

Human review has its own economics. The headline review rate is insufficient. Measure handling time, queue delay, review yield and downstream escape rate. A reviewer who rubber-stamps almost every low-risk result may add delay without control value. A small specialist queue may catch severe errors and be highly valuable. The ledger should distinguish approval, correction, completion, investigation and quality sampling because they have different cost and evidence meanings.

Waiting matters when it consumes scarce capacity, misses service levels or extends working capital. Idle orchestration that incurs no resource or business cost should not be priced theatrically. A delayed invoice that loses an early-payment discount or blocks a month-end close has an economic effect. The task schema therefore stores elapsed time and active resource time separately.

Failure cost needs a tail, not one average. Most technical failures are cheap: the route stops and returns to a queue. A smaller class creates duplicate actions, privacy exposure, incorrect communications, financial leakage or control breaches. Expected loss can inform planning, but incident-level reporting should preserve the actual distribution and uncertainty. Never claim that a short pilot observed a rare-event rate with precision it cannot support.

The strongest counterargument is that early programmes lack stable workflows, so full allocation creates bureaucracy and spurious precision. That objection is partly correct. A discovery-stage prototype does not need a monthly product margin with six decimal places. It does need a visible system boundary, a route identifier, direct cost capture and a register of omitted cost. Otherwise the prototype creates no path to trustworthy economics.

Use progressive fidelity. In discovery, record model, tool and measured human cost for a representative sample, plus explicit omissions. In pilot, add outcome states, path segmentation and provisional shared pools. In production, reconcile to invoices, payroll assumptions, service records and finance-approved allocation keys. The ledger matures with the decision. Uncertainty is acceptable; invisible cost is not.

Architecture choices become economic hypotheses

Once route costs are observable, architectural debates can be tested as economic hypotheses. A larger model may reduce retries but add latency and inference spend. A retrieval step may improve factual accuracy while increasing tool cost and failure points. Parallel tool calls may shorten elapsed time but purchase unused results. A deterministic pre-check may reject unsuitable work cheaply, yet create false rejections that shift value elsewhere. Each design changes a bundle of events, not one line item.

Compare complete route variants on a representative case mix. Preserve assignment so that task complexity does not favour one variant. Measure accepted and verified outcomes, not only offline scores. Retain the same policy and outcome definition. Then calculate the incremental cost and outcome difference with an interval. If the stronger model costs 8 pence more but avoids 40 pence of expected review and correction, it is the cheaper production choice. If the difference appears only in an offline benchmark and never changes route disposition, it has not yet earned the premium.

Latency should be priced only where it changes an outcome. Five additional seconds in a back-office overnight queue may have no economic effect. Five seconds in a live fraud intervention may change abandonment or loss. Store latency distributions and service-level breaches, then connect them to business effects rather than assigning a universal price per millisecond.

Resilience has option value. A secondary model, alternate retrieval source or manual fallback may look idle in average unit cost but prevent a severe service interruption. Account for its committed cost and test whether the availability gain is worth it. Do not bury resilience in normal-route inference, and do not pretend every redundant component has infinite value. The decision needs outage frequency, recovery time, consequence and the cost of the alternative control.

The same logic applies to caching and memory. Caching can reduce model and retrieval consumption, but stale results may increase exception or failure cost. Long-lived memory can improve continuity while adding storage, privacy, deletion and contamination controls. The ledger should tag cache hits, memory reads, freshness state and downstream disposition. Optimisation is credible only when it lowers verified-outcome cost without crossing quality, policy or risk boundaries.

Part IV: Worked example, an invoice-resolution route

Take a monthly population of 20,000 supplier invoices. The current process costs £9.40 per verified resolution, including operations, support and an allocation of finance-platform cost. The proposed agent admits every invoice, but only 16,000 belong to the representative segment used for the first economic decision. The remaining 4,000 include countries, document types or exception categories not yet supported.

Within the representative segment, 12,800 routes complete normally. Another 2,560 require human exception work. Six hundred and forty fail or time out. Of the normal and exception completions, 15,010 pass business and policy checks. The system then confirms 14,720 correctly posted, non-duplicated invoice outcomes in the finance ledger. The difference between accepted and verified exposes asynchronous rejection, readback mismatch, reversal and duplicate prevention.

Direct monthly costs are £12,400 for document extraction and retrieval, £6,900 for model inference, £4,100 for workflow and tool calls, £15,800 for human exception work, £2,600 for sampling and approval, and £3,900 for failed-route recovery. Allocated costs add £8,300 for platform engineering and operations, £3,500 for evaluation and controls, and £2,700 for change and training. The attributable total is £60,200.

That produces £3.76 per attempted in-scope task, £4.01 per accepted result and £4.09 per verified outcome. The model invoice is only 11.5 per cent of attributable cost. Replacing the model with a free one would reduce verified-outcome cost to £3.62 if every downstream rate stayed constant. It would not reduce it to zero.

Now test the cheap-model option. Inference falls by £4,000, but the exception rate rises from 16 to 24 per cent, adding 1,280 reviewed cases. At an observed eight minutes per exception and a £41 loaded hourly rate, added human work is about £7,000 before queue delay, retries and escapes. The cheaper model raises total cost by at least £3,000. It might still be chosen if latency, resilience or supplier concentration improves, but the inference saving alone does not justify it.

The example is synthetic. It is not a claim about invoice automation generally. Its purpose is to expose which observed quantities determine the choice. A real implementation would segment by invoice type, supplier, country, exception reason and risk; measure handling-time distributions; reconcile cloud and application invoices; and model rare losses separately.

The sector boundary matters. In a low-value consumer-content task, an accepted output may be the final unit and automated checks may dominate. In lending, payments, healthcare or public decisions, outcome verification, authority and remedy may be more expensive than inference. Cross-industry transfer is legitimate only at the mechanism level: routes consume resources, exceptions change distributions, and external effects need readback. The specific states, controls and loss values do not transfer without testing.

Part V: The field artefact and operating cadence

The deployable artefact has two parts: an event schema and a reconciliation query. The schema should be small enough to implement across gateways, orchestration, human workflow and systems of record. It should also preserve evidence rather than importing every payload into a financial store.

At minimum, record route_id, event_id, parent_event_id, task_class, segment, risk_tier, event_type, actor_type, resource quantity, currency, direct cost, cost pool, allocation key version, start and end time, outcome state, evidence reference and product version. Sensitive business data should remain in its authorised source. The ledger stores references, hashes or controlled identifiers needed for verification.

The reconciliation query first aggregates direct events by route. It then applies approved shared pools for the reporting period. Next it joins acceptance state and business-system readback. Finally it groups by segment and path. Results should include volume, direct cost, allocated cost, unallocated cost, review minutes, retries, failures, accepted results, verified outcomes, and cost at all three denominators.

WITH route_cost AS (
  SELECT route_id,
         SUM(direct_cost) AS direct_cost,
         SUM(allocated_cost) AS allocated_cost,
         SUM(CASE WHEN event_type = 'human_review' THEN duration_minutes ELSE 0 END) AS review_minutes,
         SUM(CASE WHEN event_type = 'model_retry' THEN 1 ELSE 0 END) AS retries
  FROM ai_cost_event
  WHERE reporting_period = :period
  GROUP BY route_id
), terminal AS (
  SELECT route_id, task_class, segment, path_type,
         MAX(CASE WHEN outcome_state = 'accepted' THEN 1 ELSE 0 END) AS accepted,
         MAX(CASE WHEN outcome_state = 'verified' THEN 1 ELSE 0 END) AS verified
  FROM ai_route_outcome
  WHERE reporting_period = :period
  GROUP BY route_id, task_class, segment, path_type
)
SELECT task_class, segment, path_type,
       COUNT(*) AS attempts,
       SUM(accepted) AS accepted_results,
       SUM(verified) AS verified_outcomes,
       SUM(direct_cost + allocated_cost) AS attributable_cost,
       SUM(direct_cost + allocated_cost) / NULLIF(COUNT(*),0) AS cost_per_attempt,
       SUM(direct_cost + allocated_cost) / NULLIF(SUM(accepted),0) AS cost_per_accepted,
       SUM(direct_cost + allocated_cost) / NULLIF(SUM(verified),0) AS cost_per_verified
FROM route_cost JOIN terminal USING (route_id)
GROUP BY task_class, segment, path_type;

A 30, 60 and 90-day implementation

In the first 30 days, choose one workflow, define the verified outcome and terminal states, instrument route identifiers and capture direct model, tool and human events. Reconcile a sample manually. Publish omissions. Do not begin with enterprise-wide allocation debates.

By day 60, segment normal, exception and failure paths; add readback from the system of record; reconcile metered costs to supplier invoices; and establish provisional pools for platform, evaluation and control. Run the deterministic negative control. Compare at least two route configurations, such as cheap-first escalation and strong-first processing, on total cost and outcome quality.

By day 90, obtain finance approval for allocation keys, report cost per attempt, accepted result and verified outcome with intervals, and assign owners to the largest leakage categories. Add release and operating gates. A route may scale when verified-outcome cost, quality and loss exposure beat the approved alternative. It should repair when exceptions or orphan costs exceed thresholds, and stop when the outcome definition or readback cannot be trusted.

The monthly operating review should not become a catalogue of cloud spend. Begin with verified outcomes and their value or service significance. Then inspect cost, path mix, exceptions, losses, quality and segment drift. Move to technical drivers only after the economic movement is clear. FinOps, product, operations, risk and finance should see the same route population, even if each uses a different lens.

AWS recommends tracking both technical and business metrics, establishing baselines and using decision points to optimise or terminate underperforming agents (AWS measurement guidance). Its related guidance also notes that human feedback cost must be considered and that routing should balance risk-adjusted total cost rather than model price alone (AWS human-feedback guidance). These principles align with the ledger, while the specific schema and denominator design here are practitioner synthesis.

The OECD’s review of experimental evidence warns that generative AI effects vary by task and user experience, and that trust and human expertise matter (OECD Artificial Intelligence Paper 39). McKinsey’s widely cited macro analysis estimates a large potential productivity effect, but explicitly frames that value as potential across use cases and functions rather than a realised unit cost in one organisation (McKinsey Global Institute). Both support the same discipline: macro potential cannot substitute for route-level proof.

Close: price the route you are actually operating

The question is not whether model cost matters. It does. The question is whether it describes the economic unit that management must choose. It does not.

An AI-enabled task begins when work is admitted and ends when an accepted, authorised action produces an independently confirmed business effect or a clearly classified non-success state. Everything consumed between those points belongs to the route. Shared support belongs through a published allocation rule. Unassignable cost remains visible. Exceptions and failures retain the cost already consumed before they branched.

The recommendation changes if three conditions fail. First, the outcome cannot be defined or read back from an authoritative system. Second, shared costs cannot be allocated or at least disclosed without material distortion. Third, exception and failure paths are not observable. In those circumstances, use direct cost per attempt as an engineering measure, label omissions and postpone claims about verified-outcome economics.

For a production decision, require one comparative answer: what does one accepted, policy-compliant and reconciled outcome cost across the complete route, and how does that compare with the best credible alternative at the same quality, risk and volume? That is the number that connects AI architecture to operating economics.

Use the schema on one live workflow. Reconcile one month. Inspect the cost braid. Then optimise the largest total-route driver, whether it is inference, context, review, exceptions, failed actions or change. The result may validate a cheaper model, a stronger model, deterministic automation, a human-AI design or no automation at all. A useful ledger is indifferent to the answer. Its job is to make the choice reproducible.