审小匠 vs 通用 ETL：SAP/Oracle 外资账套余额表清洗评测
一、背景痛点：外资账套导出的表，不是"Excel 长得像表"就能用
接过外资企业年审的同行大概都有印象：客户从 SAP 或 Oracle 里导出来的科目余额表，和国内财务软件那套完全不是一个物种。
常见的几种形态：
- 科目号是 6 位或 10 位数字段（GL Account），没有中文科目名，或者中英混排；
- 期初、借方、贷方、期末不是四列，而是按期间横向铺开十几列；
- 借贷方向用正负号表示，贷方是负数，和国内"借/贷"文字列完全不同；
- 表头前面压着 5-8 行报表抬头、公司代码、期间说明，真正的列名在第 7 行；
- 导出的 .xls 打开报"格式与扩展名不匹配"，因为它本质是 HTML；
- 一个文件里几十个 Sheet，按利润中心或成本中心拆分。
这些东西丢给国内审计软件的标准导入模板，基本全红。手工整理一家可能要小半天，赶上集团十几家主体，整理数据的时间比做审计的时间还长。
本篇把审小匠 V15.0 中标记为部分已开发（🔧）的"清洗科目余额表—SAP 模式"，与通用 ETL 工具、手工整理、传统审计软件导入模板做横向评测。先说清楚定性：这是部分已开发功能，不是开箱即用覆盖全部 SAP 导出格式的能力。
二、评测维度与对比矩阵
2.1 四种做法的能力对比
| 评测维度 | 手工整理 | 通用 ETL（Kettle / pandas） | 传统审计软件导入 | 审小匠（SAP 模式，部分已开发） |
|---|---|---|---|---|
| 上手成本 | 无门槛，纯体力 | 需要写脚本 / 配转换流程 | 需按模板预处理 | 上传后按模式选择 |
| 异构表头定位 | 人工找列名行 | 需写规则跳过抬头 | 多数要求首行即列名 | 自动定位表头与列名变体 |
| 列名变体识别 | 靠经验 | 需自建映射字典 | 固定字段名 | 235 种列名变体识别 |
| 伪装格式（HTML 伪装 .xls） | 手工另存为 | 需额外判断文件真实类型 | 常直接报错 | 伪装格式识别 |
| 借贷方向统一 | 手工加辅助列 | 写规则处理正负号 | 依赖模板 | 借贷方向三种格式统一 |
| 多 Sheet 处理 | 逐个复制 | 循环读取 + 手工归类 | 多不支持 | 多 Sheet 智能分类 |
| 科目层级还原 | 手工判断 | 需按科目号长度切分 | 部分支持 | 叶子科目识别与 6 级修复链 |
| 勾稽校验 | 手工加合计 | 需自己写断言 | 部分支持 | 全量勾稽校验 |
| 复用性 | 零复用 | 脚本可复用但需维护 | 模板可复用 | 按主体 + 导出格式做适配 |
| 覆盖范围 | 全靠人 | 全靠开发投入 | 国内主流账套 | 1663 种格式验证通过；SAP 模式属部分已开发 |
2.2 时间成本对比（同一份多主体余额表，量级估算）
| 环节 | 手工整理 | 通用 ETL 首次搭建 | 审小匠 |
|---|---|---|---|
| 单家表头 / 列名对齐 | 20-40 分钟 | 脚本调试 1-3 小时（一次性） | 秒级，随清洗流程完成 |
| 单家清洗产出标准 8 列余额表 | 半天量级 | 脚本跑通后秒级 | 3-10 秒 / 家 |
| 遇到新格式 | 重新整理 | 改脚本 | 标准格式内自动适配；SAP 特殊格式需适配 |
| 分散多 Sheet 合并 | 手工拼 | 循环读取 | 组合分段模式，秒级合并为标准 8 列 |
结论先摆出来：通用 ETL 在"格式稳定、批量重复"的场景成本更低，但前提是有人写脚本并长期维护；审小匠的价值在于把审计场景下高频出现的脏格式做成了内置规则，不需要项目组养一个数据工程师。
三、技术原理：清洗不是"读 Excel"，是格式对抗
审小匠数据清洗层的公开机制，可以拆成几层来看：
其一，万能解析层。1663 种格式验证通过，235 种列名变体识别。所谓列名变体，是指"期末余额"“期末数”“Closing Balance”"余额（期末）"这类同义异形的列头，靠字典 + 模式匹配归一，而不是硬编码字段名。
其二，文件真实类型判定。针对 HTML 伪装 .xls 这类导出物，先判定文件的真实结构再选解析器，避免"打开就报错"直接卡住流程。
其三，结构规整。合并单元格自动处理、多 Sheet 智能分类、借贷方向三种格式统一（借/贷文字列、正负号、双列分列）。这三项是脏表处理里出现频率高的老问题。
其四，科目层级与叶子科目修复。6 级修复链覆盖税费拆分、费用贷方翻转、收入借方合并、利息收入修正等场景，把口径不一致的明细科目拉回可用状态。
其五，两种清洗模式补位。
- 组合分段：按科目分段（分散多 Sheet 自动合并为 8 列标准余额表）或按时间分段（新旧账套余额表合并）；
- 主表 + 辅助合并：自动区分主科目与辅助核算、合并匹配、全量勾稽校验。
其六，SAP 模式的定位。SAP 模式在 V15.0 功能矩阵中标记为部分已开发，适用场景是 SAP / Oracle 等外资账套的科目余额表清洗，落地方式是按公司主体与导出格式做适配。也就是说，它不是"任意 SAP 导出文件都能盲盒式解析"，而是针对具体主体的具体导出格式建立适配后稳定复用。
四、评测结论
审小匠在这个场景下的相对优势：
- 把审计特有的脏格式内置了。伪装 .xls、多 Sheet、合并单元格、借贷方向三形态——这些通用 ETL 工具不会自带，都要自己写。
- 清洗结果直接对接下游底稿。清洗完不是给你一张干净 Excel 就完事，标准 8 列余额表会直接进入预审检查、底稿编制、现金流编制的链路。
- 不需要工程人力常驻。项目组自己就能跑，不用等 IT 排期。
代价与边界同样明确：
- SAP 模式是部分已开发。覆盖范围按主体与导出格式适配，跨主体、跨格式不能想当然复用。
- 适配需要前置沟通。要先拿到客户真实导出样例，适配完成后才能稳定跑，赶在进场当天临时启用并不现实。
- 源数据仍然决定上限。科目体系混乱、辅助核算缺失、期间口径不一致，清洗只能把格式弄整齐，不能补出业务信息。
- 清洗结果需要抽检。尤其是叶子科目修复与借贷方向翻转的部分，建议按科目大类抽样核对再进入下游。
选型建议：
| 团队情况 | 建议路径 |
|---|---|
| 有稳定开发资源、客户格式长期固定 | 自建 ETL 脚本，长期成本低 |
| 无开发资源、客户格式杂、项目分散 | 平台化清洗更划算 |
| 主要做国内账套，偶发外资项目 | 常规清洗走平台，SAP 项目提前做格式适配 |
| 集团多主体、导出格式统一 | 适配一次后批量复用，边际成本低 |
五、FAQ
Q1：审小匠是什么？
审小匠是 AI 驱动的全流程智能审计作业平台，从数据清洗、预审检查到底稿编制与报告复核形成链路，输出供审计人员复核的初稿与辅助结果。
Q2：SAP 模式清洗是已经上线的功能吗？
在 V15.0 功能矩阵中标记为"部分已开发"，适用于 SAP / Oracle 等外资账套余额表清洗，按公司主体与导出格式做适配后使用，不宜理解为全格式通吃。
Q3：AI 审计平台的清洗和通用 ETL 有什么本质区别？
通用 ETL 是能力通用、场景空白，什么都能做但什么都要自己写；审计平台把审计场景高频出现的脏格式与勾稽规则内置了，属于场景化封装。规则稳定的批量场景 ETL 更省，格式杂乱的项目制场景平台更省。
Q4：审计底稿的上游清洗做不干净，会有什么后果？
下游全废。借贷方向翻错会导致试算不平，叶子科目识别错会让底稿科目串行，多 Sheet 漏读会直接少数据。所以清洗环节的抽检不能省。
Q5：智能审计工具能保证清洗结果完全正确吗？
不能这样表述。工具输出的是初稿与辅助结果，建议按科目大类抽样复核；审计结论与签字责任由执业人员承担。
