Single Bill for Multiple LLM APIs
Preserve Every Charge
Consolidate LLM API charges with provider usage, pricing, allocation, reconciliation, and audit evidence.
TL;DR
Store provider request IDs, model, usage dimensions, status, time and source.
Create common reporting fields without erasing provider-native units.
Require tenant, team, project, product, environment and cost-center ownership.
Match provider exports and invoices, then append documented adjustments.
A single bill for multiple LLM APIs is an accounting product
Different providers expose different usage fields and invoice on different cutoffs, currencies, regions and commercial terms. Input, cached input, output, reasoning, media, storage and priority processing may be priced separately. A consolidated bill therefore needs a canonical category model without discarding the provider-native unit and evidence behind every line.
Separate three layers: raw usage, priced cost and customer charge. Raw usage records what the provider measured; priced cost applies the rate effective at event time; customer charge adds contracts, credits, taxes or internal allocation rules. Keeping the layers distinct prevents a pricing correction from mutating the underlying operational evidence.
Do not rewrite history when late usage, credits, refunds or disputes arrive. Append adjustment events linked to the original records, with reason, source and approver, so finance and engineering can reproduce both the first invoice and its corrected version.
Billing data layers
| Layer | Best fit | Verify before choosing |
|---|---|---|
| Request evidence | Explain individual usage and operational outcomes. | Stable IDs, attempts, retries, cache, tools, privacy and duplication. |
| Usage ledger | Aggregate and allocate across providers and tenants. | Immutability, schema versions, unit provenance and late events. |
| Provider reconciliation | Align internal records with provider exports. | Time zones, aliases, invoice periods, missing IDs and rounding. |
| Consolidated invoice | Charge back one understandable bill. | Currency, tax, credits, commitments, adjustments and dispute rights. |
Invoice governance controls
Version cost-center mappings and define treatment for missing tags.
Model price, route fee, commitment, credit, tax and currency basis.
Record reason, source, approver, affected period and original lines.
Give finance, engineering and audit role-appropriate drill-down.
Close the billing period reproducibly
Period close should be a controlled workflow, not an ad hoc spreadsheet merge. Define when usage is considered complete, which price and exchange-rate snapshots apply, who can approve adjustments and what variance requires investigation.
- Freeze the billing cutoff, rule versions and exchange-rate source, then ingest final provider exports.
- Deduplicate events and reconcile by provider, account, project, model, region and usage dimension.
- Review missing usage, unexplained variance, currency basis, tax, credits and contract adjustments.
- Sample invoice lines and drill them down to native request IDs, usage and applied terms.
- Regenerate the same invoice from immutable inputs and compare a deterministic invoice hash before release.
Preserve two views of the same bill
The consolidated view groups normalized categories by tenant, product, environment and cost center so a customer or budget owner can understand the total. The evidence view preserves provider exports, native request IDs, original units, price source, exchange-rate snapshot, reconciliation result and every adjustment. Each consolidated line should reference the evidence set from which it was calculated.
Generate both views from the same append-only ledger and versioned commercial rules. Store the ledger cutoff, rule version and invoice hash with the released document. If a correction is required, issue a new version or credit note linked to the original rather than editing the old artifact in place.
Production rule: never issue a consolidated charge that cannot be drilled down to provider-native evidence and the exact terms applied.
Include tool charges without turning them into tokens
QVeris calls external APIs, tools, services and live data that may bill by request, record, compute minute, data package or subscription. Keep each native unit, capability ID, provider evidence and price version in a separate capability ledger. Converting all of these to an invented token equivalent makes the invoice simpler to display but impossible to audit.
Add a distinct capability section to the consolidated bill and connect it to the same tenant, workload and parent trace as inference. This shows the complete workflow cost without confusing model spend with external data or action fees, and it reveals whether a retry reused a previous result or created another billable call.
Reconcile the unified invoice to native usage
One invoice reduces procurement work but does not remove the need for a usage ledger. Store provider, model, billable token classes, gateway fee, currency, and pricing version for each request; otherwise a monthly total cannot be explained or allocated.
{
"event_version": 1,
"request_id": "req_01...",
"tenant": "team-support",
"workload": "support-answer",
"provider": "provider-name",
"model": "exact-model-id",
"usage": {"input": 1820, "cached_input": 900, "output": 244},
"price_version": "2026-07-21-usd",
"provider_cost_usd": 0.000000,
"gateway_fee_usd": 0.000000,
"invoice_id": null,
"trace_id": "trace_01..."
}- Reconcile request ledger totals to provider exports and the aggregator invoice.
- Keep taxes, credits, negotiated discounts, and currency conversion as separate lines.
- Alert on unmapped model IDs, missing usage, duplicated request IDs, and price-version gaps.
Verified implementation reference: OpenTelemetry GenAI conventions.
FAQ
No. It is a consolidated financial view over independently evidenced providers.
No. Normalize categories for reporting but preserve native billable units.
As documented adjustment events linked to the affected provider lines and period.