Your application telemetry says the month cost $47,820. The provider invoice says $51,406. Which number should product use for customer margin, and which number should engineering use to investigate the change?
The answer is both, with different jobs. Request telemetry is operational evidence. The provider bill is financial evidence. LLM cost reconciliation connects them, explains the residual, and prevents a precise-looking estimate from becoming false unit economics.
Reconciliation turns fragmented request evidence into a financial total that can support allocation, margin, and verified savings decisions.
What is LLM cost reconciliation?
LLM cost reconciliation is the process of comparing request-level usage and calculated cost with a provider's billing evidence, classifying every difference, and allocating the reconciled total back to the business activity that caused it.
A complete reconciliation preserves three separate values:
| Value | Source | Best use |
|---|---|---|
| Provider-reported usage | Model response, usage API, or runtime telemetry | Engineering diagnosis and request attribution |
| Calculated cost | Usage quantities multiplied by an effective price rule | Near-real-time estimates and scenario analysis |
| Reconciled billed cost | Provider cost report, billing export, or invoice | Finance, margin, chargeback, and realized savings |
Do not overwrite one with another. If the bill changes after a late adjustment, you still need the original request evidence to explain which workload should absorb the difference.
Why telemetry and the bill diverge
The simple formula tokens × public list price assumes every billable unit appears in the response, every request uses the expected model and tier, and the public rate card matches the commercial agreement. Real systems break those assumptions in predictable ways.
Token classes are not interchangeable
Providers can price uncached input, cache reads, cache writes, output, reasoning, audio, images, grounding, search, and code execution differently. The official OpenAI pricing page, Anthropic pricing documentation, and Google Gemini API pricing all separate at least some of these dimensions.
Flattening them into one total_tokens field loses the information required to reproduce the charge. Keep each raw quantity and the normalized category it maps to.
Service tier and execution mode change the rate
Batch, standard, priority, flex, regional inference, and committed capacity can change the economic treatment of the same model. Anthropic, for example, exposes service-tier data in usage reporting but notes that Priority Tier uses a different billing model and is not included in its Cost API. Its Usage and Cost API documentation tells customers to track that usage separately.
A pricing key therefore needs more than provider and model:
provider + model/version + service tier + region + modality + token class + effective date + contract
The request stream is not the complete bill
Some charges do not map cleanly to one synchronous model response. Examples include tools, web search, code execution, asynchronous jobs, provisioned throughput, reserved GPUs, minimum commitments, platform fees, and marketplace billing.
Anthropic's cost report includes service-level categories such as web search and code execution, while its usage endpoint is focused on message usage. Google Cloud's detailed billing export schema similarly carries billing dimensions and adjustments that application traces do not reproduce by themselves.
Time and identity boundaries differ
Your telemetry may use UTC event time while the provider closes a billing bucket on another boundary. A streaming request can start in one bucket and finish in the next. Late events, corrected usage, credits, and refunds can revise a previously stable total.
Identity can be lossy too. A provider cost report may group by organization, project, workspace, or API key. Your application may need customer, feature, workflow, agent, and outcome. Reconciliation connects these layers, but it cannot invent context that was never recorded.
A repeatable reconciliation method
The goal is not to force the first comparison to zero. The goal is to make the residual explainable, bounded, and smaller over time.
1. Freeze the comparison window
Choose one provider, currency, commercial account, and closed time range. Record the timezone and the freshness timestamp for every source.
Do not treat provisional data as invoice-grade. Anthropic's Enterprise Analytics documentation, for example, says cost and usage values may be revised as late events arrive and recommends querying sufficiently old periods for stable invoicing totals. Apply the provider's own freshness contract before comparing numbers.
2. Preserve raw provider dimensions
Ingest request identifiers, model identifiers, token classes, tools, service tier, region, project or workspace, API key ID, timestamps, and provider-reported cost when it exists. Normalize the fields for cross-provider analysis, but keep the originals next to them.
OpenTelemetry's generative AI semantic conventions provide a useful common vocabulary for model operations and usage. They are a telemetry foundation, not a billing ledger. Add pricing-rule and billing-source provenance explicitly.
3. Reproduce the estimate with a versioned price rule
For each usage record, store the rule that converted usage into money:
| Field | Example |
|---|---|
| Pricing source | Provider public rate card |
| Effective interval | 2026-08-01 through 2026-08-31 |
| Match dimensions | Provider, model, tier, region, token class |
| Quantity | 8,400,000 cached input tokens |
| Unit rate | Contract or list rate per million |
| Calculated amount | Decimal currency value |
Use decimal arithmetic or integer currency micros. Binary floating point can introduce its own residual at large scale.
4. Compare at the narrowest shared grain
Start with the dimensions both sources actually share. A useful matching order is:
- provider account and billing period
- project, workspace, or API key
- model and service tier
- region or inference geography
- usage class
- smaller time bucket
Do not begin with customer or feature if those dimensions exist only in application telemetry. Reconcile the provider total first, then allocate the reconciled amount through your business mappings.
5. Classify the residual
Use a controlled variance taxonomy instead of a free-text note:
| Variance class | Typical evidence | Corrective action |
|---|---|---|
| Missing telemetry | Bill exists without matching requests | Find an uninstrumented SDK, gateway, batch job, or tool |
| Missing billed class | Requests exist but a tool or cache class was not priced | Extend the usage and pricing schema |
| Price mismatch | Quantities match but money does not | Correct tier, region, effective date, or contract rate |
| Timing | Adjacent buckets offset each other | Align boundaries or wait for provider freshness |
| Credit or adjustment | Negative or revised billing line | Preserve as a separate financial adjustment |
| Shared commitment | Fixed cost has no request identity | Apply a documented allocation rule |
| Unknown | Evidence is insufficient | Keep it visible and assign an owner |
The unknown bucket is a control, not an embarrassment. Hiding it produces confident but unauditable customer margins.
6. Allocate the reconciled total
Once the provider-level amount is trusted, map it to customer, feature, workflow, team, agent, or outcome using stable application identifiers. Our AI cost attribution guide covers that business mapping in detail.
For a group where telemetry estimated $9,700 and the reconciled billed amount is $10,000, a proportional allocation factor is:
reconciled allocation factor = 10,000 / 9,700
Apply that factor only within a defensible shared group. Do not spread an unexplained provider-wide residual across every customer if the variance belongs to one project or service tier.
Reconciliation controls worth operating
A monthly spreadsheet is a start. A durable control has owners, thresholds, evidence, and a close process.
- Report absolute and percentage variance by provider and shared dimension.
- Track billed cost that remains unattributed to a customer, feature, workflow, or team.
- Alert on new model aliases, token classes, service tiers, or billing descriptions.
- Version price rules and never silently reprice historical periods.
- Keep credits, taxes, marketplace fees, and commitments separate from variable inference cost.
- Link every aggregate to the raw usage, calculation rule, billing line, and allocation rule behind it.
- Close a period only after the provider's documented freshness window.
The FinOps Foundation's Unit Economics capability emphasizes connecting technology cost to business value. That connection is only as reliable as the cost total underneath it.
How reconciliation changes optimization claims
Suppose a model swap reduces calculated request cost by 28 percent in a replay. That is a projected saving. If the production event mix changes, quality causes retries, a service tier changes, or the contract price differs from the test rate, the invoice may move by another amount.
Use three labels:
- Projected savings: the modeled difference before deployment.
- Observed usage savings: the change in normalized production telemetry after adoption.
- Reconciled realized savings: the change supported by comparable provider billing evidence after controlling for volume and mix.
This prevents a benchmark result from being reported as cash saved before the system has produced financial evidence. The same rule applies to caching. A higher cache-hit rate is operationally useful, but the realized saving depends on cache write charges, read rates, request mix, and the final provider bill.
The practical starting point
Choose the largest provider account and one closed billing week. Export provider usage and cost evidence, aggregate application telemetry to the narrowest shared dimensions, and calculate the residual. Classify the top three differences. Assign an owner to every unknown category and repeat the same comparison the following week.
Only after that total is defensible should you allocate it to customer margin or claim realized savings.
trAIce is built around that separation of evidence. It preserves request context and pricing provenance, connects cost to customers, features, teams, employees, agents, and outcomes, and keeps provider reconciliation distinct from calculated estimates. Explore the developer documentation, try the AI cost calculator, review security behavior, or start free.