清算算完不等于算对了。日终批量产出的应收应付净额，下一步是拿去和权威来源对账：交易所的成交回报、中国结算的清算文件、银行的资金余额。对不上就两个可能——我算错了，或者对方发错了，或者两边都没错但口径不同。账实核对的目标不是"对平"这个动作，而是在交收动真钱之前，把任何差异都解释清楚。
三层校验：从粗到细的成本梯度
核对按粒度分三层，成本递增、覆盖度递增，系统设计要按这个梯度排布：
总额核对（总对总）：我方计算的法人层面资金收付总额，对中登清算文件里的资金总额；证券总量同理。一行 SQL 的事，秒级完成。总额不平说明有大问题——文件收漏了、主体范围算错了、币种漏转换——这层不通过后面两层不用跑。
明细核对：按"证券账户 × 券种"和"资金账户 × 科目"逐条比对我方明细与对方明细。这是工作量最大的一层，双方的数据模型不完全同构（中登按托管单元，我方按客户），比对前要做映射和归并。明细核对抓的是总额核对抓不到的错：两笔方向相反的差错在总额里抵消，在明细里现形。
总分勾稽：回到内部——客户明细账的加总，对法人层面的总账。这是《法人清算与二级清算》里那条守恒律的日常化：$\sum \text{客户明细} = \text{法人总额}$。它核的不是"和外部对不对"，而是"我自己内部碎没碎"，两层都有，缺一不可。
三层的关系是：总额是闸门（不过就熔断），明细是主体（主要工作量），勾稽是保险（防内部撕裂）。任何想跳过明细只跑总额的方案，本质是在用低成本换取高风险敞口——总额平了而明细错行的案例在生产里反复出现。
差额归因：先分层，再分类
对不平的差额怎么处理，决定了一个清算团队的成熟度。我见过的有效方法论是两步：
第一步，定位差异所在层。把差额按三层校验逐层分解：总额差多少、明细差多少笔、勾稽差多少。三层差额有结构性含义——只有总额差、明细全平，几乎必然是口径问题（比如对方含上了某笔手续费而我方不含）；总额平、明细差几笔，是典型的漏记/重记；勾稽不平而对外全平，是内部分摊逻辑错了。
第二步，区分数据错还是逻辑错。数据错是单笔流水的问题——文件解析错位、某条记录被过滤条件误杀，修复方式是重放那笔数据，让流水重走一遍正确的处理逻辑；逻辑错是算法或规则的问题——费用舍入方向、分红口径，修复方式是改逻辑重跑，并且要把"错误版本影响哪些天"算清楚。混淆这两类的代价极高：用改数据的方式修逻辑错，等于给审计留一个无法解释的手工痕迹；用改逻辑的方式修数据错，则是杀鸡用牛刀还惊动了全部历史。
挂账与追平：允许带着差异前进吗
原则性答案是：不允许带着未解释的差异进入交收。但生产里会遇到对平需要数小时、而交收有截止时间的冲突，这时候的折中是挂账——把差异金额记入专门的待查挂账科目，客户账和法人账先按已解释部分推进交收，挂账部分由专人跟进追平。挂账合法的前提有三个：金额有上限阈值（超过阈值必须熔断等人工）、台账逐笔记清（哪边多、差多少、初步归因）、有明确的追平时限和升级路径。挂账是缓冲区不是垃圾桶，很多清算事故的起点都是"先挂一下"挂到忘了。