审计流程自动化的探索与实践：从序时账到审计方案

审计工作中有大量时间消耗在重复但又不能省略的环节：整理序时账、统一字段、汇总收入成本、筛选异常项目、核对项目节点、计算财务指标，最后再把分散的发现整理成审计方案。

我在 Audit Analysis Tool 中尝试把这些环节连接起来。这个项目目前更接近一个持续演进的审计自动化原型，而不是开箱即用的成熟产品。它的价值不仅在于减少做表时间，更在于探索一个问题：哪些审计程序适合交给规则和程序稳定执行，哪些工作可以由 AI 辅助，以及哪些判断必须留给审计人员。

本文基于仓库 main 分支截至 2026 年 7 月 13 日的版本整理。项目后续更新时，具体功能和目录可能发生变化。

一、审计自动化真正要解决什么

单独编写一个 Excel 汇总脚本并不困难，困难的是把审计流程中的数据、规则、证据和结论连接起来。实践中至少存在四个断点：

1. 数据口径不统一：不同系统导出的字段名称、日期格式和金额格式不一致。
2. 分析步骤相互割裂：序时账、项目台账和财务报表往往由不同人员分别处理，结论难以相互印证。
3. 异常判断依赖个人经验：同一组数据可能因人员经验不同而得到不同的关注重点。
4. 报告编制重复劳动较多：分析结果还需要人工转写成风险提示、审计程序和汇报材料。

因此，我希望建立的不是一个孤立的“做表工具”，而是一条从原始数据到审计方案的可重复流水线：

原始序时账
  → 字段标准化和汇总做表
  → 项目经营异常识别
  → 项目台账合规检查
  → 财务报表指标分析
  → 风险汇总和审计方案生成

仓库说明中使用约 14 万条凭证数据和 84 个项目段作为实践场景，核心实现由 Python、pandas、openpyxl、python-docx 和兼容 OpenAI 接口的大模型调用组成。

二、整体设计：规则负责判断，AI负责表达

这套工具最重要的设计思路，是没有让大模型直接承担全部审计判断，而是把流程分成三层。

这种分工能够保留基本的可解释性。金额计算和日期比较可以重复验证，不应依赖大模型的概率性输出；大模型更适合将已有事实组织成自然语言，或发现规则尚未覆盖的线索。

三、第一步：把序时账转换成可分析的数据

审计做表模块首先读取序时账，将中文字段映射为统一的内部字段，并处理日期和金额格式。随后按照会计科目名称识别：

• 主营业务收入：取贷方发生额；
• 主营业务成本：取借方发生额；
• 合同履约成本：取借方发生额；
• 利润金额：主营业务收入减主营业务成本；
• 利润率：利润金额除以主营业务收入。

输出工作簿包含原始数据、按年月汇总、按项目段汇总收入成本、按项目段汇总合同履约成本四张工作表。

这一阶段看似只是做表，但它决定了后续分析是否可靠。自动化的第一个收益，是把每次手工筛选、复制、透视和公式填充变成同一套处理逻辑；第二个收益，是为后续工具建立相对稳定的数据接口。

四、第二步：从经营指标中识别异常项目

项目经营分析模块在做表结果上继续计算收入占比、成本占比、利润贡献度和盈亏状态，并通过阈值识别风险。

目前设置的主要规则包括：

程序还从采购端和市场端继续穿透。例如，检查供应商或客户集中度、月末收入确认比例、同类项目成本偏离、大额采购凭证，以及合同履约成本匹配程度。输出不仅是异常标签，还包括可供人工追查的项目、凭证和往来单位线索。

这些阈值的作用是形成统一的初筛口径，而不是直接替代审计结论。高利润率并不必然意味着虚增收入，供应商集中也不必然代表舞弊；程序提供的是“优先看哪里”，最终仍需要结合合同、验收、发票、函证和业务背景验证。

五、第三步：把项目流程规则转化为合规检查

项目台账分析模块将项目管理制度转化为日期顺序和流程完整性规则。

例如，需要提前开工的项目和正常项目适用不同的立项流程；程序会比较 POC 立项、合同签订、交付立项、入账、入库、出库和终验等时间节点。同时，为避免机械规则制造大量误报，代码中加入了若干豁免逻辑：空置节点不当然视为异常、部分节点在同一月份发生可以豁免、多采购编号或多入库日期本身不作为异常，但合同签订后超过一定时间仍未交付立项会被标记为流程延迟。

这部分实践让我认识到，审计规则自动化不能只写“正常顺序”，还必须同步定义：

• 在什么条件下适用该规则；
• 哪些字段缺失属于流程尚未完成；
• 哪些情况属于合理豁免；
• 多久以后才构成异常；
• 一个项目同时命中多条规则时如何汇总风险。

规则引擎完成确定性检查后，大模型可以补充发现未被规则覆盖的异常描述，但补充结果应单独展示，不能和确定性规则混为一谈。

六、第四步：把财务指标翻译成审计风险

财务报表分析模块读取资产负债表、利润表和现金流量表，计算盈利能力、营运能力和偿债能力指标，并将指标变化转换成面向审计负责人的风险提示。

这里的重点不只是计算毛利率、应收账款周转率、流动比率等指标，而是建立指标之间的联系。例如：

• 收入增长是否伴随应收账款快速上升；
• 净利润是否得到经营现金流支持；
• 高毛利是否与项目成本完整性相匹配；
• 流动资产看似充足时，真正可以用于偿债的现金是否充足。

当输入资料没有行业平均值时，程序不会虚构外部基准，而是明确说明数据限制。这是自动生成专业报告时非常重要的边界。

七、第五步：编排流程并形成审计方案

全流程编排器负责识别输入文件、调用各个子工具、传递中间结果和收集报告。当前代码先串行执行“审计做表 → 项目经营分析”，再并行执行“项目台账分析”和“财务报告分析”，最后进入汇总阶段。

汇总模块将三类分析报告整合为审计方案，并检查最终文档是否包含：

1. 审计重点与风险分析；
2. 审计依据；
3. 审计策略与方法。

如果大模型不可用，程序会使用模板内容兜底；如果某份分析报告缺失，最终文档会增加缺失提示。相比于“一旦出错全部中止”，这种设计更方便单独重跑失败步骤，但也带来了一个新的管理要求：必须明确区分“流程运行完成”和“审计资料完整”。

八、实践中的收获

1. 自动化首先改变的是审计资源分配

程序最适合承担高频、重复、规则明确的工作。审计人员因此可以把更多时间用于理解业务、验证证据、设计访谈和判断风险，而不是反复制作透视表。

2. 可解释规则是自动化审计的基础

每个异常都应能够回答三个问题：使用了哪条规则、读取了哪些字段、为何得到这个结果。如果只能得到一个模型评分，却无法回到原始凭证和业务单据，就很难形成可靠的审计证据。

3. AI适合辅助，不适合独立定性

AI可以生成审计建议、归纳多份报告和发现文本线索，但它不能替代事实核查。较稳妥的方式是先由程序计算事实，再把有限且经过脱敏的结果交给模型，最后由审计人员复核。

4. 容错机制不能掩盖数据缺失

允许单个模块失败后继续生成文档，有利于定位问题和恢复运行；但如果最终状态只显示“成功”，使用者可能忽略缺失报告。因此，完整性状态本身也应该成为正式交付物的一部分。

九、当前原型仍需解决的问题

在核对当前代码后，我认为以下问题应优先处理。

1. 目录和路径需要彻底解耦

当前编排器仍使用中文子工具目录名，而仓库已经采用 list_clean_up、project_operating_analysis 等英文目录。这会导致克隆仓库后无法直接按说明运行。应统一目录约定，或从仓库根目录和配置文件动态解析各模块位置。

2. 输入接口仍依赖文件名和固定字段

目前主要通过文件名关键字判断输入类型，通过预设字段名称读取数据。相似文件名可能被错误路由，源系统字段变化也可能直接导致失败。应为每类输入建立明确的数据契约，包括必填字段、类型、取值范围、版本和校验报告。

3. 阈值需要结合业务和重要性水平

80%的高利润率、70%的集中度或30个百分点的月度波动适合做默认初筛，却不应适用于所有行业和项目。阈值应按企业、行业、项目类型和审计重要性水平配置，并记录每次运行实际使用的参数版本。

4. 输出需要更完整的数据血缘

每条异常应能够追溯到源文件、工作表、行号、字段值、规则编号和程序版本。现在的报告已经保留部分项目和凭证线索，但还可以增加统一的证据索引和运行清单，让复核人员能够快速重现结论。

5. 需要防止旧报告被误用

汇总阶段会从输出目录收集既有报告，财务模块还会选择最新的 Word 文件。如果本次运行失败但目录中保留了历史文件，可能把旧报告带入新审计方案。每次运行应生成唯一批次号，并只汇总该批次确认成功的产物。

6. 自动化测试和基准样本不足

仓库中的校验脚本主要检查输出文件，尚未形成覆盖数据清洗、金额勾稽、异常规则、豁免条件和端到端流程的自动化测试体系。需要准备脱敏的小型样本，并为每条核心规则设计正常、异常和边界测试。

7. 敏感数据与模型治理必须前置

审计数据可能包含客户、供应商、合同和财务信息。模型调用前应进行字段最小化和脱敏，并明确数据是否离开本地环境、保存多久、由谁访问。API 密钥使用环境变量只是第一步，还应增加访问控制、调用日志和模型输出复核机制。

十、下一阶段改进路线

我会按照“先保证正确，再增强智能”的顺序推进。

第一阶段：可运行与可验证

• 统一仓库目录和命令入口，消除本机路径依赖；
• 增加命令行参数和集中配置，避免脚本硬编码输入路径；
• 建立输入数据契约、字段校验和金额勾稽检查；
• 为关键计算和规则建立单元测试、边界测试和端到端样本；
• 为每次运行生成批次清单，记录输入摘要、参数、产物和完成状态。

第二阶段：可追溯与可复核

• 为每条异常分配稳定的规则编号；
• 在报告中记录源数据定位和计算过程；
• 将规则发现、模型补充发现和人工结论分栏展示；
• 增加人工复核状态、证据附件索引和结论审批记录；
• 对新旧版本的规则和输出结果进行差异比较。

第三阶段：性能与使用体验

• 对大规模 Excel 数据采用向量化处理，减少逐行计算；
• 评估 DuckDB、Polars 或 Parquet，降低重复读取大型工作簿的成本；
• 提供统一界面显示运行进度、异常数量、失败步骤和重跑入口；
• 将高频数据源改为标准接口导入，减少依赖人工整理文件名。

第四阶段：审计智能增强

• 按行业和项目类型建立经验证的阈值库；
• 用历史已复核项目评估规则的误报率和漏报率；
• 在规则初筛后引入同类项目对标和多变量异常检测；
• 为 AI 输出设置固定结构、引用证据和置信提示；
• 建立“程序发现—审计复核—最终结论”的反馈闭环。

十一、结语

审计流程自动化的目标，不是让程序替审计人员作出最终判断，而是让数据处理更稳定、异常筛选更一致、分析过程更可追溯。

这次实践证明，从序时账做表、经营指标分析、台账规则检查到审计方案汇总，可以逐步连接成一条自动化流水线。但要真正进入审计项目，还必须继续补齐路径兼容、数据契约、参数治理、证据血缘、自动化测试和敏感数据保护。

只有当每个自动化结论都能够回到原始数据、规则依据和审计证据时，工具带来的效率提升才会真正转化为审计质量的提升。

项目资料

• Audit Analysis Tool 仓库
• 全流程编排器
• 审计做表模块
• 项目经营分析模块
• 项目台账分析模块
• 财务报表分析模块