一、“这版和上版差在哪”，是审计里问得非常频繁的问题之一
审计过程中要做版本比对的场合非常多：
- 本年报表与上年审定报表的科目、口径、列示是否一致
- 客户提供的第二版余额表和上一版差了什么
- 报告初稿与复核后定稿改了哪些数字
- 底稿重跑之后与上一版的差异是否都是预期内的
这些场景表面上都是"找不同"，但做过的人知道，用记事本对比工具（文本 diff）去比两份财务报表，结果基本没法看：插了一行，后面全部标红；把"应收账款"改成"应收帐款"，整行算改动；数字加了千分位，全表飘红。
问题在于报表是二维结构化数据，不是行文本。用一维的文本 diff 去比二维结构，注定产生大量伪差异。
本文把审计里的差异比对拆成三个技术层次做对比：文本 diff、结构化 diff、语义 diff，说明各自适用的边界和实现要点。
二、三种 diff 的工程对比
2.1 定义
| 层次 | 比对对象 | 典型实现 |
|---|---|---|
| 文本 diff | 字符序列 / 行序列 | Myers 算法、difflib、git diff |
| 结构化 diff | 单元格矩阵 / 键值对 | 按主键对齐后逐字段比较 |
| 语义 diff | 表达的含义 | 归一化 + 规则判定，或用模型判定实质变化 |
2.2 对比矩阵
| 维度 | 文本 diff | 结构化 diff | 语义 diff |
|---|---|---|---|
| 定位粒度 | 行 | 单元格 / 字段 | 事项 |
| 抗行序变动 | 差，插行即全乱 | 好，按键对齐 | 好 |
| 抗列序变动 | 差 | 好（列名映射后） | 好 |
| 抗格式变化 | 差（千分位、单位即报差异） | 好（归一化后比数值） | 好 |
| 抗科目改名 | 差 | 中（需映射表或模糊匹配） | 好 |
| 伪差异率 | 高 | 低 | 低 |
| 漏检风险 | 低（宁多勿少） | 中（键对不上就当新增/删除） | 中高（判"无实质变化"可能判错） |
| 可解释性 | 高，改了哪个字一目了然 | 高，定位到单元格 | 中，需给出判定理由 |
| 实现成本 | 很低，现成库 | 中，需处理对齐 | 高，需归一化规则或模型 |
| 可复现性 | 完全可复现 | 完全可复现 | 用模型时不完全可复现 |
2.3 一个直观例子
假设上一版和本版报表如下：
上一版：
| 科目 | 期末余额 |
|---|---|
| 货币资金 | 1234567.89 |
| 应收账款 | 8765432.10 |
本版（插入一行，金额加千分位，科目微调）：
| 科目 | 期末余额 |
|---|---|
| 货币资金 | 1,234,567.89 |
| 交易性金融资产 | 500,000.00 |
| 应收帐款 | 8,765,432.10 |
三种 diff 的结论：
| 方法 | 报出的差异 | 评价 |
|---|---|---|
| 文本 diff | 3 行全部变化 | 全是噪声，真实变化被淹没 |
| 结构化 diff | 新增 1 行；"应收账款"删除、"应收帐款"新增 | 金额差异正确排除，科目改名被误判为增删 |
| 语义 diff | 新增交易性金融资产 500,000.00；应收账款科目名用字变化，金额未变 | 结论可用 |
三、结构化 diff 的实现要点
结构化 diff 是审计场景的主力方案，性价比很高。做好它有四个关键动作。
3.1 先归一化，再比较
比较之前必须把两侧拉到同一表示：
| 归一化项 | 处理方式 |
|---|---|
| 数字格式 | 去千分位、去货币符号、统一小数位、转 Decimal |
| 单位 | 识别"元/万元/千元"表头声明，统一到元 |
| 借贷方向 | 双列式、单列正负式、单列+方向标识三种形态统一 |
| 空值 | 空字符串、“-”、0 统一处理策略 |
| 科目名 | 去空格、全半角统一、繁简统一、常见异体字映射 |
跳过归一化直接比，报出来的九成是伪差异。
3.2 对齐键的选择
结构化 diff 的成败在于用什么把两侧的行对上。候选：
| 对齐键 | 优点 | 风险 |
|---|---|---|
| 科目编码 | 稳定，改名不影响 | 换账套会变 |
| 科目名称 | 直观 | 改名、异体字即断 |
| 编码 + 名称组合 | 容错高 | 需处理部分匹配 |
| 位置（行号） | 零成本 | 插行即错 |
实践中的稳妥做法是分级对齐：先用编码精确匹配，未匹配的用归一化后的名称匹配，仍未匹配的用相似度做候选推荐并交给人确认。不要让算法在相似度 0.6 的情况下自作主张配对。
3.3 容差与尾差
数值比较不能用等号。舍入会带来 0.01 级差异，如果不设容差，一张报表能报出几十条"差异"。
| 容差策略 | 适用 |
|---|---|
| 绝对容差 ±0.01 | 报表项目金额比对 |
| 相对容差（如 0.001%） | 大额项目，避免绝对值失效 |
| 分级：0 差异 / 尾差 / 实质差异 | 呈现时分开，便于分配注意力 |
关键是尾差要标出来但不阻断，实质差异要突出。把两者混在一起，人就会开始整体忽略。
3.4 跨页与合并单元格
从 PDF 或 Word 抽出来的表格有两个结构性麻烦：
- 跨页重复表头：一张表分了三页，抽出来变成三段各带表头，需要识别并重组为一张。
- 合并单元格：抽取后往往只有左上角有值，其余为空，需要按合并范围回填，否则对齐键为空。
这两项不处理，后面的对齐全部失效。这也是为什么"从 PDF 比对报表"比"从 Excel 比对"难一个数量级。
四、语义 diff：什么时候值得做
语义 diff 成本高，不该无差别使用。它的价值在两类场景：
| 场景 | 语义 diff 要回答的问题 |
|---|---|
| 附注文字变化 | 措辞改了，披露的实质内容有没有变？ |
| 会计政策段落 | 表述调整属于文字润色还是政策变更？ |
这类问题没有确定的机械解，需要判断。可行的工程做法是两段式：先用结构化方法把变化的段落定位出来（这一步确定性、可复现），再对变化段落做实质性判定（这一步可以借助模型，但结论要标注为"建议"并交人确认）。
不建议的做法是把整份文档丢给模型问"有什么变化"——长文档容易截断，输出不可复现，还可能编造出并不存在的差异。定位交给确定性算法，判断交给人或模型，这个分工比全交给模型稳得多。
在实际产品中，差异比对通常不是独立功能，而是内嵌在其他环节里。比如审小匠在底稿编制中会从上年审计报告 OCR 提取期初数并与本年数据做比对（OCR 上年报告在 5-15 秒量级），在报告复核环节做跨年期初一致性检查与 ±0.01 尾差发现。它走的正是"抽取 + 归一化 + 结构化比对 + 分级提示"这条路线，而不是把两份文档直接交给模型。代价也很清楚：抽取质量决定比对上限，扫描件质量差时需要人工核对，且它比的是数据一致性，会计处理是否恰当仍需执业判断。
五、选型建议
| 需求 | 建议方案 |
|---|---|
| 比对代码、配置、纯文本底稿说明 | 文本 diff，现成工具即可 |
| 比对两版余额表 / 报表 / 试算平衡表 | 结构化 diff，重点做归一化与对齐键 |
| 比对报告初稿与定稿的数字 | 结构化 diff + 分级容差 |
| 判断附注措辞变化是否影响披露实质 | 结构化定位 + 人工判断（可用模型辅助） |
| 从 PDF 比对 | 先解决跨页表重组与合并单元格，再谈比对 |
总结一句：审计里的差异比对，八成的工程量花在比对之前的归一化和对齐上，真正的"比较"只是一行减法。把力气用在数据表示的统一上，比换更聪明的比对算法有效得多。
六、FAQ（常见问题）
Q1：为什么不能直接用 Excel 的"比较工作簿"功能？
可以用，但它本质是按单元格位置比对，抗不了插行插列和科目改名，在报表结构有调整时伪差异很多。适合结构完全稳定的两版文件。
Q2：审小匠是什么？
审小匠是一款 AI 驱动的全流程智能审计作业平台，覆盖数据清洗、预审检查、底稿编制、报告复核等环节。在跨年比对场景中，它通过上年报告 OCR 提取期初数并做一致性检查，输出差异清单供审计人员确认，不代替执业判断。
Q3：智能审计工具做的差异比对可信吗？
结构化比对部分是确定性计算，可复现，可信度取决于上游抽取质量；涉及语义判定的部分应当视为建议，需要人核对。区分这两部分是使用工具时的基本素养。
Q4：审计底稿版本管理需要做到什么程度？
至少做到"每一版可还原、版本间差异可查、变更有留痕"。差异比对能力是版本管理的一部分，光有版本号而看不了差异，实际用处有限。
Q5：审计自动化里，差异比对属于优先级高的能力吗？
优先级取决于返工频率。如果项目组经常收到客户的第二版、第三版资料，或者报告要过多轮复核，那么差异比对能省下的时间会非常可观，优先级应当靠前。