Organize your token accounting in a single ledger
Request a demo with Formance to organize your token accounting, prepaid commits, and marketplace reconciliation in a single ledger.
The frontier AI labs have started admitting the problem out loud. In January 2026, Investing.com reported, citing The Information, that Anthropic now projects roughly a 40% gross profit margin in 2025, 10 percentage points below its previous internal estimate, because inference costs on third-party cloud infrastructure from Google and Amazon climbed about 23% higher than anticipated.
Those inference costs did not appear in any billing platform in real time. They appeared in a reforecast. Traditional billing systems meter what customers are charged and have no native concept of the cost of serving a token. AI finance leads have begun publicly describing this problem as unsolved.
A 10-point margin miss that only surfaces in a reforecast is a metering failure. Token accounting is the fix. Token accounting is the practice of posting the revenue and the serving cost of every AI request to the same ledger, on shared customer, model, and feature dimensions, at request time, so gross margin per token becomes a live balance query instead of a monthly reconstruction.
This article covers why AI margins shift faster than billing systems can track, and how a dual-balance ledger makes per-customer, per-model margin a live query.
AI margins are dynamic because the price you charge per token and the cost to serve it move independently, on different schedules. A margin model built on a blended per-token rate breaks the moment traffic mix shifts across models, cache states, or batch modes.
Seven dimensions change token cost across major providers: model, token direction, cache state, batch mode, service tier, region, and sales channel.
Output tokens cost around 5x as much as input tokens on major frontier models. Claude Sonnet 5 costs $2.00/$10.00 per million tokens (introductory pricing through August 31, 2026, with new standard pricing of $3.00/$15.00 beginning September 1), and Claude Haiku 4.5 costs $1.00/$5.00 per million tokens, a clean 5x ratio in both cases.
Cache reads run at ~0.1x standard input pricing because prompt caching reduces cached input cost by 90%, while cache writes carry a 1.25x–2x premium over standard input pricing, depending on cache TTL.
Batch processing cuts both input and output prices roughly in half compared to synchronous API pricing, with non-time-critical requests running at a 50% discount on standard token rates.
Fast-processing tiers, priority tiers, and regional processing each change the effective price of the same workload.
Effective per-token pricing spans roughly 50x once the seven dimensions are stacked together.
To anchor the ratio in dollars: a cached input token on Claude Sonnet 4.6 runs at roughly $0.30 per million tokens (10% of the $3.00 standard input rate), while a standard output token on the same model costs $15.00 per million, which is a 50x spread inside a single model family before batch, tier, or channel discounts stack on top.
Widen the comparison to a cached input token on Claude Haiku 4.5 (~$0.10/M) against a Sonnet 4.6 output token ($15.00/M), and the ratio blows out past 150x. Published OpenAI direct API and Anthropic direct API pricing varies sharply across model class, token direction, cache state, batch mode, and service tier.
A low-cost cached input token on a small model and a standard output token on a frontier model are not economically comparable units. Two engineering teams at the same company, on the same provider, making different choices about caching, batching, and service tier can run effective per-token costs that differ by ~50x.
The cost of serving swings varies with hardware generation and load, so a cost model built on last year's fleet is off by an order of magnitude within a year.
Load also moves cost per million tokens sharply. A GPU running at low load makes effective cost per token much higher, while continuous batching with vLLM or SGLang increases utilization and improves throughput on hardware you already own.
Effective cost per million tokens can swing by more than an order of magnitude between low-QPS operation and saturated serving on the same model and hardware. Combined with the Anthropic reforecast above, the pattern is clear: cost-side volatility can move gross margin by double-digit points inside a single quarter.
Given seven price dimensions on the sell side and hardware-plus-load volatility on the cost side, the question shifts from "How do we price tokens" to "Can our billing stack even see the cost side of a token in the first place?"
The standard stack cannot answer per-customer, per-hour, per-model margin because revenue events live in the billing platform, aggregate cost lives in vendor invoices, and monthly summaries land in the general ledger, with no native join key connecting the three at the customer-hour-model grain.
Billing platforms meter what you charge and not what it costs to serve. Usage-based billing systems are designed around revenue-side events such as tokens billed and calls rated, and they track credit drawdown on the revenue side.
Cost-side events sit outside the priced event, while customer charges remain a separate artifact. For spiky agent workloads, delayed rollups allow hardware costs to accrue before the next aggregate lands.
The general ledger consumes monthly summaries and cannot decompose costs into per-customer, per-model, per-hour. Your general ledger receives period-close journal entries: a monthly cost of goods sold (COGS) aggregate.
Standardized billing and usage data helps finance teams allocate cloud and SaaS costs, but a general ledger (GL) summary remains too coarse for live product-margin decisions. As inference becomes a material share of revenue for scaling AI companies, a COGS line visible only monthly hides the 10-point margin swings Anthropic just reported.
Warehouses store events but cannot enforce financial posting guards at write time. Analytical tables like Snowflake or BigQuery do not prevent double posting or concurrent drawdowns from overspending a balance, and deduplication mechanisms only clean up after the fact rather than making the insert itself atomic.
Prepaid drawdowns make this worse. Without a write-time materialized balance, "current prepaid balance" means summing an account's rows on the query path, and a full-history balance scan gets slower every day you keep posting. Warehouses are the right place to analyze the ledger; a core ledger is the system that enforces postings.
The fix is a ledger that atomically posts revenue and costs on shared dimensions. This is the dual-balance model. Formance Ledger closes the architectural gap within token accounting by posting revenue and cost atomically, with prepaid drawdown in the same transaction so margin can be queried at the customer, model, or hour.
The dual-balance model posts revenue and serving cost as two legs of a single atomic transaction on accounts with the same customer, model, and feature dimensions, so margin becomes a balance difference rather than a reconciliation project.
Double-entry accounting must be enforced programmatically by the ledger to ensure transaction postings remain balanced. Every transaction's postings sum to zero, and multiple send statements in one script commit as one atomic transaction.
Every billable event posts revenue and the cost of serving in a single atomic transaction to accounts that share the customer, model, and feature dimensions.
One transaction carries both legs, with the hour attached via Metadata (arbitrary context on any transaction or account), or neither leg posts. The multi-segment account namespace gives you the dimensional hierarchy directly.
In Numscript, Formance's ledger-native scripting language, the dual-balance model looks like this.
Suppose customer Acme consumed tokens priced at $12,400.00 during the 14:00 hour on Claude Sonnet 4.6, and the serving cost for that traffic was $4,180.00.
Acme's prepaid balance sits at @customers:acme:prepaid, revenue posts to @platform:revenue:customers:acme:models:sonnet_4_6:features:summarize, and cost posts to @platform:cogs:customers:acme:models:sonnet_4_6:features:summarize.
A single script execution posts both legs atomically, and Formance Ledger's querying and aggregation APIs aggregate slices of that hierarchy, such as one customer across all accounts or one account type across all customers:
// TOKEN_USAGE_ACCOUNTING
// Event: Acme consumes tokens; revenue drawdown and serving cost post together
send [USD/2 1240000] (
source = @customers:acme:prepaid
destination = @platform:revenue:customers:acme:models:sonnet_4_6:features:summarize
)
send [USD/2 418000] (
source = @counterparties:aiProviders:anthropic allowing unbounded overdraft
destination = @platform:cogs:customers:acme:models:sonnet_4_6:features:summarize
)
set_tx_meta("event_type", "token_usage_accounting")
set_tx_meta("usage_id", "use001")
set_tx_meta("customer_id", "acme")
set_tx_meta("model_id", "sonnet_4_6")
set_tx_meta("feature", "summarize")
set_tx_meta("usage_hour", "2026-07-27T14")The Numscript relies on three invariants:
Atomic posting keeps serving cost tied to the same financial state as revenue recognition and prepaid balance movement.
The customer's prepaid balance is drawn down within the same atomic transaction that posts revenue and costs.
Revenue is sourced from @customers:acme:prepaid, so recognition and drawdown share a single ledger posting, and the core ledger is concurrency-safe, so concurrent postings execute without a check-then-act balance update in application code.
Gross margin becomes a single balance-aggregation query at the customer, model, feature, or hour grain.
Gross margin for Acme is the aggregate balance of @platform:revenue:customers:acme:* minus @platform:cogs:customers:acme:*, expressed as a balance aggregation query.
Filter by usage_hour metadata or scope the wildcard differently, and the same query answers margin per model, per feature, or per hour. Bi-temporality, which tracks both when an event was recorded and when it was effective, lets you ask what the books looked like on any past date without running a close.
Teams that skip atomic posting experience revenue-cost drift no one can explain, and manual reconciliation work that grows every quarter.
The dual-balance model handles the request-time posting. Two AI-specific contract shapes further stress this: prepaid commits and marketplace channel remittances.
Enterprise AI contracts operate on three mechanics: a committed spend floor (a guaranteed minimum), a prepaid balance drawn down against usage, and a periodic true-up in which the customer owes any shortfall below the floor. Provider credit terms add expiry on top.
Subscription engines model a recurring fixed charge against a time period. A commit contract needs something different: a live balance decremented per event at contract rates, a floor enforced at term end, and an overage rate applied separately once the balance hits zero. Even vendors adding prepaid-commitment features still require a dedicated ledger for the drawdown itself.
In the dual-balance model, the commit is a single posting into @customers:acme:prepaid at signing. Every billable event drains the account. True-up is a balance read at period end, and breakage sweeps to a breakage account with one more posting.
Prepaid commits handle the customer-facing contract. Cloud marketplaces introduce a second reconciliation problem on the disbursement side.
Marketplace remittances arrive late, netted, and without shared join keys, so tying them back to per-token usage requires carrying the join keys on the postings themselves and running policy-based matching between internal postings and external statements. Here's how the mechanics break, and how the ledger plus a reconciliation module fix it.
Cloud marketplace revenue arrives as an aggregated wholesale remittance weeks after the usage, net of listing fees, and tying the remittance back to your per-customer token metering is entirely your job.
On AWS Marketplace, sellers submit usage hourly through the BatchMeterUsage API, disbursements arrive only after collection from the customer, and revenue reports arrive net: gross revenue, listing fee, and seller net revenue, keyed by transaction and disbursement identifiers. Azure runs slower still for some usage-based products, and if the customer never pays, Microsoft can recoup the payout from future disbursements.
Carry the marketplace transaction reference ID and the disburse bank trace ID on the postings themselves, so a remittance can be matched back to the exact metered postings that produced it. If your token metering already lives in a core ledger, the join keys live there too.
The Formance Reconciliation module applies policy-based matching rules to reconcile internal postings with external statements. It covers:
Ingestion is source-agnostic across banks, digital asset rails, and PSPs.
With request-time posting, prepaid commits, and marketplace remittances all landing in the same ledger, margin stops being a monthly reconstruction.
Token accounting gives you customer-hour-model margin as a balance query instead of a quarter-late reconstruction. GitHub Copilot reportedly lost an average of $20+ per user per month in 2023 because no billing system was posting that cost signal in real time.
When the billing platform and vendor invoice only meet in a monthly journal entry, margin becomes a reconstruction project that finishes a quarter after the money moved. When both legs and the drawdown post in one Numscript transaction on the ledger, the metering layer becomes your system of record for margin.