面向财务与产品的钱包月末 02:00 导出

月末 02:00 会失败——若财务打开三个文件、产品打开第四个。预付需要一份共享导出：钱包上每一笔 hold、debit、release、refund，外加解释 burn 的通道组合，且没有平行「真相」。若 cutoff 文件答不出「动了什么、为何而动」，早晨就是工单风暴。

IOSOR 是 white-label prepaid。一个账户承载 messaging、verification、email、voice 与 JIT 号码意图。USD 20 在试点流量上证明导出可用；接近每月 USD 1,000 的 soft review 抬高脏关账的代价。通道邻居：财务导出的 Verify 会话关联与语音计费取整与接通费导出。本页是钱包级月末文件。

为何 02:00 需要一个共享故事

一个时区、一个 cutoff。财务与产品读同一快照——不是「ops 稍后对账」。02:00 之后的行属于下一期间。无冻结的局部窗口产生重复计数与幽灵退款。写明任务负责人、文件位置，以及规则：迟到的 outcome 更新状态，不改写已结算资金。

把关账与日常诚实配对：同一账本上的扣款行与送达状态——月末是汇总，不是资金与结果的第一次见面。

财务与产品都信任的列

可辩护的 02:00 文件最低列：

缺任一列就会发明 join。一份 CSV 优于聊天转储。

Holds、扣款、退款在同一文件

Cutoff 时开放 hold 仍为 reserved，不是自由 available。Settled debit 显示金额与通道。Release 与 refund 链接到原 intent。自动退回资金的失败路径——预留失败时的自动退款与状态真相——显示为显式行，而非静默改余额。成功路径：首次扣款前的预付资金预留。

切勿把 refund 折叠成「负向 send」。移动类型保持显式，审计才能重放整月。

无品牌泄漏的通道组合

导出使用客户端已见标签：SMS、voice、email、verify、numbers——绝不写上游品牌或成本底线。Mix 回答哪条队列烧了钱包，而非哪条履约路径。Caps 姿态旁置：流量离开试点后的多通道钱包上限；文件需要诚实的通道标签与金额。

Verify 会话数学与 voice 取整留在邻居文。钱包月末只需这些通道已结算的单位。

Cutoff 前的运维清单

1. 时区与 02:00 cutoff 是否书面指定负责人？
2. 开放 hold、settled debit、release、refund 是否全部出现？
3. 财务能否把每笔 refund 接到原 intent ID？
4. 文件中的客户端标签是否品牌安全？
5. Stop-lines 是否匹配本期间？查阅 生产流量前的钱包止损线。
6. 支出控制是否用 预付费支出控制 文档化？

从 IOSOR 开始

在 IOSOR 控制台中安排 02:00 UTC 的自动快照，为财务和产品团队映射准确的导出目标位置。在计划的导出窗口运行之前，确保意图标识符以及保留、借记、释放和退款等变动类型已明确映射。设置 Webhook 警报，以便在任何未分配的分类账变动试图跨越截止边界写入时通知工程团队。

IOSOR 要点

让财务和产品团队围绕统一的 02:00 月末导出保持一致，能够消除微秒级的会计差异和幽灵退款。在统一的关联标识符下规范化保留、借记和释放操作，可为两个部门提供一个经得起推敲的分类账，同时不会泄露敏感的内部路由数据。

务必在 02:00 实行严格的截止时间并明确负责人归属，将未结的保留项在导出报告中保持在预留状态。切勿依赖运营与财务之间手动的事后对账，也不要将内部成本结构泄露到面向客户的渠道组合摘要中。