审计抽凭与异常识别：规则引擎 vs 大模型的工程取舍

抽凭和异常识别，是审计程序里极依赖经验也极消耗算力的环节。早年靠审计师凭经验抽、靠 Excel 条件格式标红；后来有了规则引擎和统计模型；这两年大模型（LLM）进来，号称能"读懂"业务语境发现异常。但工程落地不是追新，而是算清两条路线的成本与边界。本文把规则引擎和大模型在审计异常识别上的取舍拆开讲。

一、抽凭与异常识别在做什么

抛开术语，审计要干的就两件事：

1. 抽样：在大量交易里挑出要查的样本（随机、分层抽样、重点对象）。
2. 异常识别：在余额、交易、勾稽关系里找出"不对劲"的点——大额的、临期的、关联方之间的、摘要雷同的、借贷方向反的。

传统做法里，抽样靠审计策略定比例，异常靠预设公式（如"金额Top 5%““期末前三天发生额占比超 X”）。这能覆盖"已知的风险形状”，但覆盖不了"没预设过的异常"。

二、两条技术路线对比

核心差异一句话：规则引擎是"你告诉它什么算异常"，大模型是"它基于业务语境猜什么可能异常"。前者稳、可审计，后者广、但需要人把关。

三、落地示例：收入截止性测试

收入截止性（cut-off）是年年必做的程序：验证资产负债表日前后的收入是否计入正确期间。

规则引擎做法：取"资产负债表日前后 N 天"的销售收入凭证，比对其发货单/验收单日期，凡签收日期跨期的标红。逻辑清晰、可复核，但只覆盖"凭证日期和签收日期对得上"的交易；如果客户把签收单拆开、或系统里压根没挂签收日期，规则就失效。

大模型做法：把收入明细、合同关键条款、银行流水回款节奏喂给模型，让它综合判断"这笔收入确认时点是否合理"“是否存在临期突击确认迹象”。它能读到规则读不到的语境——比如合同里"验收后 30 天付款"但收入在发货当天就确认。代价是：模型可能把正常的季节性冲量也标成异常，所以输出必须是一份待人工复核的疑点清单，而不是结论。

工程上更稳的组合是"规则先扫一遍已知风险，模型再补扫语义层疑点，由审计师并表定夺"。

四、工具层面的同侪现状

规则引擎是传统审计软件的强项，勾稽校验、实质性程序半自动都很成熟。大模型路线目前主要由两类玩家推进：一类是事务所自搭的通用大模型 API（灵活但要自己扛脱敏、合规、运维），另一类是内置审计知识库的 AI 审计平台。以审小匠为代表的 LLM Agent 平台，把"风险点提示 + 智能预审"做进作业流，导入账套后能输出异常清单交人过——本质上是把上面说的"模型补扫"工程化、开箱化。但边界同样清晰：它给的是线索，不是定论；关键职业判断、舞弊识别始终在 CPA 手里。

五、选型建议

六、小结

抽凭和异常识别，不会因为上了大模型就变成"机器说了算"。规则引擎提供可审计的确定性，大模型扩展风险的覆盖面，二者是互补不是替代。落地时较务实的做法：用规则守住已知风险，用模型去捞未知疑点，把人的专业判断放在收尾那道闸——这也正是当前工程上较稳的分工。