对账表应该如何设计？支付和订单金额不一致怎么排查？

简化版

对账表用于记录业务系统、支付渠道、财务系统之间的账务差异和处理状态。设计重点是保留双方原始单号、金额、状态、对账批次、差异类型、处理状态和审计记录，不能只靠覆盖业务表来“修平”差异。

详细版

支付场景里，订单系统认为支付成功 100 元，渠道账单可能显示 99 元、退款中、重复扣款或没有这笔记录。对账表就是把这些差异显式记录下来，供自动修复或人工处理。

常见字段包括 reconcile_batch_no、biz_order_no、channel_order_no、biz_amount、channel_amount、diff_type、status、handled_by、handled_at、remark。

对账设计要强调幂等导入、批次可追溯、差异不可静默删除、处理动作留痕。它是账务系统的安全网。

完整版教学

一、为什么需要对账表

在理想世界里，订单、支付渠道、财务系统每条数据都一致；现实里网络超时、回调丢失、重复通知、人工退款、渠道结算延迟都会制造差异。

如果没有对账表，差异只能散落在日志、人工 Excel 或直接改业务表中。这样既难追溯，也容易越改越乱。

对账表的作用是把“发现差异、确认差异、处理差异”的过程结构化。

二、对账表要保存双方事实

对账不能只保存一个最终结果，要保存业务侧和渠道侧各自的原始事实。否则后续无法解释差异来自哪里。

CREATE TABLE payment_reconcile_diff (
  id BIGINT PRIMARY KEY,
  batch_no VARCHAR(64) NOT NULL,
  biz_order_no VARCHAR(64) NOT NULL,
  channel_order_no VARCHAR(64),
  biz_amount DECIMAL(18,2),
  channel_amount DECIMAL(18,2),
  diff_type VARCHAR(32) NOT NULL,
  status VARCHAR(32) NOT NULL,
  handled_at DATETIME,
  remark VARCHAR(255),
  UNIQUE KEY uk_batch_biz (batch_no, biz_order_no)
);

这里 batch_no 很重要，因为每天、每渠道、每账期都要可追溯。

三、差异类型要分类

差异不是简单“不一致”。常见类型包括金额不一致、业务有渠道无、渠道有业务无、状态不一致、重复支付、退款差异。

差异类型	示例	处理方向
金额不一致	业务 100，渠道 99	人工核查或冲正
业务有渠道无	订单成功但渠道无账	查回调和支付状态
渠道有业务无	渠道扣款但无订单	补单或退款
状态不一致	业务失败渠道成功	修正业务状态

分类越清楚，自动处理和人工排查越容易。

四、导入和处理必须幂等

渠道账单可能重复下载，定时任务可能重复执行。如果导入不幂等，就会生成重复差异。

可以用 (batch_no, channel_order_no) 或 (batch_no, biz_order_no) 做唯一约束。处理差异时也要用状态机，避免同一差异被处理两次。

数字例子：每天 100 万笔支付，差异率 0.05% 就是 500 条。如果重复导入 3 次没有唯一约束，人工处理池会膨胀到 1500 条，排查成本直接翻倍。

五、不要静默改业务表

发现差异后，不能直接 update 订单金额或支付状态就结束。账务系统要求每一步都有依据：谁发现、谁处理、依据是什么、改了哪里。

正确做法是对账表记录差异，处理表记录动作，业务表做必要修正，并保留关联单号。必要时生成冲正单、退款单或补单。

这不是流程繁琐，而是为了满足财务可追溯和事故复盘。

六、常见误区与追问

误区：对账就是每天跑 SQL 比一下。 SQL 比对只是发现差异，对账表还要承载处理状态和审计。
误区：差异修完就可以删除记录。 差异记录是审计证据，应保留批次和处理痕迹。
误区：只看金额一致就没问题。 状态、手续费、退款、渠道单号也可能不一致。
追问：如何避免重复导入账单？ 用批次号和渠道单号建立唯一约束，导入任务幂等。
追问：渠道有支付但业务无订单怎么办？ 先核查请求链路，可能补单、退款或进入人工处理。

七、加强记忆

记忆钩子：对账表不是橡皮擦，而是账务差异的病历本；病好了也要留下诊断、用药和复查记录。

回答这题时突出“双方事实、差异分类、批次追溯、幂等导入、处理留痕”。这能体现你理解财务类数据库设计的严肃性。

简化版

详细版