Single Bill, Multiple LLM APIs: Consolidate the Invoice, Preserve Evidence 多个 LLM API 统一账单：合并发票，同时保留证据
A consolidated invoice is useful only when every charge remains traceable to provider-native usage, commercial terms, allocation rules and adjustment events.
只有每笔费用仍可追踪到供应商原生用量、商业条款、分摊规则与调整事件时，统一账单才真正有用。
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.
存储供应商请求 ID、模型、Usage Dimension、Status、Time 与 Source。
建立通用报告字段，同时不抹除供应商原生单位。
要求租户、Team、Project、Product、Environment 与 Cost Center 归属。
匹配供应商导出与账单，再追加有记录的调整。
A single bill for multiple LLM APIs is an accounting product 多个 LLM API 的统一账单本质上是一项核算产品
Different providers expose different usage fields and bill on different cutoffs, currencies, regions and commercial terms. The consolidated bill needs a canonical category model plus the native evidence behind every line.
不同供应商公开的用量字段不同，并按不同截止、币种、区域与商业条款计费。统一账单需要规范类别模型，以及每行背后的原生证据。
Do not rewrite history when late usage, credits or disputes arrive. Append adjustment events linked to the original records so finance and engineering can reproduce the invoice.
迟到用量、Credit 或争议到来时不要重写历史。应追加关联原记录的 Adjustment Event，使财务与工程可以复现账单。
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. 核对稳定 ID、尝试、重试、缓存、工具、隐私与重复。 |
| 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. 核对时区、别名、账期、缺失 ID 与舍入。 |
| Consolidated invoice 统一账单 | Charge back one understandable bill. 进行一次清晰的 Chargeback。 | Currency, tax, credits, commitments, adjustments and dispute rights. 核对币种、税费、Credit、承诺、调整与争议权利。 |
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.
版本化 Cost Center 映射，并定义缺失 Tag 的处理。
模型价格、路由费、承诺、Credit、税费与币种基准。
记录原因、来源、Approver、影响账期与原始行。
为财务、工程与审计提供符合角色的下钻访问。
Close the billing period reproducibly 可复现地关闭账期
- Freeze the billing cutoff and ingest final provider exports.
- Reconcile by provider, project, model, region and usage dimension.
- Review unexplained variance, currency basis, tax and contract adjustments.
- Regenerate the same invoice from immutable inputs before release.
- 冻结账期截止并导入最终供应商导出。
- 按供应商、Project、模型、Region 与 Usage Dimension 对账。
- 审查未解释差异、币种基准、税费与合同调整。
- 发布前从不可变输入重新生成相同账单。
Preserve two views of the same bill 保留同一账单的两种视图
The consolidated view groups normalized categories by tenant and cost center. The evidence view preserves provider exports, native request IDs, pricing source, reconciliation results and adjustments. Both are generated from the same immutable ledger and versioned commercial rules.
统一视图按租户与 Cost Center 汇总标准化类别；证据视图保留供应商导出、原生请求 ID、价格来源、对账结果与调整；两者由同一不可变账本与版本化商业规则生成。
Production rule: never issue a consolidated charge that cannot be drilled down to provider-native evidence and applied terms.
生产规则：无法下钻到供应商原生证据与已应用条款的统一费用，绝不能出账。
Include tool charges without turning them into tokens 纳入工具费用但不把它们变成 Token
QVeris calls external APIs, tools, services and live data that may bill by request, record, compute or subscription. Keep those native units and evidence, then add a separate capability section to the same consolidated bill.
QVeris 调用外部 API、工具、服务与实时数据，可能按请求、记录、计算或订阅计费。保留原生单位与证据，再把独立能力费用区段加入同一统一账单。
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.
统一账单降低采购工作，但不会消除 Usage 账本的必要性。每个请求都应记录供应商、模型、可计费 Token 类型、网关 Fee、Currency 与 Pricing Version，否则月度总额无法解释或分摊。
{
"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.
- 将请求账本汇总与供应商导出及聚合商账单对账。
- 把税费、Credits、协议折扣与汇率换算作为独立行。
- 对未映射模型 ID、缺失用量、重复请求 ID 与 Price Version 断层告警。
Verified implementation reference: OpenTelemetry GenAI conventions.
实施参考已根据官方资料核验：OpenTelemetry GenAI conventions。
Build an Effective Cost Model for single-bill multi-LLM access为多 LLM 单一账单访问建立有效成本模型
When evaluating Single Bill Multiple LLM APIs, list price is an input, not the decision. Compare the cost of an accepted production outcome after quality, retries, latency, operational work, and non-token charges are included.
评估“多个 LLM API 统一账单”时，目录价只是输入，而不是最终决策。应在计入质量、重试、延迟、运营工作和非 Token 费用后，比较获得一个合格生产结果的成本。
Sample production-shaped tasks and record aggregator markup, pass-through provider prices, credits, currency conversion, taxes, failed calls, refunds, usage latency, and invoice-level model identity. Use percentiles and task classes rather than one average prompt so long-context and output-heavy requests remain visible.
抽取接近生产形态的任务，并记录聚合商加价、供应商成本转嫁、额度、汇率、税费、失败调用、退款、用量延迟和发票级模型身份。使用分位数和任务类别，而不是单个平均提示词，确保长上下文与高输出请求不会被隐藏。
When evaluating Single Bill Multiple LLM APIs, measure completion, rubric score, structured-output validity, tool accuracy, retry rate, and human-review time. Divide total run cost by accepted outcomes, not by raw requests.
评估“多个 LLM API 统一账单”时，对每个模型与路由衡量完成率、评分标准得分、结构化输出有效率、工具准确率、重试率和人工复核时间，并用总运行成本除以合格结果，而不是原始请求数。
When evaluating Single Bill Multiple LLM APIs, add gateway or aggregator fees, storage, egress, cache writes, evaluations, observability, support, engineering, incident handling, reserved capacity, unused credits, taxes, and the business cost of latency or failed work.
评估“多个 LLM API 统一账单”时，加入网关或聚合费用、存储、流量、缓存写入、评估、可观察性、支持、工程、事故处理、预留容量、未用额度、税费，以及延迟或任务失败的业务成本。
When evaluating Single Bill Multiple LLM APIs, store source URL, retrieval date, currency, region, service tier, thresholds, discounts, and model version. Recompute scenarios when a catalog changes and alert when observed invoice cost diverges from the estimate.
评估“多个 LLM API 统一账单”时，保存来源链接、获取日期、币种、区域、服务层级、阈值、折扣和模型版本。目录变化时重新计算情景，并在实际发票成本偏离估算时发出告警。
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.
不是。它是多个独立证据供应商之上的统一财务视图。
不应。报告可标准化类别，但必须保留原生计费单位。
作为有记录的调整事件，关联受影响的供应商行与账期。