计费对账规格：容差机制与异常升级

我上线过两套对账系统，又接手过四套。一句话总结：如果你的内部账本跟自己都对不上零，那就是 bug，不是四舍五入问题。容差是留给外部世界的，因为处理商和银行有自己的凑整节奏。规格存在的意义，就是把这条线划清楚，并且在审计压力下稳住。

发布于 2026-03-01 · ✓ 已更新 2026-05-06 · 阅读约 7 分钟 · 作者：Spec Coding 编辑部 · 审校：编辑与事实核查政策

"当日关账"到底意味着什么

大多数团队会说，只要对账任务跑完了，这一天就算关了。这是运维视角的说法，不是规格视角。按规格的定义，一天真正关账要同时满足三件事：每一笔带 payment intent 的订单都处于终态；内部 payments 表里的每一行都要么匹配到一条 settlement，要么带着明确的异常原因；总账分录已经写入并锁定。关账之后，任何资金流动都必须走带日期的调整分录。

只有这样，你才能安全地向商家放款、针对昨天的订单发起退款、或者确认收入。我见过一个团队把"任务跑完"当成关账，结果第二天早上偷偷写了一堆负数调整，原因是处理商推送了一笔迟到的 capture。审计发现得比 CFO 还早。

两个容差，不是一个

我见过最大的规格错误，就是一刀切地用"一分钱"容差覆盖所有场景。这是错的。你需要两个容差，而且它们位于 pipeline 的不同位置。

• 内部账本对内部账本：严格等于 $0.00。payments 表对 orders 表对税务系统，必须分毫不差。如果对不上，就是你自己代码的问题，拿容差盖住它，就是财务团队日后出现"幽灵收入"的起点。
• 内部账本对外部 settlement：分级容差，通常是单行 $0.01、每 1000 笔一批 $1.00。处理商对 FX 和手续费的凑整有自己的节奏。单笔差一分不是 bug，每笔都差一分才是。

把这两个数字都写进规格，并解释为什么。没被财务追到头上的评审者会反对"零容差"这条规则，这时候要顶住。

$127.03 事件

举一个去年的真实案例。一条 Stripe settlement 写着 $127.00，对应的内部 payment 是 $127.03。朴素的对账器看到文件里挂着 $0.05 的缓冲，就标成"在容差范围内"，顺手放过去了。

这三分钱其实是一个税费凑整 bug。我们的算法是先对小计计算税费、按分取整，再求和；而处理商是对行总额算一次税、只凑整一次。六个月下来，14 万笔交易累计漂移了大约 $4,200。每一笔单独看都"在容差范围内"，所以一直没人发现。从这次事件里沉淀下来的规格规则是：容差只适用于处理商手续费和 FX；税费、本金、退款必须对到零，否则直接进异常队列。

异常队列要分家，每一类都要有自己的 playbook

单一异常队列就是一个墓地。我要的是四个队列，每个都有自己的 on-call runbook 和老化 SLA：

• 时序异常（Timing）。内部已有 charge，但 settlement 还没到。自动解决窗口：5 个工作日。超过就升级。
• 缺失异常（Missing）。有 settlement 行，找不到内部记录。这类最吓人，必须 24 小时内排查；它们经常对应丢失的 webhook 或者一个去重 bug。
• 重复异常（Duplicate）。同一个外部 reference 匹配到两条内部记录，或反过来。通常是重试 bug。先冻结相关代码路径，等根因定位再放开。
• 金额差异异常（Amount-diff）。两边都有记录，但金额对不上。按数额分桶：fee 行上的 $0.05 以下，大概率是处理商凑整；principal 行上哪怕只差一分，也是 bug。

两两对账，而不是一个大 join

规格应该明确列出四个对账数据源，并描述它们两两之间的关系。在我做过的系统里，这四个源是：处理商 settlement 文件、内部 payments 表、内部 orders 表、税务系统。不要试图用一个 SQL 把四张表 join 起来，而是跑三个两两对账任务。

• Payments 对 Orders。每一笔已 capture 的 payment 对应唯一一个订单，金额一致。
• Payments 对 Settlement。每一笔 payment 都要在迟到窗口内出现在某个 settlement 批次里，否则进入 timing 队列。
• Orders 对 Tax。每个订单的税费行要与税务系统在同一周期的登记负债一致。

如果这三对都平了，四方对账自然也成立。如果其中一对跪了，你立刻知道是哪个接口出了问题。而一个大 join 只会告诉你"某片行海里有问题"。

FX、迟到和拒付

多币种会带来三个大家习惯回避的规格问题，必须显式回答：用哪个汇率，mid-market 还是处理商报价？用哪个时间戳，capture 还是 settlement？滑点由谁承担，商家还是平台？我的默认答案是：用 settlement 时间的处理商报价汇率；平台吸收 10 个基点以内的滑点；超出部分进 FX 异常队列。

迟到是另一只野兽。第 N 天授权的 charge 可能因为处理商积压，到第 N+3 天才 settle。规格必须定义迟到窗口（我用 7 个自然日），并约定第 8 天的行为：不再自动匹配，必须人工审核。这里你不写清楚，早晚有哪个新来的工程师会用一个沉默的 timeout 加一个静默的数据丢失 bug 替你定义掉。

拒付和争议不属于日常对账。它们走的是另一条时钟，应该对接争议系统走独立流程。把它们塞进日常对账，就等于把一个"每日"任务变成永远关不干净的任务。

$47 的水头，谁有权冲掉？

任何对账系统最终都会留下一点谁都解释不清楚的残差。规格必须回答：谁有权把它核销掉？我的规则是：每月聚合金额在 $10 以下，由对账负责人直接核销，但必须附带一个有记录的原因代码；$10 到 $500，需要财务审批；超过 $500，必须发起事件、写根因报告，然后才能入账核销。任何核销都要配一条带日期的日记账分录和一个具名审批人。这件事听起来很无聊，但却是审计最在意的唯一一条条款。

真正能报警的可观测性

四个指标，每日发布：

• 匹配率（Match rate）：首轮自动匹配上的 settlement 行占比。目标 99.5% 以上。一夜之间掉半个点就是 P1。
• 异常老化（Exception aging）：按队列和在途天数统计的未结异常数量。如果 timing 异常超过 5 天的数量还在增长，说明 settlement 推送环节卡了。
• 自动解决率（Auto-resolve rate）：在 SLA 窗口内不依赖人工就自动结清的异常比例。这个比例下滑，通常是新 bug 的早期信号。
• 核销体量（Write-off volume）：每周核销的金额。应当长期保持平稳且数额极小。一旦冲高，几乎必然是有人在拿核销盖新 bug。

验收标准

- Given a processor settlement file for 2026-04-16
  And all internal payments for that settlement date
  When the daily reconciliation job runs
  Then every settlement line matches an internal payment within $0.01
  And every internal payment is either matched or routed to a named exception queue
  And the internal payments-to-orders pair reconciles to exactly $0.00
  And the day is marked closed only if all three conditions hold

- Given an amount-diff exception of $0.03 on a principal line
  When the reconciler evaluates tolerance
  Then the exception is NOT auto-resolved
  And it is routed to the amount-diff queue with a 24-hour SLA

- Given a settlement line that arrives 8 calendar days after the capture date
  When the late-arrival matcher runs
  Then the line is flagged for manual review
  And it does NOT auto-match even if the amounts agree

这些条款是我希望在任何人动手写 SQL 之前就签字确认的。如果评审会上大家连这些条款都谈不拢，那这套系统就还不具备开建条件，哪怕架构图画得再漂亮也没用。

异常队列要比对账差异更早设计

对账规格不只是在每天结束时算差额。真正麻烦的是差额出现后谁处理、怎么暂停、如何重跑、多久关闭。没有异常队列，系统会把财务工作丢给 Slack。

Reconciliation exception:
- exception_id: rec_20260428_usd_001
- source_balance: processor=103442.18
- ledger_balance: internal=103441.92
- delta: 0.26 USD
- tolerance: 0.10 USD
- owner: finance-ops
- system action: pause payout batch for USD
- close condition: adjustment entry approved or processor correction received

边界：容差不是“差不多就行”。低于容差可以自动记录，高于容差必须有 owner、状态和关闭证据。

异常关闭也需要证据

异常队列里最危险的状态不是 open，而是被随手 close。规格要要求关闭原因、调整分录、审批 owner、截图或 provider reference。没有这些字段，下一次月结还是会把同一个差额翻出来重新查。

对账表还要记录 source、currency、statement_date、owner、resolution_status 和 evidence_url。API 可以很简单，但内部状态不能省。否则金额对上了，没人知道是谁关的异常、凭什么关。

我会要求异常记录里有 idempotency_key，防止同一 provider statement 被重复导入。测试要覆盖重复导入、币种不一致、日期跨区、手动调整和回滚。每个用例都断言 reconciliation_status、owner、evidence_url 和 ledger_adjustment_id。

可复制产物：契约评审包

当工作涉及 API 行为、schema、事件、重试或消费者预期时使用。它会把兼容性和发布证据提前摊开。

API 契约评审包：计费对账规格：容差机制与异常升级

本次要做的决策：
- 确认契约变化是否兼容，消费者需要什么迁移动作，发布后如何观察风险。

责任人检查：
- 产品责任人：
- 工程责任人：
- QA 或运维评审：

范围边界：
- 本次包含：
- 本次不包含：
- 仍需确认的假设：

验收证据：
- 测试或 fixture：
- 日志、指标或截图：
- 人工复核步骤：

契约边界：没有兼容性分类、消费者影响、重试行为和回滚说明，不进入发布。

评审追问：
- 没参加需求会的人还会误解哪里？
- 哪个证据能证明这次改动足够安全，可以发布？

编辑复核记录

复核日期：2026-04-28。本次补充了可复用产物，按相关主题 Hub 检查了文章定位，并收紧下一步链接，让页面更像可操作参考，而不是孤立长文。