IOSOR 知识库

报表必须对齐 DLR 交付回执，而非提交数量

已提交不等于已送达。财务与产品报表导出必须基于 DLR 交付回执——切勿仅凭接收发送总数来进行周度结算。

提交数量往往给人一种安全感：API 已经接纳了消息，因此这一周的工作似乎顺利完成。然而这种安全感在结算周会被彻底打破。将提交数量等同于成功的报表，必然会与 DLR 交付回执、多分段流量的钱包扣费以及 Webhook 审计结果产生严重分歧。

IOSOR 严格恪守这一规则：报表导出必须紧跟交付回执。已提交(Submitted)、已排队(Queued)和已接收发送(Accepted-for-send)仅作为运维维度的过程标记。而已送达(Delivered)、失败(Failed)和未知(Unknown)才是财务与产品团队需要深入复核的核心列。

提交数仅是过程痕迹，而非结算指标

接收发送仅证明传输链路接收了该任务，并不代表终端手机接收到了短信。如果您的报表包将提交数作为核心 KPI，那么每当未知或失败状态的比例上升时，您都会严重高估成功率。如果需要，可以将提交数保留为吞吐量指标列，但决不能将其作为已送达的替代指标。

建立规范的结算复核流程：首先查看 DLR 列——未知、失败、已送达——然后再查看提交数以了解整体发送总量。产品发布复核也应遵循完全相同的顺序，防止营销团队在周中随意重新定义成功标准。

导出列必须基于回执状态

报表导出模式必须明确定义回执状态。已送达必须具备 DLR 证明。失败必须具备明确的终态失败信号。未知状态在收到确切回执之前始终保持为未知，绝不能将其默认为软性送达。在结算周将未知状态隐匿于成功数据中，势必引发关于未知份额未送达的剧烈争议。

当分段计算与实际账单出现不符时，应从具备回执支持的行数据及其分段计数入手，而不是用总提交数乘以估算的大致分段数。短信账单周的分段路径必须保持严谨，报表系统应坚决拒绝将提交数混淆为已送达。

依据相同回执核对 Webhook 与账本

针对账本导出开展 Webhook 审计核对，是证明报表真实可靠的关键手段。每日 Webhook 日志、DLR 状态与预付费账本明细必须保持逻辑一致。如果 Webhook 显示失败而报表显示成功，说明报表逻辑存在错误——应当修复导出逻辑，而不是随意调整钱包余额。

保持日常例行审计工作：按日对齐 Webhook 回执、账本导出与报表包中的消息 ID。发现缺口交由运维团队排查，虚假的成功数据则退回给架构负责人修正。

坚决拒绝基于提交数的账单周结算

任何仅凭提交数量进行计费或总结的结算行为都应被立即终止。重新重构报表包，促使财务团队围绕已送达和未知份额进行透视分析。如果合作伙伴合同中仍沿用'成功 API 提交'等措辞，请在技术层面将其转换为 DLR 附注，切勿为了迎合不恰当的措辞而扭曲报表数据列。

从 IOSOR 开始

在 IOSOR 控制台打开本周报表包，确认每个头条 KPI 都按 DLR 回执（delivered、failed、unknown）统计，而不是 submit 或 API accept。若图表仍把 submit 当成成功，先改名或删掉再关账。导出一次，让产品和财务共用同一套回执列。

IOSOR 要点

报表以 DLR 回执收口：delivered、failed、unknown，不是 submit。submit 只衡量吞吐，不能当送达真相，也不能用来吵账单。

要做：锁定一份回执字段导出。不要：产品庆祝 accept，财务却拿 failed DLR 对账。

这篇指南有帮助吗？