当每个工作负载都使用同一提供商、同一计价单位和同一种付款方式时，AI API 发票很容易批准。但 AI 产品团队并不会长期这样运作。一个支持类 Copilot 可能会使用输入 token、输出 token、缓存 token 和重试。一个创意工作流可能会增加图像单位或视频秒数。一个编码代理可能会通过多条路径调用模型和工具。财务看到的是充值记录和发票；工程看到的是请求日志。
AI API 发票对账：匹配使用量、计价单位与充值记录 是一个按月执行的流程，它将这些分散的视图转化为一次可审计的关账。目标不是手工为每个请求重新定价，而是证明使用记录、计价单位规则、余额变动、充值记录、积分、税费和发票总额彼此一致、能够相互解释。
Flatkey 就是为这类审查而构建的：一个 key、一个余额、一张发票、300+ 官方模型、1,000+ 按次付费工具、按请求级别的账本可见性、子 key 预算、模型白名单，以及 48 小时内出具发票。本指南展示产品、平台、运营和财务团队如何在不拖慢模型实验的情况下运行对账闭环。它还为已经拥有 AI API 使用账本、但在月末仍难以匹配 AI API 充值记录和 AI API 计价单位的团队，提供一种实用的 AI API 计费对账模式。
快速答案
对于 AI API 发票对账：匹配使用量、计价单位与充值记录，需要将以下四张表一起对账：
| 表 | 负责人 | 必须匹配的内容 |
|---|---|---|
| 使用账本 | 平台和产品 | 请求 ID、工作负载、模型或工具、输入单位、输出单位、缓存单位、状态、重试、已接受结果 |
| 计价单位映射 | 平台和财务 | 单位类型、来源提供商、模型或工具、费率来源、舍入规则、生效日期 |
| 充值记录 | 财务 | 充值金额、充值前后余额、支付参考号、积分、税费、负责人 |
| 发票 | 财务和运营 | 按单位划分的小计、积分、税费或 VAT、例外项、已批准总额 |
实际关账规则很简单：
approved_invoice_total =
matched_usage_cost
+ taxes_or_vat
- credits
+/- approved_adjustments
如果这些数字无法对账，不要先去投诉提供商。先检查单位映射。大多数 AI 计费不一致都源于：将使用量归类到了错误的单位、遗漏了缓存行为、将评估流量与生产流量混在一起、对失败或重试的调用处理不一致，或者在未匹配余额变动的情况下就批准了充值。
为什么 AI API 发票对账会失效
传统 SaaS 对账通常匹配席位、订阅周期和付款记录。AI API 对账则有更多变量。
Token 模型可能会对输入和输出采用不同定价。一些提供商会暴露缓存输入或 prompt 缓存单位。批处理的经济模型可能与同步调用不同。图像、视频、语音、嵌入、重排序、浏览器操作、丰富化工具，以及 agent 工具调用，可能各自使用自己的计价单位。单个产品功能在一次用户会话中可能会触及其中多个单位。
这使得提供商级别的发票总额对于产品团队来说过于粗略。月度总额可以告诉财务支出上涨了，但它无法解释增长究竟来自用户增长、模型升级、更长的输出、缓存未命中、视频生成、重试循环，还是一次性的评估运行。
对账工作的目标，是将这些上下文从请求一直保留到发票。
要匹配的四类记录
1. 使用台账
使用台账是运营事实的来源。每一行都应描述发生了什么，而不仅仅是花了多少钱。
至少保留以下字段：
| 字段 | 重要原因 |
|---|---|
request_id |
让工程能够将一笔费用追溯到一个请求或作业 |
timestamp |
将使用情况与计费周期及价格生效日期对齐 |
team 和 workload |
支持成本分摊和负责人审阅 |
environment |
区分生产、预发布、评估和内部自动化 |
model_or_tool |
标识所使用的路由或付费工具 |
unit_type |
防止 token、图像、视频和工具单位被混用 |
input_units 和 output_units |
区分定价不同的单位 |
cache_units |
在相关时捕获缓存读取或缓存写入行为 |
status 和 retry_count |
解释失败调用、重试风暴和重复支出 |
accepted_result |
将成本与业务产出而非原始使用量关联起来 |
cost_center |
为财务提供分摊或展示的键 |
不要等到月末才补充这些字段。如果在请求时缺少成本中心、环境、工作负载或负责人，财务之后就只能从 Slack 消息中重建上下文。
2. 计价单位映射
计价单位映射会将原始使用量转换为可计费单位。许多 AI API 发票不一致的问题都始于这里。
使用类似这样的表：
| 单位类别 | 示例 | 对账风险 |
|---|---|---|
| 文本输入 | 提示词 token、长上下文、系统指令 | 长提示词和检索到的上下文可能会悄然增长 |
| 文本输出 | 完成 token、推理输出、结构化 JSON | 即使输入稳定，冗长输出也可能主导成本 |
| 缓存输入 | 缓存读取、缓存写入、提示缓存 | 缓存未命中或前缀变更会影响预期成本 |
| 批处理 | 离线批处理任务、评估扫测 | 用量可能落在与触发事件不同的周期 |
| 图像 | 生成图像、编辑、预览 | 单位定义因提供商和模型而异 |
| 视频 | 秒数、片段、帧、分辨率档位 | 小的工作流变更也可能显著改变单位数量 |
| 音频和语音 | 转录、语音生成、音频 token | 时长和模态的计费方式可能不同于文本 |
| 工具 | 搜索、浏览器、增强、社交、爬虫、媒体操作 | 工具调用通常更像工作流支出，而不是模型支出 |
对于波动较大的模型价格，不要在结账流程中硬编码费率。应存储源 URL、来源核对日期、模型或工具 ID、单位标签、生效日期、舍入规则和负责人审批。然后在结账时更新计价单位映射。
3. 充值记录
充值记录解释余额变动。它们不应被视为用量的替代品。
对于预付费系统，充值证明资金已进入账户，但并不能证明是哪个工作负载消耗了这些资金。对于后付费系统，付款记录证明结清完成，但并不能证明发票总额分配是否正确。
需要跟踪：
- 充值 ID 或付款参考号。
- 付款方或计费负责人。
- 充值前后的余额。
- 币种。
- 信用额或促销调整。
- 税费、增值税或发票要求。
- 关联发票或收据。
- 审批负责人。
关键控制点是余额变动：
ending_balance =
starting_balance
+ approved_recharges
+ approved_credits
- matched_usage_cost
- taxes_or_fees_when_applicable
如果余额变动不符，应分离判断是缺少用量、缺少充值、币种错误、税务处理、信用额、退款，还是时点差异。
4. 发票
发票是审批文件，而不是证据系统。它应当汇总分类账和充值记录已经解释清楚的内容。
一份可审查的 AI API 发票应包括：
| 发票部分 | 需附证据 |
|---|---|
| 总使用成本 | 按工作负载和单位类型汇总的使用台账小计 |
| 抵扣和调整 | 贷项通知单、支持工单、承诺消费规则或提供商调整 |
| 税费或增值税 | 计费资料、发票司法辖区、税号、fapiao 或 VAT 字段 |
| 充值或付款 | 充值记录、卡或电汇参考号、余额变动 |
| 例外项 | 负责人、原因、影响和下一步行动 |
不要因为顶部总额“看起来差不多”就批准发票。只有当每一处实质性差异都有负责人和解释时，才批准它。
月度 AI API 发票对账工作流
在月末结账前运行此工作流，并将其保持得足够轻量，以便产品团队也能参与。
步骤 1：冻结源期间
在 UTC 和财务日历时区中设置计费窗口。然后冻结输入集：
period:
usage_start_utc: 2026-09-01T00:00:00Z
usage_end_utc: 2026-10-01T00:00:00Z
finance_month: 2026-09
source_locked_at: 2026-10-02T12:00:00Z
这可以防止滚动仪表盘在财务审核发票时发生变化。
步骤 2：按工作负载和单位导出使用量
先按工作负载分组请求，再按提供商分组。仅按提供商的报表会隐藏财务需要的产品上下文。
使用以下导出格式：
period,team,workload,environment,model_or_tool,unit_type,units,cost_usd,accepted_results,retries,failed_calls,cost_center
2026-09,customer-platform,support-copilot,production,primary-support-route,input_tokens,184200000,92.10,48120,329,41,cs-ops
2026-09,customer-platform,support-copilot,production,primary-support-route,output_tokens,49600000,248.00,48120,329,41,cs-ops
2026-09,growth,research-agent,production,web-enrichment-tool,successful_tool_calls,8720,174.40,3180,92,13,gtm
如果某一行有使用量但没有负责人，则将其视为例外项。未知归属不仅是财务上的麻烦；这还是治理失败。
步骤 3：在总额之前验证计价单位
在核对美元总额之前，先检查单位分类：
| 检查项 | 问题 |
|---|---|
| 模型 ID | 台账中的模型是否与计价来源模型一致？ |
| 单位标签 | 该行是输入、输出、缓存输入、图像、视频、音频还是工具使用？ |
| 生效日期 | 该费率在请求期间是否有效？ |
| 缓存行为 | 当提供商对缓存写入和缓存读取采用不同定价时，它们是否被分开？ |
| 批处理行为 | 当批处理作业与同步调用的经济性不同时，它们是否被分开？ |
| 失败调用 | Flatkey 侧失败调用、提供商侧失败和用户取消调用是否被一致处理？ |
| 舍入 | 发票舍入规则是否有文档记录？ |
只有在此之后再比较总额。
步骤 4：将充值记录与余额变动匹配
对于每一笔充值或付款记录，请确认：
- 付款参考号存在。
- 金额和币种与计费档案匹配。
- 扣除积分或费用后的余额变动与充值金额一致。
- 充值记入同一期间，或被标记为时间差异。
- 发票或收据已附上。
预付余额很有用，因为它们让支出上限变得具体可见。但它们仍然需要一条对账记录。没有这条记录，团队只知道现金进入了账户，却不知道是哪个产品行为消耗了它。
步骤 5：构建异常队列
保持异常队列小而明确。
| 异常类型 | 可能原因 | 负责人 |
|---|---|---|
| 缺少成本中心 | 新密钥、路由或任务上线时未打标签 | 运营 |
| 单位不匹配 | 缓存、批处理、图像、视频或工具使用映射错误 | 平台 |
| 时间不匹配 | 批处理任务或充值记账时间超出预期期间 | 财务 |
| 重试激增 | 上游不稳定、客户端重试循环或缺少退避 | 工程 |
| 失败调用争议 | 失败类别未被足够清晰地拆分 | 平台和供应商负责人 |
| 发票税额不匹配 | 计费档案、VAT 或 fapiao 数据不完整 | 财务 |
每个异常都应有截止日期和规则变更。如果同样的异常下个月再次出现，说明流程并没有真正改进。
面向多模型团队的计价单位控制
产品团队通常从模型价格表开始对账。这并不是正确的第一步。应先从单位分类法开始。
OpenAI、Anthropic 和 Gemini 都发布了定价和用量文档，但它们的单位呈现并不相同。当前官方文档包含输入、输出、缓存或 prompt-caching 单位、批处理行为以及按模态区分的定价等概念。具体费率可能会变化，因此请将官方供应商页面作为费率来源，并将内部单位映射作为审批记录。
控制问题是：
我们能否用使用台账中产品和平台团队使用的同一套单位标签
来解释每一笔重要发票小计？
如果答案是否定的，请先修正单位标签，再去争论总额。
Flatkey 的适用场景
当由于 AI 技术栈碎片化而导致发票对账困难时，Flatkey 会很有帮助。
在以下情况下使用 Flatkey：
- 产品团队需要在官方模型端点之间使用一把统一密钥，而不是在每个应用、智能体或代码仓库中分别使用供应商密钥。
- 财务希望模型和工具支出共用一个余额和一张发票。
- 运营需要子密钥预算、模型允许列表、告警和台账审查。
- 平台团队需要对输入、输出和缓存 token 进行请求级可见性。
- 智能体构建者需要与模型调用处于同一计费界面上的按次付费工具。
- 财务需要尽快获取发票，并在适用情况下支持 VAT 或 fapiao。
Flatkey 并不会消除月结的需要。它通过将使用量、余额和发票证据移到同一运营层中，使结账更容易。这让财务需要对账的仪表板更少，也让产品团队有更清晰的方式来证明有价值的支出。
有关相关的设置工作，请使用 AI API 支出管理 运营模型、AI 网关定价 指南、AI 模型价格比较工作表，以及 计价单位清单。
可复制的对账清单
月度审核请使用此清单。
| 控制项 | 通过条件 |
|---|---|
| 期间锁定 | 使用窗口、发票期间和财务月份已固定 |
| 负责人覆盖 | 每一条生产数据行都包含团队、工作负载、环境和成本中心 |
| 单位映射 | 每一个计费单位都映射到有来源支撑的单位定义 |
| 定价来源 | 每个费率都链接到官方来源和来源核查日期 |
| 充值匹配 | 充值能够解释余额变动并链接到付款参考 |
| 积分 | 积分、退款和调整都有证据 |
| 失败调用 | 失败调用的处理按失败类型分开 |
| 重试 | 重试峰值会结合工作负载日志进行审核 |
| 发票总额 | 使用量、税费、积分和调整与发票对账一致 |
| 例外项 | 每一个未解决差异都有负责人、原因、影响和到期日 |
最好的目标不是“没有问题”。最好的目标是没有匿名差异。
结账期间需要核实的官方参考资料
每次结账时都使用实时来源，因为定价和单位定义会变化。
| 来源 | 需要核实的内容 |
|---|---|
| Flatkey pricing | 当前方案、充值和计费界面，以及实时产品条款 |
| Flatkey models | 当前模型可用性和路由标签 |
| OpenAI API pricing | 当前模型费率和计价单位标签 |
| OpenAI usage API reference | 可用于直接 OpenAI 使用情况的使用报告字段 |
| Anthropic pricing | 模型定价、提示缓存和批处理定价参考 |
| Anthropic Admin usage and cost API | Anthropic 管理工具中可用的成本和使用情况报告 |
| Gemini API pricing | 当前 Gemini 单位和模型定价参考 |
| FinOps allocation guidance | 分摊、标记、showback 和 chargeback 规范 |
| FOCUS cost and usage specification | 供财务审阅的标准化成本和使用数据概念 |
不要把波动的供应商费率直接粘贴进政策文档后就不再更新。应记录来源核查日期，并将定价验证纳入月结流程。
常见问题
什么是 AI API 发票对账？
AI API 发票对账是将请求级使用量、计价单位、充值记录、积分、税费、余额变动和发票总额进行匹配的过程，以便财务和产品团队能够基于证据批准 AI 支出。
为什么计价单位对 AI API 发票很重要？
计价单位很重要，因为 AI API 并不总是按单一、简单的单位计费。一个工作负载可能包含输入 token、输出 token、缓存单位、批处理任务、图像、视频秒数、音频或工具调用。即使原始使用导出完整，如果单位错误，发票比对也会出错。
AI API 使用台账中应该包含什么？
AI API 使用台账应包含请求 ID、时间戳、团队、工作负载、环境、模型或工具、单位类型、输入单位、输出单位、缓存单位、状态、重试次数、成本中心、成本以及已接受结果状态。这些字段可以让 AI API 计费对账成为可能，而无需财务逐条检查每个请求。
团队应如何对账充值记录？
将 AI API 充值记录与付款参考、计费负责人、币种、充值前余额、充值后余额、积分、税费以及发票或收据进行匹配。然后将余额变动与匹配后的使用成本和已批准的调整进行比较。
财务是否应该审查每个请求？
不需要。财务应按工作负载、计价单位、成本中心、充值、信用额度和异常情况审查汇总后的使用情况。平台团队应保留请求级账本，以便在需要时追溯任何重大差异。
Flatkey 如何帮助进行 AI API 发票对账：匹配使用量、计价单位和充值记录？
Flatkey 为团队提供一个密钥、一个余额、一张发票、请求级账本可见性、子密钥预算、模型白名单，以及对官方模型和按次付费工具的访问。这使得将使用证据、充值记录和发票审批纳入一个月度工作流中变得更容易。
结论
AI API 发票对账：匹配使用量、计价单位与充值记录 是 AI 产品团队在模型和工具使用快速变化时保持财务信任的方式。
按以下顺序开展工作：锁定期间，按工作负载和单位导出使用情况，核实计价单位映射，将充值记录与余额变动匹配，审批发票总额，并与负责人关闭异常。Flatkey 通过将模型和工具支出整合到一个运营层中来提供帮助，因此账本、余额和发票能够讲述同一个故事。
