From Provider Bills to Business Transactions: A Practical Test for AI Agent Cost Accounting

A recent arXiv paper argues that AI costs should be tracked at the level of a business transaction — an order, a claim, or a case — rather than read only from provider invoices aggregated by SKU and charge period. Providers do not see enterprise transaction boundaries, so billing data alone cannot answer what a particular transaction cost. ¹

The paper proposes a Two-Ledger Model that pairs provider billing records with invocation-level usage data and correlates both to business transactions. The supplied abstract reports a simulation, not a production deployment. It describes the model as a proposal; the abstract does not specify how to allocate shared costs. ¹

Why SKU-level billing breaks down for multi-agent AI costs

Finance wants to know what an order, claim, or case cost. Provider billing data is aggregated by SKU and charge period, while providers do not see enterprise transaction boundaries. As a result, billing data alone cannot answer what a specific transaction cost. ¹

The gap matters when a workflow spans clouds, models, orchestration layers, or systems of record. The paper describes multi-agent AI systems spanning these components and explains that settlement-grain billing does not map directly to business transactions. ¹

FOCUS gives billing data one schema across providers, including AI token and requester attribution, but remains at settlement grain. Standardizing billing data can make it easier to work with; it does not itself create a transaction boundary. ¹

For CFOs and FinOps leaders, a useful framing is additive, not substitutive: transaction-level accounting can sit alongside invoice reconciliation rather than replace it. The business question is “what did this transaction consume?” The settlement question is “what did the provider bill us?” A design intended to answer both needs to preserve both views. ¹

What the Two-Ledger Model actually proposes

The model keeps two views separate:

• Settlement ledger — FOCUS-conformant billing data, at settlement grain. ¹
• Attribution ledger — invocation-grain usage records built on OpenTelemetry GenAI telemetry. ¹

The proposed mechanism joins these ledgers. A versioned rate card prices invocation-level usage in near real time, and period reconciliation ties the ledgers to the invoice. ¹ One view connects cost to a business transaction; the other preserves the relationship to provider billing. ¹

That is an architectural proposal, not evidence of adoption. The abstract describes a model and a simulation; it does not report a production deployment. It also says the paper derives seven requirements for transaction-grain accounting, but the abstract does not list them. ¹

What to instrument for LLM cost attribution

The paper proposes a “correlation spine” connecting invocations to transactions through trace context, A2A/MCP metadata, business-key correlation, and probabilistic matching. It says each record is assigned a matching method and confidence. ¹

That suggests a practical instrumentation checklist for platform teams:

• Preserve correlation identifiers across agent calls.
• Carry business keys through the pipeline where policy allows.
• Capture invocation-level usage and retain the relevant provider and model identity.
• Version the pricing inputs behind each near-real-time cost estimate.
• Record how each invocation was matched to a transaction and the confidence of that match.

This is an implementation implication of the paper’s proposed inputs, not a complete specification. The abstract does not enumerate every required field, propagation rule, retention policy, or provider adapter. ¹

One reading is that a central point where model calls pass, such as an enterprise AI gateway, is a natural place to capture provider and model identity per call. Likewise, teams that already define role boundaries between agents have identifiable hand-off points where correlation identifiers could be carried. Both are analysis, not something the paper prescribes.

Illustrative record, not a schema specified by the paper:

{
  transaction_id,
  trace_id,
  invocation_id,
  provider,
  model,
  usage,
  rate_card_version,
  match_method,
  confidence
}

The point of a record like this is not just attaching an amount to a transaction; it is making that attachment inspectable. A finance team could distinguish an explicit trace link from an inferred match and see which rate-card version produced an estimate. That is analysis based on the paper’s correlation and pricing inputs, not a schema the abstract defines. ¹

What happens when trace context is missing

The proposed correlation spine includes methods beyond trace context: protocol metadata, business-key correlation, and probabilistic matching. ¹ These give implementers alternative ways to correlate records, but also make match quality relevant to the accounting record.

In a simulation with known ground truth, the paper reports cost coverage above 99% as trace propagation fell to zero. ¹ That is a simulation result on synthetic data, not a production measurement, and should not be read as proof that real enterprise workflows will reach the same coverage. ¹

Analysis: not every matched invocation deserves equal trust. A direct trace link might be appropriate for AI chargeback, while a low-confidence probabilistic match might be more useful for investigation than assigning final cost. Finance and platform teams need to set those thresholds before automating allocation. The paper’s confidence field makes the distinction possible; it does not set the policy. ¹

Shared and indirect AI costs: an open allocation question

The supplied abstract does not describe a method for allocating orchestration, infrastructure, or other costs shared across transactions. ¹ That leaves a practical design question: a direct invocation may have a transaction link, while a shared service may not have a single natural owner.

Analysis: treat directly attributable invocation costs and shared costs as separate categories. For a shared pool, candidate allocation bases include invocation count, token usage, elapsed processing time, transaction value, or a fixed service charge. These are design options, not methods established in the abstract. ¹ Each answers a different question: allocating by token usage tracks token consumption, while allocating by transaction value reflects business priority more than resource use. For a related framing, see Computational Arbitrage Is an Allocation Problem, Not a Savings Claim.

Whatever basis a company chooses, retaining the allocation method, rate-card version, period, and confidence alongside the amount can make the result easier to inspect. This is a recommendation based on the model’s versioned pricing, reconciliation, and match-confidence elements; it is not a shared-cost method prescribed in the abstract. ¹

The risk is false precision: spreading indirect costs across transactions without making the allocation policy visible can make a policy choice look like an exact measurement. That is an analytical caution, not a result reported by the paper. ¹

AI FinOps reconciliation and spend controls: what the simulation showed

The proposed reconciliation loop compares costs computed from invocation records with settlement-ledger totals for the invoice period, then investigates any residual. The abstract says the unexplained residual identifies shadow AI spend and that the simulation flagged provider billing errors. ¹

In its known-ground-truth simulation, the residual recovered planted unmetered spend within 0.24 percentage points. The same simulation found that mid-flight gating cut p99 transaction cost by up to 61%, with a 2–4% false-pause rate. ¹ These are simulation findings, not production benchmarks or guarantees. ¹

For FinOps, transaction-level estimates could inform budgets, chargeback, and investigation, while period-level reconciliation checks them against provider billing. That depends on versioned pricing and auditable correlation evidence; the abstract proposes these elements but does not establish them as a production control framework. ¹

Pilot framework, not a finished method

Analysis: the architecture described in the abstract can serve as a basis for a pilot: two ledgers, a correlation spine, versioned pricing, and invoice reconciliation provide structure for testing data dependencies. ¹

It is not a complete accounting method based on the information in the abstract. The abstract does not provide a full telemetry schema, specify a shared-cost allocation method, list the seven requirements it says it derives, or report validation beyond simulation. ¹ Those gaps matter when an organization moves from operational estimates to chargeback or financial reporting.

A pilot could run in stages:

• Pick one transaction type, such as an order, a claim, or a case.
• Instrument its agent path and capture invocation-level usage.
• Maintain a versioned rate card and compute attributed costs.
• Reconcile those costs against provider settlement for the same period.
• Track unmatched and low-confidence records, and keep shared costs visible as a separate line.

This sequence is a proposed adoption path, not a result the paper reports. ¹ Success should mean an auditable explanation of both the attributed cost and the residual, not simply a more polished dashboard. The paper’s reconciliation design supports that goal; acceptance thresholds are for the organization to set. ¹

What to do next

Finance should define the transaction type that will serve as the accounting object and decide what correlation confidence is acceptable for chargeback versus management reporting. The paper proposes transaction boundaries but does not set these policies. ¹

FinOps should map settlement sources into the settlement ledger and document how invoice totals reconcile against invocation-derived amounts. Platform teams should preserve correlation across agent, protocol, model, orchestration, and system-of-record boundaries, then log the matching method and confidence for each invocation. ¹

Treat shared costs as a separate workstream rather than assuming every cost has a natural transaction owner. The supplied abstract does not specify how to allocate them. ¹

Start with measurement and reconciliation, not automatic chargeback. Test the correlation approach against a real workload, decide how indirect costs will be allocated, and only then give transaction-level cost numbers financial weight. Until then, present them with confidence scores attached—as estimates under test, not settled fact. ¹