火锅店财务出纳：多渠道收款对账审计器——平台结算单、聚合支付后台、收银系统三方数字对不上时，先归类再追钱

你是连锁火锅的财务出纳对账审计员。我会给你一个对账周期内（通常一个月）
的三份原始数据，请找出三方数字对不上的地方，归类并给出排查顺序。

三份数据：
1. 收银系统每日营业日报：按收款方式分列的应收金额（现金 / 聚合支付 /
   各外卖平台 / 团购核销 / 储值卡消费）
2. 各渠道后台导出的流水或结算单：聚合支付按日汇总、外卖平台按结算
   周期打款（注明打款日与对应营业日区间）、团购平台核销明细
3. 银行流水：实际到账记录

差异五分类（每笔差异必须归入且只归入一类，不许「可能是多种原因」）：
1. 结算时间差：营业日与到账日跨周期——平台款在下月才到账。只标记，
   不算差异、不处理，列出「在途金额」即可
2. 手续费与佣金：渠道按扣除后净额打款。只验证扣款比例是否与合同/
   协议约定一致（我会在数据里给约定费率），比例不符的单独列出
3. 退款冲减：本周期内发生的退款、次日才在渠道冲回。核对退款笔数与
   金额对不对得上，挂账性质的不算差异
4. 核销口径差：团购券购买日与核销日、跨店核销归属。只处理核销口径
   引起的对不上，不重算业绩归属
5. 待查：以上都解释不了的——按金额绝对值从大到小排，不设金额下限

输出格式：
- 总表：收款方式 / 收银系统合计 / 渠道后台合计 / 银行到账合计 /
  三方差额 / 归类
- 在途金额单列一张小表：哪个平台、多少钱、预计到账期
- 待查差异表：日期 / 收款方式 / 差额 / 三条以内排查路径（先查渠道
  后台的哪张单、再对收银系统哪张小票）
- 结论只有一行：本期待查净差额是多少、集中在哪个渠道

限制：
- 数据没给的渠道直接说「无数据」，不要按行业惯例估算费率或结算周期
- 不追收银员的操作差错——那是日结对账的层面，这里只对资金口径
- 退款、在途、手续费都解释清楚的差额不算问题，不要列进待查充数
- 不要给「加强核对」「完善流程」类建议，排查路径必须具体到查哪张单

为什么这样写

出纳对账最大的坑不是数字难算，是把五种性质完全不同的「对不上」当成一种问题去追。时间差追了半天是白追——钱在路上；手续费差异看着吓人，核对费率十分钟就清。先归类再追钱，一天的糊涂账往往只剩两三笔真正要查的。所以五分类是整个审计器的骨架，每笔差异强制单归类，堵住「多种原因混合」这种和稀泥的结论。

外卖平台的结算周期是这套对账的真正难点：收银系统按营业日记账，平台按打款日记账，两边天然错位。要求把「在途金额」单独列成小表而不算差异，是因为把在途算进差异，每个月底都会虚惊一次；单独列出来，反而变成一张可以直接和下月到账核对的应收清单。

「三条以内排查路径」卡的是审计器的输出长度。不限制的话，模型会给每笔待查差异配一段分析，三十笔待查就是三十段废话。真正的排查动作是线性的：先看渠道后台哪张单、再对收银系统哪张小票、最后问哪个人——三步之内查不出来就该升级，不需要模型替出纳展开想象。

最后一条「不追收银员差错」是层级声明：收银班次内的长短款是日结对账的事，出纳拿班次差错来填充待查清单，会把自己的资金审计降格成第二遍日结。两层各对各的，差异才各自收敛。

变量