金额勾稽是什么
金额勾稽用「总额 → 维度分类 → 单据明细」三级核对：先看总数对不对，再按渠道、日期、商户等维度看分类合计对不对，最后把差异落到具体单据。它比单纯的准确性规则更贴近业务：总额对了不代表分类对了，分类也对了仍可能有单据级错配。退款、优惠、手续费的计算规则必须在开始对账之前就对齐，否则差异的大部分解释成本都花在口径争论上。
基本信息
| 核对层级 | 总额 → 维度分类合计 → 单据明细三级下钻 |
|---|---|
| 口径前置 | 含不含退款、优惠如何分摊、手续费归属方需先书面确认 |
| 阈值 | 绝对差（元）+ 相对差（万分比）双阈值判定 |
| 输出 | 差异金额、差异率与差异单据清单 |
| 执行节奏 | 日核对为主，月结时与财务口径再做一次；节假日单独约定 |
| 归属 | 每个对账项明确责任人，差异必须闭环关闭 |
典型使用场景
- 业务与财务核对：业务侧统计的收款金额与财务账单总额比对
- 渠道对账：各支付渠道流水合计与渠道方提供的对账文件逐条核对
- 分层核对：汇总表与明细表金额逐日比对，确认加工过程无误
- 退款与优惠专项：退款、优惠券、积分抵扣的金额影响单独核对
- 结算前校验：结算或分账前的金额勾稽，避免错误结算
总分核对（总额级）
总分核对（总额级）
SELECT t.stat_date, t.pay_amt AS dw_total, s.pay_amt AS src_total,
ROUND(t.pay_amt - s.pay_amt, 2) AS diff,
ROUND((t.pay_amt - s.pay_amt) / NULLIF(s.pay_amt, 0), 6) AS diff_rate
FROM ads_trade_pay_daily t
JOIN src_pay_bill_sum s ON t.stat_date = s.stat_date
WHERE t.stat_date = '2026-10-11';维度分类核对与单据定位
维度分类核对与单据定位
-- 第二级：按渠道核对分类合计，找到差异集中的渠道
SELECT t.pay_channel, t.pay_amt AS dw_amt, s.pay_amt AS src_amt,
ROUND(t.pay_amt - s.pay_amt, 2) AS diff
FROM (SELECT pay_channel, SUM(pay_amt) AS pay_amt FROM ads_trade_pay_daily
WHERE stat_date = '2026-10-11' GROUP BY pay_channel) t
FULL JOIN (SELECT pay_channel, SUM(pay_amt) AS pay_amt FROM src_pay_bill
WHERE stat_date = '2026-10-11' GROUP BY pay_channel) s
ON t.pay_channel = s.pay_channel
WHERE ABS(COALESCE(t.pay_amt, 0) - COALESCE(s.pay_amt, 0)) > 0.01;
-- 第三级：定位到具体单据，交业务确认
SELECT COALESCE(t.order_id, s.order_id) AS order_id,
t.pay_amt AS dw_amt, s.pay_amt AS src_amt
FROM dw_pay_detail t
FULL JOIN src_pay_detail s ON t.order_id = s.order_id
WHERE t.stat_date = '2026-10-11'
AND ABS(COALESCE(t.pay_amt, 0) - COALESCE(s.pay_amt, 0)) > 0.01;常见差异来源
| 差异来源 | 表现 | 处理方式 |
|---|---|---|
| 口径不一致 | 总额差一个稳定比例或固定项 | 先对齐退款与优惠规则，再复核对账 |
| 时间归属不同 | 跨日差异集中在日切前后 | 明确按支付时间还是入账时间归属 |
| 在途数据 | 最新时段总是有差异 | 对账窗口排除在途区间 |
| 源端漏单 | 差异落在固定几笔单据上 | 定位单据后由源端补数并回刷 |
| 精度与舍入 | 小额零星差异 | 统一四舍五入规则与小数位数 |
勾稽差异最终必须落到单据级清单：只报「今天差 3.2 万元」而不给清单，业务方无法确认是真错还是口径解释，问题会一直悬着。
对账口径未对齐就开跑，差异解释成本极高：双方各自按自己的理解核对，最后发现不是数据问题而是规则不同，白白消耗一轮人力。