审计数据分析：先说清楚它到底改变了什么
审计数据分析，是指用数据处理工具对被审计对象的全部业务明细逐条执行既定的测试规则，输出疑点清单与命中原因，替代或补充传统的抽样查凭。它改变的不只是覆盖率，更是结论的可核查性：每一条疑点都能倒推回原始记录。
抽样审计的前提，是假设样本能代表总体。但真正的问题往往不服从这个假设：拆分交易恰好都在阈值以下，重复付款分散在不同月份不同供应商，异常时点集中在几个特定日期。这些恰恰是抽样最容易漏掉的部分。国内会计师事务所的公开研究也早已指出，数据分析与持续审计能让审计更有针对性，并在控制测试与交易分析之间取得更好平衡（参见毕马威中国《数据分析及持续审计》，公开资料，2026-09-09 核实）。
难点不在道理，在落地。规则写在制度文档里，执行靠人手工筛 Excel；换个人做，口径就变了；上级追问过程，只能口头解释。iModel 解决的正是这一段：把规则搬进工作流，让它可运行、可复用、可回放。这种工作方式的基本逻辑，见为什么要用可视化工作流。
关键事实
| 适用职能 | 内部审计、稽核、纪检监督、合规与风控、监管报送数据准备 |
|---|---|
| 测试方式 | 全量逐条执行规则，输出疑点清单与命中原因，不做抽样；可与抽样程序并行使用 |
| 已验证操作系统 | 麒麟 V10 / V11、统信 UOS（均为 x86-64 版本）、Windows |
| 已验证处理器 | 海光 C86（x86-64），已测试、已部署。iModel 目前不支持 ARM 架构（鲲鹏、飞腾），相关版本仍在规划中 |
| 数据接入 | 300+ 数据源连接，覆盖主流关系型数据库、Excel 与 CSV 文件、接口取数 |
| 规则建模 | 300+ 内置分析节点，拖拽配置；需要时可嵌入 Python / R 脚本节点处理特殊逻辑 |
| 底稿与留痕 | 每个节点保留输入表、输出表与配置参数，可逐节点回放；同一份数据任何人重跑，结果一致 |
| 交付与移交 | .knwf 工作流文件，与 KNIME 双向通用，可版本化归档、可作为项目交付物整包移交 |
表中信创口径按已实测部署范围填写，未列入的处理器与操作系统请以实际测试结论为准。
审计数据分析：审计人真正卡住的五个环节
工具不解决所有问题。下面这五个环节是我们在项目里反复遇到的，前两个属于组织协调，后三个才是工具能直接改善的。分清楚这一点，项目排期才不会失真。
审计数据分析：四类常用测试与各自的判定逻辑
下表按判定逻辑分类，并列出误报最常见的来源。误报这一列比规则本身更值得看，因为绝大多数项目失去信任，都是从第一批疑点里一半是假的开始的。
| 测试类型 | 判定逻辑 | 常用数据 | 误报通常来自 |
|---|---|---|---|
| 完整性与重复 | 同一笔业务是否被重复记录或重复支付；汇总值与明细合计是否一致 | 付款记录、发票、凭证、供应商主数据 | 正常的分期付款与预付冲销；供应商名称写法不一致导致的漏配 |
| 授权与规避 | 是否存在刚好落在审批阈值以下的拆分交易，或绕过审批路径的记录 | 请购单、采购订单、报销单、审批日志 | 业务本身就按批次下单；阈值在期间内调整过但规则没跟着改 |
| 异常与离群 | 金额、笔数、频次相对同类记录显著偏离；出现罕见的科目与对手方组合 | 总账、明细账、费用与报销数据 | 季节性业务波动；新上线业务样本量不足被误判为离群 |
| 时效与截止 | 重算账龄；识别提前付款、倒签、跨期入账等时点异常 | 应收应付、合同、入库与开票时间 | 节假日与账期规则未纳入计算；系统记账时间与业务发生时间混用 |
上表为通用审计程序的分类整理，具体阈值与判定口径应结合本单位制度与行业监管要求确定，不宜直接照搬。
采购与供应商方向的具体做法见供应商审计方案；财务口径的场景见财务数据分析；金融与公共部门的整体场景见金融服务数据分析与公共部门数据分析。
在信创环境里落地：已实测的软硬件范围
审计与监督数据敏感度高，绝大多数场景要求内网离线、国产化底座。以下是已完成测试并有实际部署的范围，未列入的项请先做适配验证，不要按「应该可以」推进项目。
- 操作系统：麒麟 V10 / V11、统信 UOS，均为 x86-64 版本；Windows 环境同样支持
- 处理器：海光 C86（x86-64），已测试、已部署
- 部署方式：完全离线安装，不需要连接外网许可服务器；数据全程不出内网
- 界面与文档：全中文界面，节点名称、参数与报错提示均已中文化
- 底稿可移交：工作流以 .knwf 存储，与 KNIME 双向通用，不产生私有格式锁定
工作流即底稿：审计真正稀缺的能力
这几年不写代码已经不稀缺了，Excel 里都有了 AI 助手。审计场景里稀缺的是另一件事：说得清楚这个数是怎么来的，并且换个人重跑还是这个数。
当被审计单位质疑一条疑点，当上级问「这个口径为什么和上期不一样」，当外部检查要求提供分析过程，能当场打开处理流程逐步演示的机构，和只能回答「系统就是这么算的」的机构，差别不在工具版本，在于处理过程有没有被当成底稿管理起来。
iModel 的主张就在这里：把审计测试沉淀成组织资产，而不是某台电脑里的一个文件。工作流本身就是底稿，每一步处理逻辑可视化留痕；规则改一次，所有下游同步；人员轮岗时，交出去的是能跑的流程，不是一句口头交代。
