AI API 用量与账单对不上，怎样逐项核对？
AI API 用量与账单不一致、没有返回结果却扣费时，先对应请求编号、实际输出、计费单位和结算记录。附缺失资料清单、7例合成演示和原始下载；不能据此直接判定多扣费或退款责任。
这是本站整理的核对流程与合成演示，AI 辅助编制，未经独立人工复核。没有接入任何服务商或客户账单，没有新增模型运行、客户访谈、退款或经营结果；也不替服务商解释合同或作退款裁定。
API 用量与扣费对不上，先核对什么？
先选一条有争议的请求，把请求编号、账户与项目、时间和时区、实际返回、用量分项、当时费率及扣费明细对应起来。遇到单位不同、缺少明细或退款只有通知时，先记录缺失证据；不要用余额变化、成功状态或一条客户反馈直接判定计费正确或多扣费。
适合已经发现一次调用或一组同范围记录有差异、需要整理依据的人。完成后应得到“对应记录、缺失资料、待核问题”清单，而不是一个未经证实的多扣金额。支付 API 的银行流水对账、服务商采购比较和整套计费系统开发不在本页范围内。
先准备哪些记录？
先在自己的环境保留原始文件，再做脱敏副本。以下字段由本站根据案例归纳；不要求把提示词、客户正文、密钥或完整凭据发送给本站。
| 记录 | 需要对应的内容 | 缺失时怎么处理 |
|---|---|---|
| 请求与关联 | 请求编号、任务编号与重试记录，以及两者的对应关系。 | 只有客户一句“没结果”时，先找到对应请求，不把多次尝试合成一次。 |
| 账户与时间 | 账户、项目、模型、完整时间戳与时区；账单所用时间范围和导出时点。 | 范围不同先重选；时区不明保留未知，不能凭两个钟面时间判断重复。 |
| 实际返回 | 状态码、实际返回类型、是否中断、是否有最终成果及用量字段。 | 请求被受理不等于交付完成；无最终成果也不能自动推导实际厂商不应收费。 |
| 用量与计价规则 | 输入、输出、缓存等分项及单位；当时的费率版本、币种或积分换算规则。 | 相同数字不同单位不能相减；缺规则先补规则，不套用其他平台价格。 |
| 扣费与调整 | 可关联的账单条目、计费项目、结算状态；分项扣费、优惠、税费、调整与延迟说明。 | 多条条目先查是否分项；没有账单行不等于没有收费，也可能尚未结算。 |
| 反馈与处理 | 客户反馈对应的任务，沟通时间、解释内容、待处理项和已确认项。 | 已发解释不等于客户认可；客户未回复也不等于争议解决。 |
| 退款或不适用 | 有退款时保留原扣费关联、退款金额、状态和到账凭据；没有退款事项则标不适用。 | 申请、承诺、通知和到账分别记录；缺到账记录既不写已到账，也不写退款失败。 |
生成本次待补资料清单
只勾选已经备齐且能相互关联的记录；退款项也可以按“不适用”勾选。选择仅在当前页面处理，不上传、不自动保存；刷新后重置，不采集选项内容。
未勾选的项目保留为待补资料；勾选不等于对账通过。
对不上时，下一次应确认什么？
| 情境 | 下一步 | 对应合成例子 |
|---|---|---|
| 范围或单位不同 | 先统一账户、时间窗口、单位和费率版本；无法统一就记录未知。 | D04、D05 |
| 同一请求出现多条扣费 | 查分项、重试、调整与结算状态；同一请求编号下多条记录本身不足以证明重复收费。 | D02 |
| 无成果却有扣费 | 对照原约定、真实返回、用量和失败计费规则，保留请求与账单条目供服务商核实。 | D03 |
| 反馈或退款无法关联 | 先补关联编号；退款另查实际结算凭据，不用沟通记录替代。 | D06、D07 |
| 给定字段全部匹配 | 只记为本轮所查字段匹配，继续保留费率、凭据真实性和未覆盖情形的边界。 | D01 |
没有返回结果却收费时，先保留原请求和账单条目，再查服务商对中断、重试、部分输出及结算延迟的约定。本文无法仅凭“无结果”或 HTTP 成功状态确定收费和退款责任。
API 对账演示：把请求、扣费和退款状态逐项对应（合成数据）
先下载合成记录和核对规则，再按请求编号关联实际输出、用量与扣费，单独查看反馈和退款状态。以下7例全部由本站编制，不是来源部分三位作者的日志，也不是真实客户反馈。虚构单位 demo_credit 与 demo_token 没有提供换算规则；本演示不涉及真实价格、交易或经营结果。
| 合成情境 | 按本演示规则得到什么 | 仍不能证明什么 |
|---|---|---|
| D01：一条请求对应一条扣费 | 输出为图片，同一请求、时间、单位与数量匹配。 | 只检查合成字段，不证明客户满意或真实计费准确。 |
| D02：同一请求有两条有效扣费 | 本演示约定每请求至多一条扣费，因此标为待核。 | 真实系统可能分项计费，不能直接套用为多扣费结论。 |
| D03：没有返回图片，却有正数扣费 | 本演示约定有图片才计费，因此输出与扣费均待核。 | 这不是实际厂商的收费规则或已确认的退款责任。 |
| D04：用量是 demo_token，扣费是 demo_credit | 没有换算表，保持单位未知，不计算差额。 | 100与10不能直接相减，也不能判定收费过高。 |
| D05：01:00Z 与 09:00+08:00 | 两个带时区时间为同一时刻；其他字段匹配。 | 仅对账单记载的请求时刻，不代表入账或处理延迟。 |
| D06：退款状态为已通知、到账时间空白 | 退款到账保持未确认，不以通知代替结算记录。 | 不能写成已经到账或退款失败。 |
| D07：反馈说没结果，但未关联请求编号 | 反馈不能与本条请求对应，先补齐关联依据。 | 不能用这条反馈推定当前请求或全部收费有误。 |
本站离线检查输出为2例符合演示约定、5例待核，结果由样本设计决定，不是错误率或经营效果。规则不覆盖分项计费、部分退款、流式输出、费率变更、税费和凭据真实性。未经独立人工复核，不适合直接用于生产账单。原数据、规则、预期输出和离线检查器分别保留；不运行模型，不上传填写内容。
下载原记录并离线复查
这些文件仍是此前发布的 v1 原件，数据和检查规则没有改动。把数据、检查器和预期输出下载到同一文件夹，按规则文件中的步骤运行；无需模型、API 密钥或联网。修改副本时保留原文件、改动和实际输出，不能用预期结果代替运行结果。
来源事实、本站归纳与未知事项
流程来自本站对已有材料的归纳；合成演示来自本站自设规则。两者都不能冒充来源作者实际采用过的方法或真实客户反馈。
预付额度只有总量，怎样回到逐次记录：作者自述事后重建明细并退款；本站未见私人日志或到账凭据。用来说明总量不能替代逐笔记录。 u/Scared_Sentence_2834 · 原帖
实际输出和计费项目是否一致：作者区分文本返回与无内容收费，后者仍待调查；不能当作现行收费规则或已完成修复。 numlocked · 原帖
查日志、解释与实际退款分别记录：作者报告支持投入和未来退款偏好；此次实际退款结果、客户回应和计费正确性仍未知。 mikaizhu · 原帖
官方文档的口径提醒
文档核对日期：2026年10月25日。不同产品、版本和合同须分别核对，不把一家规则套用到另一家。
- Claude：Usage and Cost API：官方文档将用量与费用分开，费用有自己的单位和时间粒度，并说明数据可能延迟。此处只用来提醒核对报表口径，未调用该 API 或验证任何账单。
- Twilio：Usage API guide：官方文档区分用量估计与月末正式账单。它是非 AI API 的口径对照，不代表 AI 服务商都采用同样的结算规则。
仍然未知或未覆盖
- 真实业务的原始请求、客户授权、计费规则版本和账单完整性，本页无法确认。
- 三例公开材料沿用已有核对记录，没有在本轮重新读原帖或核验私人账单；缺少后续的事项仍保持未知。
- 演示的“有图片才计费”“每请求至多一条扣费”是虚构约定，不能外推到流式生成、重试、分项计价或真实厂商规则。
- 勾选清单只表示你认为资料已备齐，不验证凭据真实性、规则正确性或争议结论；本页不接收文件和 API 密钥。