The Two-Ledger Model: Transaction-Grain Cost Accounting for Multi-Agent AI Systems Across Clouds, Models, and Systems of Record

PREPRINT, NOVEMBER 2026

1

The Two-Ledger Model: Transaction-Grain Cost Accounting for Multi-Agent AI Systems Across Clouds, Models, and Systems of Record

arXiv:2611.06989v1 [cs.AI] 4 Nov 2026

Vivek Acharya

Abstract—Enterprises run business transactions through multiagent AI systems spanning clouds, large language models (LLMs), orchestration harnesses, and systems of record. Finance receives AI cost only at settlement grain, aggregated by SKU and charge period. The business question — what did this order, claim, or case cost in AI? — cannot be answered from billing data, because providers never see enterprise transaction boundaries. The FinOps Open Cost and Usage Specification (FOCUS) gives billing data one schema across providers but remains settlement-grain even as it adds AI token and requester attribution. We formalize this grain mismatch, derive seven requirements, and propose the Two-Ledger Model: a settlement ledger of FOCUS-conformant billing data joined to an attribution ledger of invocation-grain usage records built on OpenTelemetry GenAI telemetry. A layered correlation spine (trace context, A2A/MCP metadata, businesskey correlation, probabilistic matching) assigns each record to its business transaction with recorded method and confidence; a versioned rate card prices usage in near real time; period reconciliation ties both ledgers to the invoice, and the unexplained residual identifies shadow AI. Costs are reported per order, claim, or outcome with agentic cost metrics. A simulation with known ground truth shows the spine sustaining cost coverage above 99% as trace propagation falls to zero, the reconciliation residual recovering planted unmetered spend within 0.24 percentage points while flagging provider billing errors, and mid-flight gating cutting p99 transaction cost by up to 61% at a 2–4% false-pause rate. We propose the attribution ledger as an invocation-grain FOCUS profile for standardization. Index Terms—Agentic AI, multi-agent systems, FinOps, FOCUS, cost attribution, unit economics, OpenTelemetry, Model Context Protocol, Agent2Agent, enterprise architecture.

I. I NTRODUCTION N enterprise order-to-cash (O2C) transaction no longer lives in one system. A customer email lands in a customer relationship management (CRM) system, where an intake agent extracts the order intent. A pricing agent checks availability and discounts in SAP. An order-creation agent writes the sales order into Oracle Fusion Cloud. An exception agent opens and works a case in ServiceNow when a credit hold fires. Each agent may call a different frontier large language model (LLM) — one hosted on AWS Bedrock, one on Azure OpenAI, one on Google Vertex AI — through a different orchestration harness, with retries, tool calls, and sub-agent delegation along the way. The business sees one transaction: order ORD-48812. The chief financial officer asks one question: what did that transaction cost in AI?

A

V. Acharya is an Independent Researcher, Dallas, TX, USA (e-mail: vacharya@bu.edu; ORCID: 0009-0002-0860-9462). Manuscript prepared November 2026.

Today no one can answer it. Finance receives AI spend at settlement grain: monthly invoices and daily billing exports aggregated by provider, stock-keeping unit (SKU), and charge period. Engineering holds runtime grain: traces and logs that record each model call but carry no price and no tie to the invoice. The transaction — the unit in which the business actually accounts for its work — exists in neither dataset. Scale this across every multi-cloud, multi-LLM, multi-harness workload in a large enterprise, and AI becomes a growing line item that cannot be attributed to the work it performed. The standards landscape has moved quickly on the settlement side. FOCUS1 , the FinOps Open Cost and Usage Specification developed under the FinOps Foundation (a Linux Foundation project), gives billing data one schema across cloud, SaaS, and AI providers; version 1.4 was ratified in June 2026, and version 1.5, targeted for December 2026, is scoped to add AI model and token cost visibility, a price sheet dataset, and cost attribution to people and agents [2], [3]. On the runtime side, the OpenTelemetry GenAI semantic conventions standardize how a model call is described in telemetry, including input, output, cached, and reasoning token counts [4]. On the agent side, the Model Context Protocol (MCP) [5] and the Agent2Agent (A2A) protocol, contributed by Google to the Linux Foundation in June 2025 [6], [7], standardize how agents reach tools and each other. Each of these standards is necessary. None of them, alone or together, yields transaction-grain cost. Billing data lacks the transaction; telemetry lacks the price; agent protocols lack both. The gap between them is where AI cost attribution falls today, and it is the gap this paper addresses. We ask three research questions: • RQ1. Why can settlement-grain billing standards such as FOCUS not answer transaction-grain cost questions for agentic workloads, and what exactly is missing? • RQ2. What minimal, standards-aligned architecture gives every business transaction an auditable, reconcilable AI cost, across clouds, models, harnesses, and systems of record? • RQ3. How should that cost be expressed in the language in which businesses already track their work — orders, claims, cases, hires — and tied back, period by period, to the invoices finance actually pays? 1 FOCUS is an open specification published under the Creative Commons Attribution 4.0 (CC-BY-4.0) license by the FinOps Open Cost and Usage Specification project, a Linux Foundation project series [1]; Linux Foundation trademark usage rules apply.

PREPRINT, NOVEMBER 2026

2

Our contributions are:

1) A formalization of the grain mismatch between settlement-grain billing data and transaction-grain business accounting, with seven requirements (R1–R7) that any solution must meet (Section III). 2) The Two-Ledger Model, a reference architecture that joins a FOCUS-conformant settlement ledger to an invocation-grain attribution ledger built on OpenTelemetry GenAI telemetry, with an enterprise LLM gateway as the primary metering point, a versioned rate card for near-real-time pricing, and a component-level deployment reference architecture (Section IV). 3) The correlation spine, a layered correlation strategy — trace context, A2A/MCP metadata propagation, business-key correlation sets, and probabilistic matching — that assembles one business transaction from spans scattered across systems of record that cannot all propagate trace context (Section V). 4) Business-language cost semantics: a mapping from invocation-grain cost to a process taxonomy such as the APQC Process Classification Framework, and a set of agentic cost metrics — effective cost per transaction, tail (p95) cost per outcome, token efficiency, coordination overhead, and rework cost — together with a period reconciliation discipline whose variance doubles as a shadow-AI signal (Sections VII and VIII). 5) An analytical evaluation, a synthetic O2C walkthrough, a simulation study, and a realization analysis demonstrating the model end to end — the simulation measuring correlation coverage and accuracy under degraded instrumentation, reconciliation recovery of planted unmetered spend and provider billing errors, and the tail-cost effect of mid-flight gating, all on synthetic data with known ground truth — including three sourcing models (assemble, accelerate, or productize) and an illustrative best-of-breed market mapping of the components, and a discussion of alignment with the FOCUS 1.5 AI scope, including the proposal that the attribution ledger itself be published as a FOCUSshaped, invocation-grain dataset using the specification’s extension (x_) columns (Sections IX–XIII).

The remainder of the paper is organized as follows. Section II reviews FOCUS, runtime telemetry standards, agent protocols, and related work. Section III formalizes the problem. Sections IV–VIII present the Two-Ledger Model. Section IX walks through a synthetic O2C scenario. Section X evaluates the model analytically, and Section XI reports a simulation study on synthetic data with known ground truth. Section XII examines how the architecture is realized — assembled by the enterprise, delivered as an accelerator, or productized — against a best-of-breed market exemplar. Section XIII discusses governance integration, limitations, and standardization outlook. Section XIV concludes.

TABLE I FOCUS RELEASE TRAJECTORY [2], [3], [8]. Version

Ratified / target

Headline additions

1.0 1.1 1.2 1.3

Jun. 2024 Nov. 7, 2024 May 29, 2025 Dec. 4, 2025

1.4

Jun. 4, 2026

1.5

Dec. 2026 (target)

Core schema; four major clouds Granular multi-cloud columns SaaS and PaaS billing support Allocation columns; contract commitments; data finality flags Invoice reconciliation; commitment detail; no AI-specific columns AI model/token visibility; price sheet; person/agent attribution

II. BACKGROUND AND R ELATED W ORK

A. FOCUS: Normalizing the Bill FOCUS defines one schema — one set of column definitions and one vocabulary — for cost and usage data across technology providers [2]. Table I summarizes its release trajectory. Version 1.0 (June 2024) established the core columns and brought the four leading cloud providers to a common export format. Version 1.1 (November 2024) deepened multicloud granularity. Version 1.2 (May 2025) extended the specification to software-as-a-service (SaaS) and platform-as-aservice (PaaS) billing, which is what lets a direct modelvendor invoice sit in the same table as a hyperscaler export. Version 1.3 (December 2025) added allocation columns for splitting shared-resource cost, a contract-commitment dataset, and dataset timestamping with completeness flags [8]. Version 1.4 (June 2026), the current ratified version, added invoice reconciliation, billing-period finality, and commitment detail; it contains no AI-specific columns [2], [3]. Two properties of FOCUS matter for this paper. First, the schema can already carry token-denominated AI charges using existing columns: token counts in ConsumedQuantity with ConsumedUnit, the priced model offering in SkuId and SkuPriceId, the token type in SkuMeter, the service classified under the AI and Machine Learning service category, and reserved model throughput in the commitment-discount columns [9], [10]. The gap before 1.5 is agreed usage of these columns, not missing schema. Second, the specification reserves an x_ prefix for custom columns, which guarantees that enterprise extensions cannot collide with future standard columns [10]. We use both properties in Section IV. The 1.5 scope, announced ahead of ratification, adds requester-attribution columns — reported in preview analyses as PrincipalId, CredentialId, and RequesterDetails — so that billing data can name the person, workload, or agent behind a charge without a join to observability data [3], [11]. This is, to our knowledge, the first time a billing standard explicitly acknowledges non-human requesters. We return to why identity attribution, while necessary, still does not close the transaction-grain gap (Section III).

PREPRINT, NOVEMBER 2026

B. Runtime Telemetry: OpenTelemetry GenAI and Trace Context The OpenTelemetry (OTel) GenAI semantic conventions define a vendor-neutral vocabulary for model telemetry: span names and attributes for model operations (gen_ai. provider.name, gen_ai.operation.name, requested and response model identifiers) and token accounting (gen_ai.usage.input_tokens, gen_ai.usage. output_tokens, with cached and reasoning tokens where the model reports them), plus metrics for token usage and operation duration [4]. The conventions now extend to agent and workflow execution and to MCP operations, and are maintained in a dedicated repository with an overall status of Development [4]. Trace assembly across process and service boundaries rests on W3C Trace Context, which standardizes the traceparent header for context propagation [12]. C. Agentic Systems and Agent Protocols LLM-based agents interleave reasoning with tool use [13] and increasingly operate as conversing multi-agent ensembles [14]. Two open protocols shape the enterprise substrate: MCP standardizes how a model-backed application reaches tools and data sources [5], and A2A, an open protocol created by Google and now a Linux Foundation project with a v1.0.0 specification, standardizes secure communication between opaque agents across frameworks and vendors [6], [7]. For cost accounting, these protocols matter in a specific way: they are the seams across which correlation context must survive. An agent step that crosses an A2A boundary or an MCP tool call that fans out to another model must carry enough metadata that its spend can still be assigned to the originating business transaction. A recent IETF Internet-Draft proposes signaturechained delegation tokens for AI agents that carry per-chain spend ceilings, explicitly not running balances, with spend enforcement out of band and cost recording and billing outside its scope [15]; Section IV-E relates our attribution tokens to that design. D. Business Process Context Enterprises track work in process language. Cross-system flows such as order-to-cash, procure-to-pay, and hire-to-retire are typically anchored in a process taxonomy; the APQC Process Classification Framework (PCF) is the most widely used cross-industry example [16]. Process platforms have long solved a structurally similar correlation problem: BPMN 2.0 defines correlation keys that bind asynchronous messages to the right process instance using business data (an order number, a case number) when no technical context travels with the message [17]. We adapt this device directly in Section V. E. Related Practitioner Work and Positioning Practitioner work has started on parts of the problem. Microsoft’s FinOps guidance demonstrates normalizing Azure OpenAI billing into FOCUS and computing token unit economics from billing data [18], and proposes meter maps that enrich opaque FOCUS rows with AI attributes (token type,

3

product) via a join against a curated SKU dictionary [19]. Vendor tooling has shown that token usage can be written as FOCUS 1.4 rows today using existing columns [10]. All of this operates within or against the settlement ledger; none of it reaches the transaction, because the transaction is not present in billing data to begin with. Our contribution is to treat that absence as structural, not incidental, and to design the second ledger and the join that the question requires. To our knowledge, no prior work formalizes transaction-grain AI cost attribution for multi-agent systems spanning multiple systems of record, nor connects the FOCUS, OpenTelemetry GenAI, MCP, and A2A standards into one accounting architecture. III. P ROBLEM F ORMALIZATION A. Definitions Business transaction (BT). A unit of work the business accounts for as one thing: an order, a claim, a support case, a hire. Each BT b carries a stable identifier bt_id and a type τ (b) drawn from the enterprise process taxonomy (e.g., a PCF element). A BT spans systems of record and time; ORD-48812 is a BT. • Outcome. The completed result of a BT against which the business measures value (order fulfilled, claim adjudicated, case resolved). Cost per outcome is the unit economics the business ultimately wants. • Agent step. One agent’s bounded contribution to a BT: a span (or span subtree) executed by an identified agent within a harness, possibly delegated across an A2A boundary. • Model invocation. A single call i to a model endpoint, with usage vector ui = (ui,c )c∈C over token classes C (input, output, cache read, cache write, reasoning), a priced offering si (provider, model, SKU), a timestamp ti , an outcome status (success, retried, failed), and any per-call tool fees fi (e.g., metered search calls). • Settlement record. A row of billing data — in this paper, a FOCUS row — aggregating charges by provider, SKU, charge period, and billing dimensions such as sub-account and tags. •

B. The Grain Mismatch Let I be the set of model invocations in a period and F the set of settlement records for the same period. Billing generation applies an aggregation σ : I → F that is many-to-one and keyed on provider-visible dimensions only. The assignment of invocations to business transactions is a correlation β : I → B, where B is the set of BTs. The business question is the cost of I(b) = { i : β(i) = b }. The structural observation is simple: β is not recoverable from F. The provider never sees bt_id; the harness, the retry, the sub-agent delegation, and the downstream system of record are all invisible to billing generation, so σ destroys exactly the information β needs. Tags do not fix this: a tag identifies a workload or a team, not a transaction instance, and tags cannot in general vary per request on token-metered services. Identity attribution (FOCUS 1.5’s requester columns) narrows the aggregate — it says which agent spent — but an agent

PREPRINT, NOVEMBER 2026

4

TABLE II R EQUIREMENTS FOR TRANSACTION - GRAIN AI COST ACCOUNTING .

TABLE III ATTRIBUTION - LEDGER CORE SCHEMA WITH STANDARDS MAPPING .

ID

Requirement

Field

R1

Provider neutrality. One accounting model across clouds, model vendors, SaaS AI, and self-hosted inference. Transaction grain. Every BT has a cost object; every attributable invocation maps to exactly one BT, across systems of record. Business language. Costs roll up to the enterprise process taxonomy and to outcome units (per order, per claim, per case). Agentic completeness. Fan-out, delegation (A2A), tool calls (MCP), retries, and failed attempts are all captured and classifiable. Economic fidelity. Negotiated rates, commitment amortization (provisioned throughput), cache and batch tiers, per-call tool fees, and shared-infrastructure allocation are reflected. Reconcilability. Attributed cost ties to invoices period by period; the variance is measured and decomposable. Timeliness. A near-real-time cost estimate exists at transaction close; settlement truth corrects it at period close.

R2 R3 R4 R5 R6 R7

serves thousands of transactions per period, so identity grain is still not transaction grain. Conversely, runtime telemetry recovers β naturally — the invocation happens inside the transaction’s execution — but telemetry carries no settlement truth: no negotiated rate, no commitment amortization, no invoice. So the answer requires two datasets with one join, not a better version of either dataset alone. This answers RQ1, and it motivates the requirements below.

Runtime source (OTel Settlement GenAI / W3C) (FOCUS)

trace_id, traceparent [12] span bt_id, bt type propagated baggage / correlation spine (§V) outcome id business event tenant, app, env resource attributes agent id, har- gen_ai.* agent spans ness credential workload identity provider, model gen_ai.provider. name, model attrs token counts by gen_ai.usage.* class tool-call fees status / retry flag est. list / eff. cost rate card version correlation method, confidence

span events span status rate card (§VI) gateway spine level L1–L4

analog

— (absent) x_bt_id, x_bt_type x_outcome_id Tags 1.5 PrincipalId / RequesterDetails 1.5 CredentialId SkuId, SkuPriceId, SKU price details ConsumedQuantity + ConsumedUnit; type in SkuMeter per-call SKU rows — ListCost EffectiveCost x_rate_card_ver

/

x_corr_method, x_corr_conf

dataset; 1.3’s timestamps and completeness flags gate downstream processing on data finality [8]. Nothing in this layer is novel. Its job is completeness: this is the ledger that ties to cash.

C. Requirements Table II states requirements R1–R7. Four failure modes stress them: bypass (calls that never pass a metering point — shadow AI); broken propagation (context lost at a SaaS or protocol boundary); shared pools (provisioned throughput, graphics processing unit (GPU) clusters, vector databases serving many BTs); and settlement lag (invoices arriving weeks after the work). The architecture must degrade gracefully under each. IV. T HE T WO -L EDGER M ODEL The Two-Ledger Model answers RQ2. The organizing idea comes from accounting. A general ledger cannot answer subledger questions; no company runs accounts receivable out of the general ledger. FOCUS is the general ledger of technology spend. Transaction-grain AI cost is a sub-ledger problem, and the sub-ledger must be built where the transactions are visible: at runtime. Figure 1 shows the architecture; we describe each component. A. Settlement Ledger The settlement ledger is a FOCUS-conformant lake of all technology billing data: hyperscaler exports, marketplace charges, and — via FOCUS 1.2’s SaaS support — direct model-vendor invoices normalized into the same columns [2], [9]. Commitment purchases (provisioned model throughput, reserved GPU capacity) enter through the commitmentdiscount columns and, from 1.3, the contract-commitment

B. Attribution Ledger The attribution ledger records one row per model invocation (and one per metered tool call), written at runtime. Table III gives the core schema and its mapping to OpenTelemetry GenAI attributes and FOCUS columns. Three design choices matter. First, the gateway is the primary metering point. Routing every LLM call — all providers, all harnesses — through an enterprise gateway makes the attribution ledger a side effect of normal operation rather than a per-team instrumentation project, and makes bypass an exception to detect rather than a norm to tolerate. Where a gateway is impossible (embedded SaaS copilots, provider-managed agents), an SDK/sidecar writes the same records, and provider usage application programming interfaces (APIs) backfill what neither can see; those rows carry a lower-confidence source marker. Second, the schema is the OpenTelemetry GenAI vocabulary plus business keys. Token classes, model identity, and operation timing come straight from the conventions [4]; the additions are bt_id, the transaction type, the outcome identifier, and the correlation metadata of Section V. This keeps the ledger implementable by configuration on any OTelinstrumented stack. Third, the attribution ledger is itself published FOCUSshaped. Because FOCUS already has columns that carry token usage and reserves the x_ prefix for extensions [9], [10], the gateway can emit the attribution ledger as invocation-grain

PREPRINT, NOVEMBER 2026

5

Multi-agent workloads: harnesses, agents, MCP tools, A2A peers (across CRM, SAP, Oracle Fusion, ServiceNow, custom apps)

Rate card (versioned)

Enterprise LLM gateway (primary metering point)

Model providers (Bedrock, Azure OpenAI, Vertex, direct)

Attribution ledger (invocation grain) OTel GenAI fields; bt_id, trace_id, agent id, token classes, est. cost

Settlement ledger FOCUS-conformant exports + vendor invoices

Join & allocation layer: correlation spine β · shared-cost allocation · period reconciliation ∆

Business semantics: process taxonomy (PCF) roll-up · cost per transaction / per outcome · c95 , TE, CO, RW · showback and budget gates Fig. 1. The Two-Ledger Model. Every model call is metered at the gateway into an invocation-grain attribution ledger priced by a versioned rate card; FOCUS-conformant billing data forms the settlement ledger; a join and allocation layer correlates, allocates, and reconciles; a business semantics layer expresses cost in process language.

FOCUS rows with x_bt_id, x_trace_id, and companions. One query engine and one column vocabulary then serve both grains. This design choice is also a standardization proposal, which we take up in Section XIII. A privacy boundary is built into the schema: the ledger carries usage metadata — token counts, identities, timings, status — and never prompt or response content. Content has no role in cost accounting and does not enter this path. C. Rate Card Service The rate card is a versioned internal price book: list prices per token class per SKU, negotiated rates, cache-read and batch tiers, context-window price tiers where providers use them, per-call tool fees, and amortization rules for committed capacity. Every attribution row is priced on write with the then-current version, giving R7’s near-real-time estimate; reconciliation (Section VIII) corrects rate drift at period close. A price sheet dataset is in the announced FOCUS 1.5 scope [3]; when ratified, it becomes the rate card’s settlement-side anchor. D. A Deployment Reference Architecture Two questions decide what an enterprise actually builds here. Is this a system or a gateway feature? It is a reference architecture: cooperating planes with specified records at every seam, of which the gateway is the primary metering point — necessary, but one component among eight (Table IV). Is it a product? No single one. Every component maps to a category most enterprises already run — an LLM gateway, OpenTelemetry collectors, a lakehouse, a FinOps platform, an identity provider, a policy engine — so the proposal is compositional. The contribution is the contracts between the components: which identifiers and which records cross each edge of Fig. 2, so that independently sourced parts add up to one auditable accounting system.

End to end, a transaction moves through the architecture as follows. (1) A call leaves a harness carrying traceparent and bt_id baggage; the gateway authenticates the workload identity, checks the budget gate, and forwards to the provider endpoint. (2) The gateway writes an attribution row priced by the current rate-card version. (3) Paths the gateway cannot see arrive as SDK spans or usage-API backfill, marked lowerconfidence. (4) Systems of record emit business events — order created, case opened — carrying their keys. (5) The correlation engine resolves β through the spine and stamps method and confidence on every row. (6) The allocation engine applies αp from shared-pool meters. (7) Providers deliver FOCUS exports into the settlement lake, gated on finality. (8) At close, reconciliation computes ∆, restates the period against settled rates, and names the unmetered residual. (9) Marts publish unit economics, and c95 breaches return to the gateway as gate decisions — the loop that connects accounting back to the Govern and Gate stages of the agentic lifecycle (Section XIII). Three non-goals set the scope. The architecture stores no prompt or response content; it does not replace an observability platform or a FinOps platform; and it does not standardize agent behavior. It standardizes the accounting records those systems exchange. Section XII returns to this architecture with the market’s actual parts. E. Extensions: Verifiable Lineage, Two-Sided Reconciliation, Mid-Flight Gating Three extensions strengthen the model where finance and runtime control meet. They are described here and, where measurable, evaluated in Section XI. Verifiable lineage (level L0). The gateway or orchestrator mints, at transaction start, a signed attribution token binding the business transaction identifier, type, tenant, issuance time, expiry, and a nonce, signed with a key in the client’s keymanagement service. The token travels in trace baggage and

PREPRINT, NOVEMBER 2026

6

Execution plane orchestration harnesses & agents · MCP tools · A2A peers — every call carries traceparent + bt_id baggage

Systems of record CRM · SAP · Oracle Fusion · ServiceNow — business events with keys

Cloud & AI providers (external) inference endpoints · billing generation

Metering plane LLM gateway cluster: workload authN · budget gate · token capture · price-on-write backfill: SDK/sidecar spans, provider usage-API pollers (lower confidence)

Rate card service versioned: list · negotiated · commitment rules · tiers

Settlement lake FOCUS exports + vendor invoices, gated on finality flags

Attribution ledger invocation-grain stream → table, FOCUS-shaped with x_ business keys

Taxonomy & identity registry PCF codes · tag schema · agent PrincipalIds

Correlation & allocation engines spine β (L1–L4, confidence) · shared-pool shares αp

Reconciliation engine ∆ decomposition · unmetered (shadow-AI) report

Unit economics & gates ĉ, c95 , TE/CO/RW marts & APIs · budget-gate decisions

Close & showback invoice tie-out pack · chargeback · working-group export

Fig. 2. Deployment reference architecture. Left: the runtime attribution path (execution → gateway metering → attribution ledger → correlation/allocation → unit economics). Right: the settlement path (provider billing → FOCUS lake → reconciliation → close). Middle: shared services — business events from systems of record, the versioned rate card, and the taxonomy and identity registry. The dashed return edge is the budget-gate feedback from cost SLOs to the gateway; inference traffic from the gateway to provider endpoints is omitted for clarity (see Fig. 1). TABLE IV R EFERENCE - ARCHITECTURE COMPONENTS : RESPONSIBILITIES , INTERFACES , AND TYPICAL REALIZATIONS . Component

Responsibility

1 LLM gateway

Meters every sanctioned model call; enforces workload authN, policy, and budget gates; stamps agent and credential identity; prices rows on write 2 SDK/sidecar emit- Cover paths no proxy sees (embedded copilots, ters & usage pollers provider-managed agents, batch); backfilled rows carry lower-confidence source markers 3 Attribution ledger Invocation-grain system of record for usage; FOCUS-shaped rows with x_ business keys 4 Settlement lake All billing truth: FOCUS exports and vendor invoices, gated on data-finality flags 5 Rate card service

Versioned price book: list and negotiated rates, commitment-amortization rules, cache/batch/context tiers, tool fees

6 Taxonomy identity registry

& One schema for every join key: PCF process codes, the tag taxonomy, agent PrincipalId and credential registry 7 Correlation, allo- β at L1–L4 with recorded confidence; αp for cation, reconciliation shared pools; period ∆ decomposition and the engines unmetered report 8 Unit-economics & ĉ, c95 , TE/CO/RW per process type; showback gate layer and chargeback; turns cost-SLO breaches into gateway gate decisions

in A2A task metadata or MCP call context. At each delegation, the delegating party mints a child token hash-linked to its parent, so a signature chain runs from the originating transaction to every downstream invocation, including across organizational boundaries. A usage record carrying a verified token is assigned at a level L0 that takes precedence over

Key interfaces

Typical realization

In: model calls with trace context; out: attribution rows, gate verdicts; onward: provider endpoints OpenTelemetry GenAI spans; provider usage APIs

LLM-gateway–class proxy (Envoy-based or commercial)

Append stream in; SQL out to engines and marts Provider FOCUS exports (1.2 SaaS path for model vendors); invoice feeds Pricing API to the gateway; settledrate restatement to reconciliation; FOCUS 1.5 price-sheet sync when ratified Configuration to gateway, engines, and tagging pipelines

Lakehouse table (Iceberg/Delta class) fed by a stream FinOps platform store or a lakehouse zone

Both ledgers in; unit-economics marts and the close pack out

Stream and batch jobs on the lakehouse

BI and APIs out; policy push back to the gateway

FinOps/BI semantic layer + a policy engine

OTel SDK and Collector; scheduled collectors

Internal service over a config repository Workload identity provider + metadata catalog

L1–L4, with the level recorded on the record like any other; an auditor can check a transaction’s cost lineage from public keys and the hash chain without trusting the ledger operator. The token differs from capability tokens with static spend ceilings [15] in three ways: it is bound to the business transaction, it participates in the correlation spine with its

PREPRINT, NOVEMBER 2026

assignment recorded alongside confidence stamping, and L0assigned spend is reported as a distinct, verifiable stratum in reconciliation. In the budget-envelope variant, the token also carries a running remaining allowance and delegation depth; a delegate decrements the allowance locally from consumed amounts it returns, and a child token’s sub-envelope never exceeds its parent’s remainder, so a cost cap propagates with delegated work without a call back to the gateway. Two-sided reconciliation. With double-entry semantics, each priced usage record posts a debit to its cost object and a credit to a provider-payable accrual keyed by provider, SKU, and period; ingested settlement records clear accruals. The reconciliation of Section VIII then runs in both directions: billed consumption with no accrual is the unmetered residual, and accruals left uncleared after finality — or billed quantities priced inconsistently with the settled price sheet — form a provider billing-discrepancy register. The same join detects unsanctioned internal consumption and provider-side billing errors. Mid-flight gating. The budget gate of Section VII need not wait for outcomes. A running cost accumulator is kept per open transaction; a forecaster estimates the conditional distribution of completion cost given transaction type, current stage, and accumulated spend, from historical trajectories of the same type; when the forecast probability of breaching the type’s cost objective exceeds a threshold θ, the gate acts before further spend — pausing for approval, capping delegation depth or retries, substituting a cheaper priced offering, or terminating a runaway loop. The trade-off, a paused transaction that would have finished within budget, is measurable and is measured below.

7

TABLE V T HE CORRELATION SPINE . Lvl

Mechanism

Where it works / fails

L1

W3C traceparent + baggage carrying bt_id [12] Protocol metadata: bt_id and trace context carried in A2A task metadata and MCP call context [5], [7] Business-key correlation sets (BPMN-style): order no., case no., invoice no. + system event time windows [17] Probabilistic matching: temporal proximity, agent identity, tenant, workload fingerprint; emits confidence ∈ [0, 1]

In-process and service-to-service within instrumented estates; fails at opaque SaaS boundaries.

L2

L3

L4

Across agent and tool seams between cooperating parties; fails when a peer strips metadata.

Across systems of record (SAP, Oracle Fusion, ServiceNow, CRM) that expose business keys but no trace context; deterministic when keys are unique. Last resort for legacy or black-box paths; rows below a confidence floor fall to a pooled cost object, never silently to a BT.

for SKU s, class c at time t from the rate card, fi per-call tool fees, Psh the shared resources (vector stores, provisioned pools, GPU clusters), Cp the period cost of shared resource p, and αp (b) its allocation share to b (metered where possible — queries served, tokens drawn from the pool — policybased otherwise, using FOCUS 1.3 allocation semantics on the settlement side [8]). The estimated effective cost of a transaction is

V. T HE C ORRELATION S PINE Requirement R2 depends entirely on β: assembling one BT from spans scattered across systems that differ in what context they can carry. No single mechanism survives every boundary in an O2C flow, so we define a layered spine; every attribution row records which layer produced its assignment and with what confidence (Table V). Two disciplines make the spine auditable. Explicit degradation: an invocation that cannot be assigned at L1–L3 above a confidence threshold is pooled by workload, not forced onto a transaction; forced assignment would corrupt the unit economics it exists to serve. Confidence-weighted reporting: transaction cost can be reported with its correlation confidence, and process-level roll-ups can be stratified by spine level, so finance can see how much of a number is deterministic and how much is inferred. Layer L3 deserves a note. It is forty years of integration practice, not something new: BPMN correlation keys applied to cost. What is new is only the requirement that the spine’s provenance travel with every dollar. VI. C OST S EMANTICS A. Transaction Cost Let I(b) be the invocations correlated to BT b, ui,c the usage of token class c in invocation i, reff (s, c, t) the effective rate

ĉ(b) =

X X i∈I(b)

 X ui,c reff (si , c, ti ) + fi + αp (b) Cp .

c∈C

p∈Psh

(1) For committed capacity (provisioned throughput treated like a reserved instance), the effective rate amortizes the commitment over consumption measured in the commitment’s own meter mi — provisioned-throughput units or the provider’s normalized consumption units, not raw token counts, since token classes are not equivalent units: Cpcommit (p) , reff = P i∈Ip mi

(2)

where Ip is the set of invocations served from commitment p in the period and mi = µp (ui ) is invocation i’s consumption in that commitment’s own meter, a provider-defined normalization of the usage vector. For such invocations, the inner (p) term of Eq. 1 evaluates as mi reff . Idle capacity is either held centrally or spread per policy — a choice that must be explicit, because it decides whether a quiet month makes every transaction look expensive. Marginal cost (list or negotiated per-token rate only) and fully loaded cost (Eq. 1) are both reported; conflating them is a common unit-economics error in practice.

PREPRINT, NOVEMBER 2026

8

B. Agentic Metrics Agentic execution makes cost per outcome a distribution, not a number: fan-out, deliberation, retries, and tool loops vary per instance. For a transaction type τ , we therefore manage the tail,
c95 (τ ) = Q0.95 {ĉ(b) : τ (b) = τ } ,

(3)

as a cost service-level objective (SLO) alongside the median. Three decompositions show where money goes inside a transaction:

(tenant, product, process, environment), mandated in traces, tags, and gateway metadata alike. VIII. R ECONCILIATION : T YING THE L EDGERS T OGETHER At period close, for each provider g, SKU s, and charge period P , the settlement ledger’s billed amount is compared to the sum of attributed effective cost: ∆g,s,P = Billedg,s,P −

X i∈Ig,s,P

ĉi ,

V =

∆ . (7) Billed

Here ĉi is invocation i’s priced cost, the inner term of Eq. 1; for commitment SKUs, the attributed side is the (token efficiency) (4) amortized consumption of Eq. 2 plus allocated idle. FOCUS i∈I(b) c ui,c 1.4’s invoice-reconciliation support and 1.3’s finality flags gate cost of coordination spans CO(b) = (coordination overhead) the computation on complete data [2], [8]. The variance ∆ ĉ(b) (5) is then decomposed into: (i) rate drift (rate card vs. invoiced rates — corrected by restating the period’s rows against settled cost of failed/retried spans (rework cost) (6) rates); (ii) timing (usage near period boundaries); (iii) sharedRW(b) = ĉ(b) pool idle (Eq. 2 policy effects); and (iv) unmetered spend — where ufinal billed consumption with no attribution rows at all. Component out counts output tokens of the accepted final result (the denominator deliberately includes input tokens, (iv) is the shadow-AI report: it names, by provider and SKU, so values well below one are expected and are comparable exactly the AI spend occurring outside sanctioned paths. The within a transaction type, not across types), coordination spans reconciliation variance ratio V is therefore both an accounting are inter-agent planning, routing, and consensus traffic (as control and a governance control, and it belongs on the same opposed to task-productive spans), and the definitional choices executive page as the unit costs. The operating discipline — what counts as “final,” what counts as “coordination” — mirrors financial close: attribution coverage (share of billed are fixed per transaction type and versioned like the rate card. AI spend carrying a bt_id or an explicit pool) trends toward TE extends single-call token-efficiency thinking to the whole a threshold, and exceptions are worked like unreconciled cash. transaction; CO makes the price of multi-agent deliberation itself a managed line [20]; RW is the agentic analog of cost IX. I LLUSTRATIVE S CENARIO : O NE O2C T RANSACTION of quality. All figures in this section are synthetic and illustrative. They are constructed to exercise the model; they are not VII. ACCOUNTING IN THE L ANGUAGE OF THE B USINESS measurements from any production system. RQ3 asks for cost in business language, not engineering Order ORD-48812 (BT type: O2C) arrives as a customer vocabulary. Three bindings do that. email. Table VI lists the attribution-ledger rows the transaction Process taxonomy binding. Each BT type τ is mapped to generates across four systems of record, three clouds, and four an element of the enterprise process taxonomy — for cross- priced model SKUs (three frontier, one mid-tier), including industry use, the APQC PCF [16]; an O2C transaction’s steps one retried step. Rates are illustrative blended effective rates map onto the corresponding PCF elements across the market- per million tokens (Mtok) after commitment amortization. and-sell, deliver, and manage-financial-resources categories. From the same rows: RW(b) = 0.0234/0.2122 ≈ 11% AI cost then rolls up the same hierarchy the business already (the failed Fusion attempt), CO(b) = 0.0066/0.2122 ≈ 3%, uses for cycle time and quality: invocation → agent step → and TE(b) = 7,900/57,800 ≈ 0.14 — output tokens of all transaction → process → value stream. The PCF code lives on successful steps (the failed attempt excluded; this transaction the attribution row (x_bt_type), so the roll-up is a GROUP type’s versioned definition of “final”) over all tokens consumed BY, not a re-mapping project. — flagging that most tokens bought context and coordination, Outcome binding. Unit economics are stated per out- not the answer. Across a synthetic month of O2C transactions come unit the operating business recognizes: cost per order of this shape, a close-out report would read: median cost shipped, per claim adjudicated, per case resolved, per candi- per order $0.19, c95 = $0.61 (long tail driven by exception date screened — with distributional form (median, p95) rather cases that loop in ServiceNow), rework 9% of O2C AI spend. than averages alone, per Eq. 3. At close, reconciliation (Eq. 7) against the settlement ledger Financial binding. Showback and chargeback dimensions shows V = 7.4% for one provider, decomposed as 1.1% rate (cost center, product, tenant) come from the same tag tax- drift, 0.8% timing, 1.5% pool idle — and 4.0% unmetered: onomy applied in both ledgers, so the number the process a team calling a model vendor directly on a corporate card, owner sees and the number finance allocates reconcile by visible in the FOCUS SaaS rows and absent from attribution. construction. The governing rule is simple: the join keys are a That 4.0% is the shadow-AI finding; it is produced by the governance decision, not a tooling decision — one taxonomy ledger delta, not by an audit. ufinal (b) TE(b) = P out P

PREPRINT, NOVEMBER 2026

9

TABLE VI S YNTHETIC ATTRIBUTION - LEDGER ROWS FOR BT ORD-48812 ( ILLUSTRATIVE RATES ; ALL DATA SYNTHETIC ). Step

System of record

Agent

Provider / model

In tok

1 2 3a 3b 4 5 —

CRM SAP Oracle Fusion Oracle Fusion ServiceNow (coordination) —

intake-agent pricing-agent order-agent order-agent (retry) exception-agent supervisor tool: entitlement check

Azure OpenAI / frontier AWS Bedrock / frontier Vertex AI / frontier Vertex AI / frontier Azure OpenAI / frontier AWS Bedrock / mid-tier metered API

6,200 9,800 7,500 7,600 12,400 5,000 —

Status / corr.

Est. cost

ok / L1 ok / L2 (A2A) failed / L3 (order no.) ok / L3 (order no.) ok / L3 (case no.) ok / L1 ok / L2 (MCP)

$0.0212 $0.0579 $0.0234 $0.0245 $0.0456 $0.0066 $0.0120

Direct metered cost Shared allocation (vector store + provisioned pool idle, metered share) Fully loaded ĉ(b) (Eq. 1)

$0.1912 $0.0210 $0.2122

The scenario shows the three answers the business asked for: a cost for this transaction, with provenance; the cost stated per order and per process, not per SKU; and a monthly tie-out to the invoice with a named residual.

X. A NALYTICAL E VALUATION Absent a field deployment, we evaluate the model analytically: coverage of R1–R7 against the alternatives an enterprise would actually consider (Table VII). Tags on billing data inherit settlement grain: they segment workloads and teams, never transaction instances, and cannot vary per request on token-metered SKUs (R2, R3, R7 unmet). FOCUS alone, including the announced 1.5 scope, achieves neutrality, economic fidelity, and reconcilability by design, and 1.5’s requester columns add identity grain [11]; but identity is not transaction (Section III), billing lags, and process language is absent (R2, R3, R7). Observability alone captures agentic structure and is timely, but carries no settlement truth: no negotiated rates, no amortization, no invoice tie-out — numbers finance cannot certify (R5, R6). Gateway alone meters what passes through it and prices it in near-real time, but misses what bypasses it, cannot see the invoice, and stops at workload grain unless it also solves correlation — at which point it has become the attribution ledger of this paper. The Two-Ledger Model meets all seven because it does not ask either dataset to do the other’s job: settlement truth stays in FOCUS; transaction truth stays in telemetry; the join, the rate card, and the reconciliation are the contributions. Threats to validity. This is an architectural argument supported by a simulation on synthetic data (Section XI), not a field study; absolute cost figures in Sections IX and XI are synthetic by design, and the simulation’s parameters are chosen rather than measured. Correlation quality at L3/L4 is workload-dependent and unbenchmarked here; the confidenceprovenance discipline bounds, but does not eliminate, misattribution. The rate card approximates settlement between closes; Eq. 7 measures exactly how well. Finally, two standards the model depends on are still in flux: FOCUS 1.5 is preratification [3], and the OpenTelemetry GenAI conventions carry Development status [4]; the model depends on their column and attribute roles, which are stable in direction, more than on their final names.

Out tok

$/Mtok (in; out)

1,100 2.00; 8.00 1,900 3.00; 15.00 1,400 1.25; 10.00 1,500 1.25; 10.00 2,600 2.00; 8.00 800 0.80; 3.20 — $0.004 / call × 3

XI. S IMULATION S TUDY All data in this section is synthetic and generated by the study’s own code; every usage record carries its true business transaction, so the measurements below are made against known ground truth. The study evaluates the mechanisms relative to one another under controlled conditions. It makes no claim about absolute cost levels in any production estate. A. Setup A generator produces 20,000 business transactions of three types (order-to-cash, procure-to-pay, claim-to-settlement) across seven systems of record, yielding 109,792 model invocations priced over four SKUs from three providers at the settled list rates of Table VI. Steps fail and retry with perstep probabilities of 1–12%; 5% of transactions are runaway, repeating one step a geometrically distributed number of times (mean nine). Instrumentation is controlled by ptrace (share of invocations carrying trace context), pproto = 0.5 (share of the remainder carrying A2A/MCP metadata), pevent (availability of business-event feeds for L3), a 5% key-collision rate, and a confidence floor below which L4 assignments are pooled. L4 scores a weighted similarity over temporal proximity with decay, tenant match, agent-stage plausibility, and lifetime containment; its score-to-confidence mapping is calibrated on a separate 4,000-transaction sample with known truth, in quantile bins with monotone precision, as Section V prescribes. The random seed is fixed. The code, the results, and every synthetic dataset are available [21], together with a script that rebuilds the reconciliation results from the data files alone. B. E1: Correlation Under Degraded Instrumentation Table VIII and Fig. 3 compare the spine with a traceonly baseline (what observability alone attributes) as ptrace falls from 1.0 to 0.0. The baseline’s coverage falls with it; the spine’s cost-weighted coverage stays above 99%. What degrades is accuracy: cost-weighted accuracy falls from 100% to 95.6% as assignment shifts to L3 and L4, and misattributed spend rises to 4.44% of the total. The second sweep shows what holds accuracy up: with trace context at 40%, removing the business-event feeds (pevent = 0) pushes misattribution to 14.21%, because L3 is the only deterministic mechanism that survives system-of-record boundaries. The third sweep

PREPRINT, NOVEMBER 2026

10

TABLE VII R EQUIREMENTS COVERAGE BY APPROACH (✓ MET, ∼ PARTIAL , × UNMET ).

R1 neutrality R2 txn grain R3 biz language R4 agentic completeness R5 economic fidelity R6 reconcilability R7 timeliness

Tags on billing

FOCUS 1.4+1.5

Observability only

Gateway only

TwoLedger

∼ × × × ∼ ✓ ×

✓ × × ∼ ✓ ✓ ×

∼ ∼ × ✓ × × ✓

∼ ∼ ∼ ∼ ∼ × ✓

✓ ✓ ✓ ✓ ✓ ✓ ✓

Percent

80 60 40 20

Trace-only coverage Spine cost coverage Spine cost accuracy

0

1.0 0.8 0.6 0.4 0.2 0.0 Share of invocations carrying trace context (ptrace)

Residual (% of bill)

100

Recovered residual Perfect recovery

6 4 2 0

0

2 4 6 Planted unmetered spend (% of bill)

Fig. 3. E1 — cost coverage and accuracy as trace propagation degrades (floor 0.80, pevent = 0.85).

Fig. 4. E2 — planted unmetered spend versus the residual the engine recovers from observable data.

shows the confidence floor as a dial between coverage and certifiability: raising it from 0.80 to 0.95 at ptrace = 0.4, pevent = 0.5 moves 15.6% of spend into explicit pools and takes misattribution from 7.57% to zero. That is the explicitdegradation discipline of Section V in numbers: a finance organization can choose a provable 100% accuracy on 84.4% of spend, with the rest pooled and labeled, rather than an unprovable 99.6%.

(from the contract) are removed. The two-sided check flags the overbilled SKU at exactly the planted amount with no false flags on other SKUs, and the omitted usage appears as a negative residual on its SKU — the provider billingdiscrepancy register of Section IV-E. The small under-recovery at higher shadow levels comes from provider rounding and from shadow usage that itself sits in the boundary window; both are visible in the decomposition rather than hidden.

C. E2: Reconciliation Recovers Planted Effects From Observable Data

D. E3: Mid-Flight Gating Against Runaway Transactions

The reconciliation engine sees only what it would see in practice: the attribution ledger (metered records with quantities and rate-card estimates), a FOCUS-style billing export with per-SKU, per-day billed quantities and cost, the settled price sheet, and the commitment contract for a provisioned pool. Into the bill the study plants: unmetered consumption of 0–8% of metered usage (shadow AI), boundary-timing shifts (half of the usage in the last six hours billed in the next period), provider rounding of quantities, a 15%-idle provisioned-throughput commitment, a 3% price overbilling on one SKU, and a 2% omission of usage on another. Table IX and Fig. 4 report the decomposition of Section VIII. The unmetered residual recovers the planted shadow spend within 0.24 percentage points of the bill across all levels, after rate drift (restatement at the price sheet), timing (last-day quantity reappearing on day one of the next period), and idle

The forecaster of Section IV-E is fitted on 12,000 separate training trajectories, with the cost objective per type set at the 95th percentile of non-runaway training cost. Table X and Fig. 5 report, for gate thresholds θ, the cost distribution of the 20,000 test transactions when a transaction is paused after the call at which the forecast breach probability exceeds θ. Ungated, p99 cost per transaction is $0.701 against a p95 of $0.243 — the runaway tail. At θ = 0.5 the gate cuts p99 by 61% and total spend by 9.3%, catching 74% of runaways, at the price of pausing 4.1% of transactions that would have finished within budget; at θ = 0.9 the cut is 49% with a 2.0% false-pause rate. Thresholds 0.9 and 0.95 give identical results because the forecaster’s bin-wise estimates jump from 0.81 to 1.0 at the top accumulated-spend bin, so no gating decision changes between them; a finer forecaster would separate them. The p95 moves little, as expected: it is set by normal transactions, which the gate leaves alone. The

PREPRINT, NOVEMBER 2026

11

TABLE VIII E1 — CORRELATION COVERAGE AND ACCURACY ( COST- WEIGHTED ) VERSUS INSTRUMENTATION . T RACE - ONLY COVERAGE IS THE SHARE ATTRIBUTABLE BY TRACE CONTEXT ALONE . P OOLED : SPEND ASSIGNED TO EXPLICIT POOLS . M ISATTRIB .: SPEND ASSIGNED TO THE WRONG TRANSACTION . pproto = 0.5, 5% KEY COLLISIONS THROUGHOUT. ptrace

pevent

Floor

Trace-only cov.

Spine cost cov.

Cost acc.

Pooled

L4 share

Misattrib.

1.0 0.8 0.6 0.4 0.2 0.0 0.4 0.4 0.4 0.4 0.4 0.4

0.85 0.85 0.85 0.85 0.85 0.85 1.00 0.50 0.00 0.50 0.50 0.50

0.80 0.80 0.80 0.80 0.80 0.80 0.80 0.80 0.80 0.85 0.90 0.95

100.0% 80.1% 60.2% 39.8% 20.2% 0.0% 40.0% 40.1% 40.2% 40.0% 40.0% 39.8%

100.0% 100.0% 99.9% 99.9% 99.8% 99.8% 100.0% 99.6% 99.3% 98.7% 97.7% 84.4%

100.0% 99.1% 98.2% 97.4% 96.4% 95.6% 99.3% 92.4% 85.7% 93.0% 93.4% 100.0%

0.0% 0.0% 0.1% 0.1% 0.2% 0.2% 0.0% 0.4% 0.7% 1.3% 2.3% 15.6%

0.0% 2.6% 5.2% 7.8% 10.6% 13.1% 4.1% 16.9% 29.4% 15.8% 15.1% 0.0%

0.00% 0.89% 1.76% 2.62% 3.59% 4.44% 0.69% 7.57% 14.21% 6.96% 6.47% 0.00%

TABLE IX E2 — RECONCILIATION ON OBSERVABLE DATA . R ECOVERED RESIDUAL VERSUS PLANTED UNMETERED SPEND ( BOTH AS % OF THE BILL ); DECOMPOSITION COMPONENTS ; TWO - SIDED DETECTION OF A PLANTED 3% PRICE OVERBILLING AND A 2% USAGE OMISSION (USD, ONE SYNTHETIC MONTH ). Recovered residual

Error (pp)

Rate drift

Timing

Overbilling flagged / planted

Under-billing residual / planted

0.00% 0.87% 1.73% 3.40% 6.56%

-0.00% 0.84% 1.67% 3.28% 6.33%

0.00 0.03 0.06 0.12 0.23

-1.19% +1.28% +0.61% -0.23% +0.43%

0.40% 0.38% 0.36% 0.30% 0.17%

$16.89 / $16.89 $17.06 / $17.06 $17.23 / $17.23 $17.57 / $17.57 $18.24 / $18.24

$-2.95 / $-2.94 $-2.98 / $-2.97 $-3.01 / $-3.00 $-3.18 / $-3.06 $-3.50 / $-3.18

p95 cost (USD)

0.25 0.20

p95 cost per transaction False-positive rate (%)

4 3

0.15 2 0.10 1

0.05 0.00

False-positive rate (%)

Planted unmetered

0 0.7 0.9 ungated 0.5 Gate threshold θ

0.95

Fig. 5. E3 — p95 cost per transaction and false-pause rate by gate threshold.

threshold is therefore a policy choice between tail protection and approval friction, and the study reports both sides of it. E. What the Study Shows and Does Not Show It shows that the mechanisms behave as the architecture claims under controlled conditions: the spine trades accuracy, not coverage, as instrumentation degrades, and the confidence floor converts that trade into an explicit, labeled pool; the residual is recoverable from data a FinOps team already holds, in both directions; and forecast-based gating bounds the tail at a measurable approval cost. It does not show production magnitudes. The generator’s parameters — collision rates, feed availability, runaway frequency, provider rounding — are

chosen, not measured, and a field pilot remains the next step (Section XIII). XII. R EALIZATION : P RODUCT, A SSEMBLY, AND A B EST- OF -B REED E XEMPLAR The architecture of Section IV raises the question every adopting enterprise and every product strategist asks next: must someone build this as a product, or do customers assemble it from what they already own? The answer is that the contracts make both possible; that is what designing to FOCUS, OpenTelemetry GenAI, and W3C Trace Context buys. The economics then decide where a product earns its place. This section examines three sourcing models, then grounds them in an illustrative best-of-breed mapping of the eight components onto the October 2026 market. A. Three Sourcing Models Table XI compares the realizations. Self-assembly has the enterprise platform team build the join on its own lakehouse; it suits organizations with mature FinOps and data platforms, and its hidden cost is permanent: someone must maintain the rate card and the correlation engines forever. A delivered accelerator has an integrator implement the reference architecture as code the enterprise then owns; it buys the architecture without a new vendor, at project cost and with ownership transferring at handover. A productized join layer ships components 5 and 7 — the only two the market does not sell (Section X) — as software deployed in the customer’s account, writing the attribution ledger to the customer’s lakehouse, read-only to billing, with every adjacent component bring-your-own.

PREPRINT, NOVEMBER 2026

12

TABLE X E3 — MID - FLIGHT GATING . C OST PER TRANSACTION (USD) AND GATING OUTCOMES BY THRESHOLD θ; 5% OF TEST TRANSACTIONS ARE RUNAWAY. Gate threshold θ

p95 cost

p99 cost

Mean cost

Spend saved

False-positive rate

Runaways caught

ungated 0.5 0.7 0.9 0.95

$0.243 $0.220 $0.224 $0.229 $0.229

$0.701 $0.276 $0.307 $0.358 $0.358

$0.1581 $0.1435 $0.1467 $0.1484 $0.1484

0.0% 9.3% 7.2% 6.2% 6.2%

0.00% 4.12% 3.69% 1.97% 1.97%

0.0% 74.4% 74.4% 72.0% 72.0%

Its adoption logic for customers with existing investments is simple: nothing already owned is replaced, and the first deliverable (the reconciliation and shadow-AI report) requires only data the customer already has. Because all three models exchange the same records in the same open formats, an enterprise can start in one and move to another; the deciding variables are who carries the rate-card maintenance burden and who certifies correlation confidence to finance. B. A Best-of-Breed Exemplar Table XII maps each component onto illustrative market realizations as of October 2026, drawn from practitioner tool surveys and vendor documentation [22]–[25]. The mapping is point-in-time and illustrative, not an evaluation or endorsement; two of the surveyed sources are vendor-published, and the table should be re-verified at reading time. The analytical point stands despite those caveats: seven of the eight components are available as products or commodity infrastructure, assembled across at least four distinct vendor categories, while component 5 has no standalone vendor and component 7 has none at all — which is exactly where Table VII’s coverage gaps lie. C. The Strongest Edge Still Stops at the Ledger Boundary The pattern is sharpest in the most complete metering stacks. MuleSoft’s Omni Gateway (the former Flex Gateway), with Agent Fabric, spans LLM routing and token limits, prompt guardrails and PII detection, OpenAPI-to-MCP conversion, end-to-end correlation identifiers, consumption telemetry, and an agent registry, broker, and visualizer with A2A and MCP support [24], [25]. In this paper’s terms that is a strong component 1, parts of 2 and 6, and the enforcement actuator of 8 — and, because the surrounding integration platform already connects the systems of record, a natural emitter of the spine’s L3 business events. Yet its public materials describe FinOps only as a consumer of its telemetry: no invoice ingestion, no rate card, no FOCUS dataset, no reconciliation [24]. The most capable edge on the market still stops at the ledger boundary. That boundary is not a vendor oversight. It is the grain mismatch of Section III, and crossing it is the job of components 5 and 7 — the productizable core. XIII. D ISCUSSION Governance integration. Transaction-grain cost turns AI governance from policy into arithmetic. Budget gates become executable: an agent, workflow, or process carries a cost SLO (c95 per outcome type), enforced at the gateway, with

breaches routed through the same lifecycle gates that govern capability and risk — the Govern and Gate stages of an agentic governance maturity progression [26]. Coordination overhead (Eq. 5) prices multi-agent deliberation itself, making consensus mechanisms a cost-benefit decision rather than an architectural default [20]. The reconciliation residual makes shadow-AI detection a monthly close activity, owned jointly by finance and the AI platform team. Agent identity and settlement-native attribution. FOCUS 1.5’s requester columns call for a stable, enterprise-wide agent identity scheme used identically in both ledgers — the same PrincipalId in the gateway record and, where providers support it, in the billing row. Looking further out, verifiable agent identity with agent-held credentials and payment instruments [27] points to a settlement-native future in which the agent’s own transaction record is the attribution row; the TwoLedger join is the bridge architecture until then. Standardization outlook. The attribution ledger published as FOCUS-shaped, invocation-grain rows with x_ business keys (Section IV) is deliberately also a proposal: it shows, in the specification’s own extension mechanism, what an invocation-grain usage profile of FOCUS would look like. We intend to contribute the mapping of Table III to the FOCUS and OpenTelemetry GenAI working groups as alignment input, so that the columns finance trusts and the attributes engineering emits converge on one vocabulary for AI consumption. Limitations and future work. The immediate next step is a field pilot measuring attribution coverage, correlation precision at each spine level, and reconciliation variance over several closes — the empirical validation this paper does not claim. Further work includes correlation benchmarks for L4 matching, treatment of fine-tuning and inference-adjacent costs (embedding refresh, evaluation runs) as transactionamortizable overhead, and re-validation of the FOCUS 1.5 and OpenTelemetry mappings at ratification. XIV. C ONCLUSION Businesses account for work in transactions and outcomes. AI providers bill in SKUs and periods. In three years, FOCUS has given the bill one shape across clouds, SaaS, and AI vendors, and its forthcoming AI scope will name models, tokens, and even agents inside billing data. One thing no billing standard can contain is the enterprise’s own transaction boundary — the order, the claim, the case — because the provider never sees it. We have argued that this makes transaction-grain AI cost a sub-ledger problem. Keep settlement truth in a FOCUS ledger. Capture transaction truth in an invocation-grain attribution ledger at the gateway. Correlate

PREPRINT, NOVEMBER 2026

13

TABLE XI S OURCING MODELS FOR REALIZING THE T WO -L EDGER M ODEL . Self-assembly

Delivered accelerator

Productized join layer

Who builds components 5 and 7

Enterprise platform team, on the existing lakehouse

Vendor product, deployed in the customer’s account and lakehouse

Time to first value

Quarters

Integrator, from a reference implementation; enterprise owns it after handover About a quarter

Cost shape

Internal engineering plus a permanent Project cost; maintenance transfers to rate-card and engine maintenance bur- the enterprise den None, but schema-drift risk against Low; open formats throughout evolving standards

Lock-in surface Best fit

Large platform organizations with Enterprises wanting the architecture FinOps and data maturity without a new vendor relationship

Weeks: reconciliation and shadow-AI report from existing billing and gateway data, before any instrumentation Subscription, priced on attributed spend or metered transactions; vendor maintains the rate card Bounded by the contracts: FOCUS and OTel GenAI in, FOCUS-shaped rows and gate decisions out Multi-cloud, multi-gateway estates needing finance-grade tie-out and a maintained price book

TABLE XII I LLUSTRATIVE BEST- OF - BREED REALIZATION OF THE EIGHT COMPONENTS ( MARKET SNAPSHOT, O CTOBER 2026; EXAMPLES , NOT ENDORSEMENTS ) [22]–[25]. Component

Exemplar realizations

1 LLM gateway

MuleSoft Omni Gateway; Kong AI Gateway; LiteLLM; Portkey; provider-native endpoints

What they cover

What remains outside

Token capture and limits, guardrails, MCP/A2A policy, identity propagation, correlation identifiers 2 Backfill emitters OpenTelemetry GenAI SDKs and Collector; Paths no proxy sees (embedded & pollers provider usage and billing APIs copilots, provider-managed agents, batch) 3 Attribution ledger Iceberg/Delta tables on Databricks, Snowflake, Durable, queryable invocation-grain or BigQuery store 4 Settlement lake Apptio, CloudZero, Vantage, Finout; Microsoft FOCUS ingestion, invoices, reconcilFinOps toolkit iation to cash 5 Rate card service — (build; gateway price maps seed it) —

6 Taxonomy identity registry

& Entra ID / Okta / SPIFFE; Purview / Collibra / DataHub; APQC PCF content [16]

7 Correlation, allo- — (the white space); partial pieces: unit-cost incation, reconciliation strumentation, virtual tagging, invoice-ingesting observability 8 Unit economics & Unit-cost analytics; BI semantic layers; OPAgates class policy; gateway budget enforcement

across systems of record through a layered spine with explicit provenance. Price through a versioned rate card. Report the result in the process language the business already uses, and reconcile the two ledgers every close, letting the residual name the shadow AI. Under simulation with known ground truth, the join keeps cost coverage above 99% where tracing alone collapses, recovers planted unmetered spend within 0.24 percentage points, and bounds the runaway tail at a measurable approval cost. The bill says what the enterprise spent. The trace says why. The join answers the question the business asked. ACKNOWLEDGMENT AND AI-U SE D ISCLOSURE Generative AI assistance (Anthropic Claude) was used for literature synthesis, drafting, simulation and figure code, and LaTeX preparation under the author’s direction. The author reviewed, edited, and takes full responsibility for all content;

Prices, invoices, and anything that bypasses the proxy Lower confidence than gateway metering, by construction

The FOCUS-shaped x_ profile is a schema discipline, not a product Runtime usage and the transaction boundary Negotiated rates, commitment amortization, and tier logic have no standalone vendor; the FOCUS 1.5 price sheet will anchor, not replace, it Workload and agent identity, cata- One key schema across traces, logs, process codes tags, and gateway metadata is governance work, not a purchase Fragments on one side of the grain The trace-to-invoice join at gap or the other transaction grain, with confidence provenance and a decomposed ∆ Analytics and enforcement actuators The closed loop from c95 breach to gate decision

all references were verified by the author against their primary sources prior to submission. R EFERENCES [1] FinOps Open Cost and Usage Specification, “FOCUS Specification v1.0,” CC-BY-4.0, a Linux Foundation project series. [Online]. Available: https://focus.finops.org/docs/specification/v1-0/ (accessed Oct. 24, 2026). [2] FinOps Foundation, “FOCUS Specification,” FinOps Open Cost and Usage Specification project, Linux Foundation. [Online]. Available: https://focus.finops.org/focus-specification/ (accessed Oct. 24, 2026). [3] AISpendOps, “FOCUS 1.5 will add AI token columns. Here is what they need to get right,” Sep. 2026. [Online]. Available: https://www. aispendops.com/blog/focus-1-5-ai-token-columns [4] OpenTelemetry, “Semantic conventions for generative AI systems,” OpenTelemetry Semantic Conventions (status: Development). [Online]. Available: https://opentelemetry.io/docs/specs/semconv/gen- ai/ (accessed Oct. 24, 2026). [5] Anthropic, “Introducing the Model Context Protocol,” Nov. 2024. [Online]. Available: https://www.anthropic.com/news/model- contextprotocol

PREPRINT, NOVEMBER 2026

[6] The Linux Foundation, “Linux Foundation launches the Agent2Agent protocol project to enable secure, intelligent communication between AI agents,” press release, Jun. 23, 2025. [Online]. Available: https:// linuxfoundation.org/press/linux- foundation- launches- the- agent2agentprotocol-project-to-enable-secure-intelligent-communication-betweenai-agents [7] A2A Project, “Agent2Agent (A2A) protocol specification,” v1.0.0, Linux Foundation. [Online]. Available: https://a2a- protocol.org/latest/ specification/ (accessed Oct. 24, 2026). [8] SD Times, “FinOps Foundation releases FOCUS 1.3 to address issues related to splitting shared resource costs,” Dec. 2025. [Online]. Available: https://sdtimes.com/finops/finops-foundation-releases-focus-1-3to-address-issues-related-to-splitting-shared-resource-costs/ [9] FinOps Foundation, “FOCUS for AI,” FOCUS technology categories. [Online]. Available: https : / / focus . finops . org / technology - categories / focus-for-ai/ (accessed Oct. 24, 2026). [10] Glassity, “Token counts in FOCUS 1.4 without waiting for 1.5,” 2026. [Online]. Available: https://glassity.cloud/blog/ai-token-counts-focus-14/ [11] Token Economics, “What FOCUS 1.5 does for AI cost, and what it does not,” Oct. 2026. [Online]. Available: https://www.tokeneconomics.com/ projects/what-1-5-does-for-ai-cost-and-what-it-does-not/ [12] W3C, “Trace Context,” W3C Recommendation, Feb. 6, 2020. [Online]. Available: https://www.w3.org/TR/trace-context/ [13] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “ReAct: Synergizing reasoning and acting in language models,” in Proc. Int. Conf. Learning Representations (ICLR), 2023. arXiv:2210.03629. [14] Q. Wu et al., “AutoGen: Enabling next-gen LLM applications via multiagent conversation,” arXiv:2308.08155, 2023. [15] S. Prakash, “Agent Identity Protocol (AIP): Verifiable delegation for AI agent systems,” IETF Internet-Draft draft-prakash-aip-02 (work in progress), Oct. 2026. [Online]. Available: https://datatracker.ietf.org/ doc/draft-prakash-aip/ [16] APQC, “Process Classification Framework (PCF) — Cross Industry.” [Online]. Available: https://www.apqc.org/process- frameworks (accessed Oct. 24, 2026). [17] Object Management Group, “Business Process Model and Notation (BPMN), Version 2.0,” OMG Document formal/2011-01-03, Jan. 2011. [18] Microsoft, “Managing Azure OpenAI costs with the FinOps toolkit and FOCUS: Turning tokens into unit economics,” Microsoft Tech Community, FinOps Blog, 2025. [Online]. Available: https://techcommunity. microsoft.com/blog/finopsblog/managing-azure-openai-costs-with-thefinops-toolkit-and-focus-turning-tokens-int/4413886 [19] Microsoft, “Who ordered all these tokens? Giving AI spend a name in FOCUS,” Microsoft Tech Community, FinOps Blog, 2026. [Online]. Available: https://techcommunity.microsoft.com/blog/finopsblog/whoordered-all-these-tokens-giving-ai-spend-a-name-in-focus/4547978 [20] V. Acharya, “Semantic Consensus: Process-Aware Conflict Detection and Resolution for Enterprise Multi-Agent LLM Systems,” arXiv:2604.16339, 2026. [21] V. Acharya, “Two-Ledger Model: Simulation code and synthetic data,” GitHub repository, v1.0.0, 2026. [Online]. Available: https://github.com/ curiosityexplorer/two-ledger-model [22] SuperPenguin, “Best LLM cost tracking tools in 2026: Gateways, observability, and cost management,” 2026. [Online]. Available: https: //superpenguin.ai/blog/best-llm-cost-tracking-tools (vendor-published; accessed Oct. 24, 2026). [23] Holori, “Top 10 AI cost visibility tools in 2026,” 2026. [Online]. Available: https://holori.com/top- 10- ai- cost- visibility- tools- in- 2026/ (vendor-published; accessed Oct. 24, 2026). [24] The Futurum Group, “MuleSoft Omni Gateway: As close to an agent control plane as it gets,” May 2026. [Online]. Available: https : / / futurumgroup.com/insights/mulesoft- omni- gateway- as- close- to- anagent-control-plane-as-it-gets/ [25] MuleSoft, “Agent Fabric,” MuleSoft Documentation. [Online]. Available: https://docs.mulesoft.com/agent-fabric/ (accessed Oct. 24, 2026). [26] V. Acharya, “Governing the Agentic Enterprise: A Governance Maturity Model for Managing AI Agent Sprawl in Business Operations,” arXiv:2604.16338, 2026. [27] V. Acharya, “Decentralized identity and payment methods for autonomous agents,” U.S. Patent Application No. 19/376,988, U.S. Patent and Trademark Office.

14

Related documents

• But How Would AI Agents Run a Town's Economy?#998663
• Authority-Inference Separation in Agentic Finance: First-Line Control, Blockchain Enforcement, and Replayable Assurance#799712
• The Equilibrium Ledger Lexicon: A Descent into Logos#693689
• Cloud Broker: A Systematic Mapping Study#180486
• Cloud Broker: A Systematic Mapping Study#179624