财政部发了会计数智化文件：最要紧的四个字，是「规则引擎」

9 月 17 日，财政部办公厅发了一份征求意见稿，《财政部关于加快推进会计数智化工作的指导意见（征求意见稿）》，文号财办会〔2026〕32 号，意见反馈截止 10 月 20 日。

圈里转得挺热闹。我也转了。

但真正让我坐下来写这篇的，不是那七个方向。是（十二）条里的一句话：

以规则引擎为核心。

（十二）条讲的是"加快单位财务会计数智化转型"——整份文件里最像 AI 主场的一条。我把它来回读了几遍，确认了一件事：这一整条里，"人工智能"四个字没有出现。

文件在这一条里点名的技术栈是：规则引擎、会计数据标准、流程编排与自动化、电子凭证解析、账簿报表生成引擎。

而过去一年，我看过的方案里，这四个字基本不出现。

我不觉得这是文件写得保守。它说的是另一件事：AI 能替你干多少活，取决于你把规则写到多细。规则没写细，上什么模型都是在加速犯错。

这件事我交过学费。所以这篇不逐条讲文件，只挑我认为真正要紧的几处说。

（十二）条里，"人工智能"一次都没出现

先把原文摆出来，这一条里的技术路线写得很具体：

以规则引擎为核心，叠加会计数据标准、流程编排与自动化、电子凭证解析、账簿报表生成引擎，将国家统一的会计制度要求内嵌于会计信息系统，实现业财融合与凭证、账簿、报告自动生成和在线归档。

我数了一下它点名的层次，一共五层，顺序是有讲究的：规则在最里面，数据标准垫在下面，流程和自动化在中间，解析和生成在最外面。模型不在里面——这一条里没有它。

对比一下市面上常见的说法，错位就很清楚了：

为什么会计这件事必须这样？我想了很久，结论是它有个别的行业没有的约束：账要能解释。

你让模型判断一笔费用该进哪个科目，它能给出答案，甚至给得挺准。但审计问你"为什么是管理费用不是销售费用"，你需要的不是概率，是一条能念出来的规则。模型最不擅长的恰好就是"复述自己是按哪条规则算的"——它可以编一条听起来很合理的，但那不是它真实的计算依据。

规则引擎反过来。它笨，写多少条就只认多少条，但它能告诉你命中了第几条、为什么。

为什么是规则引擎：我交过两周学费

去年给公司在用的那套 OA 写 MCP 之前，我先干了一件跟写代码完全无关的事：把报销制度整理了一遍。

具体整理什么？就是那些平时大家都"知道"、但从来没人写死的东西——

• 哪几类费用必须附什么材料，尤其是团建费到底要不要附申请表和照片；
• 单笔多少金额以上必须带合同；
• 差旅的住宿标准分几档、超标了走哪一级审批；
• 发票的购销方名称和报销主体不一致时，算不算问题。

这活儿枯燥到什么程度？我当时的感受是：我是在做会计，不是在做一个技术项目。有几天我甚至怀疑自己在浪费时间——代码一行没写。

但后面一年证明了，那两周是整件事里最值钱的部分。因为它决定了另外一件事：系统判"合规"的时候，依据是哪一条。

如果我没整理，MCP 一样能跑，跑得还挺顺。它会把每张单读出来、把发票抽出来，然后给我一个看起来很像结论的东西。但那个结论没有出处——它可能把"团建费不需要照片"当成了默认，也可能根本没想到这个问题。

现在回头看文件（五）条，我发现里面写了一句我特别眼熟的话：

解决单位在成本管理、预算管理、绩效评价等领域数据指标"一数多义、口径不一"的问题。

"一数多义、口径不一"。这八个字，是财务人十年的痛，现在被写进文件了。而且它被写在了"管理会计数据指标标准"这一条下面——不是技术问题，是标准问题。

什么叫"一数多义"

举个我亲身经历的例子。月度经营会上，四个人讲"本月收入"：

四个人，四个数，每个数都是对的。会开完，谁也没被说服。

过去我们把这归为"沟通问题"，开会前多对一遍就好了。但文件的思路不一样：它认为这是标准缺失，得靠标准解决，不能靠人每次盯着。这个区别很重要——沟通问题靠自觉，标准问题靠机制。自觉会累，机制不会。

被跳过最多的（十九）条，要求的动作反而最具体

如果只读新闻稿，你会以为这份文件的重点是那七个应用方向。但我建议你把第四部分读到底——最后一条是（十九）加强会计数智化安全管理。

它在整个"实践应用"部分的末尾，标题里也没有"智能"两个字，很容易被划过去。可我拆开看，它要求的动作是全文里最具体的：

1. 参照相关行业领域的数据分类分级标准，对会计数据进行分类分级管理；
2. 建立会计人工智能应用清单和风险分级管理机制；
3. 对模型选用、数据输入、上线审批、运行监测、人工复核、应急接管和退出处置实施全生命周期管理；
4. 完整记录数据来源、模型版本、输出结果、人工调整及审批信息；
5. 确保全过程可解释、可追溯、可问责。

第三条那七个环节，我拿来对着自己做的 OA MCP 过了一遍。结果不太好看——我贴出来，因为它比任何"最佳实践"都有说服力：

七条里，我做扎实的只有一条，勉强算两条。而文件把七条全写了。

我特别想说"退出处置"这一条，因为它是我原来根本没意识到的盲区。做自动化的人有个通病：只想着怎么让它跑起来，不想怎么让它停下来。因为跑起来有成就感，停下来没有。

可会计这件事恰恰相反——停下来比跑起来重要。一个自动入账的流程如果哪天开始出错，你得能立刻停掉它，还得能回答一个更麻烦的问题：它是从哪一天开始错的？影响了几笔？如果当初没留痕，这个问题就答不上来，只能全部重查。

第四条那句"完整记录数据来源、模型版本、输出结果、人工调整及审批信息"，对做过审计的人杀伤力最大。它翻译成大白话就是：将来有人问你"这笔分录是怎么来的"，你要能答上来是哪个模型、哪一版、人改了什么。答不上来，这条自动化链路就是一笔说不清的账。

比模型更早决定成败的，是电子凭证和主数据

回到（十二）条的前半段，那里还有一句容易被忽略的话：深化电子凭证会计数据标准应用，实现接收、报销、入账、归档全流程无纸化，以及电子会计档案单套归档管理。

这说的是"输入"。而（四）条把整条链子拆成了四个环节，我认为这四个环节的划分，比那七个应用方向更值得记：

我最在意的是"处理"那一格，因为它列了五个词：会计科目、组织机构、客户、供应商、项目。

这五个词，就是财务分析的全部维度。你所有的看板、所有的经营分析、所有的毛利拆解，都是在这五个维度上切的。它们不统一，后面全散。

这件事我有过具体的痛。做订单利润诊断的时候，我以为最花时间的是写 SQL。结果不是。最花时间的是把"客户"这个词对齐——销售系统里一套客户编码，ERP 里一套，开票系统里又是一套，还有简称、全称、带不带"有限公司"的区别。三套编码对不上，就根本算不出客户级毛利。SQL 我写了半天，编码对了我三天。

所以文件把这五个词写进"数据处理环节"，而不是写进"系统建设"那一类，这个位置很讲究。它的意思是：主数据不是项目，是日常。项目有交付日，日常没有。

（二）条里还埋了三件不起眼的事：修订《会计档案管理办法》规范电子会计档案单套制；探索推动企业财务报告单一来源制度建设；推动数据产权登记凭证作为支撑数据资产入表的可信证明。每一件单独拎出来，都能做一年。

那张"会计人工智能应用清单"，我按自己的做法填了一版

（十九）条要求各单位建立"会计人工智能应用清单和风险分级管理机制"。但它没说这张清单长什么样。

这很正常——征求意见稿给方向，落地得靠自己。所以我按自己做过的项目填了一版，供你参考。重点不是内容，是列头怎么设：

关于这张表，我有三点想说：

• "AI 做到哪一步"这一列，比"能不能做"重要得多。同一个事项，AI 可以做全流程，也可以只做初稿。这个选择不是技术问题，是风险偏好问题，得由业务负责人定，不能由做技术的人顺手定了。
• 清单要有"不参与"的行。比如发票真伪查验，这件事有官方接口，AI 参与只会增加不确定性，不如直接调接口。把不该 AI 做的事明确写进清单，比漏掉它更安全——因为漏掉意味着它还会被某个人的临时起意重新捡起来。
• "停下来怎么办"必须是可执行的句子。不能写"视情况处理"，要写"关掉哪个服务、回到哪个流程、历史数据在哪"。写不出这句，说明这条自动化还没想清楚。

先别买平台：先做这三件事

这份指导意见七个部分、二十七条，光读完就得花不少时间，读完还容易有一种"要搞一个大工程"的紧迫感。我的建议恰恰相反。这三件事不需要预算，也不需要立项，一个人两周能出结果。

第三条我想多说一句。绝大多数公司填这张表的时候，只会填正式采购的系统。但真实情况是，财务同事的电脑上还开着好几个网页版 AI，正在往里贴明细表。这些不在清单里的用法，是没有数据分级、没有留痕、没有人工卡点的。文件要求建清单，真正的价值不在管住已经报备的，在让没报备的浮出水面。

还有一条我认为最省钱的做法：问制度类问题时，要求答案必须带条款出处。不给出处的答案，一律不信。这条不需要任何预算，却能挡掉大部分看着很专业的胡说。

我打算提的那一条：（十四）想到了，（十二）漏了

这份文件还是征求意见稿，10 月 20 日前可以提意见，满打满算还剩 12 天。

我看到的情况是：群里转的人很多，真去提的人很少。大部分人转完就等正式稿，等正式稿出来再说"怎么没考虑我们这种情况"。

我打算提一条。它不是挑刺，是补一个我认为很明显的漏。

（十四）条讲内部控制数智化的时候，专门写了一句：

建立控制规则动态优化机制，形成"设计—执行—监控—优化"的持续改进闭环。

也就是说，内部控制的规则，文件想到了它会变，还给它配了动态优化机制。

可（十二）条讲会计核算的规则引擎，从头到尾没有对应的一句。

这个不对称是要出事的，而且出事的方式很隐蔽。规则引擎这套东西，最大的成本从来不在写规则那一次——那不过是两周的辛苦。真正的成本在后面：税率改了、费用标准调了、审批权限换了，谁来改这些规则？改完怎么确认没把别的规则改坏？改之前产生的历史单据要不要重跑？

内部控制的规则有人管优化，会计核算的规则没人管。两年之后规则库烂掉，大家就会得出一个听起来很有道理的结论："规则引擎不行，还是得上大模型。"——可问题根本不在规则引擎，在没人维护它。

这类意见我认为值得提：它不是提诉求，是指出文本内部的一处不一致。写文件的人看到，大概率会认。

最后

看完起草说明我才知道，我国会计信息化走过了三个阶段：1994 年财政部印发《会计电算化管理办法》，是用计算机替代手工记账；2009 年印发《关于全面推进我国会计信息化工作的指导意见》（财会〔2009〕6 号），是网络化和标准化；现在这一份，是数智化。

从 1994 年到今天，三十二年，三个阶段。每一轮的顺序都一样：技术先冲进来，标准随后跟上，最后才是人的习惯改。而每一轮真正拉开差距的，都不是谁先用了新技术，是谁先把标准立住了。

所以如果这篇只能留一句话，我想留这句：

至于我今年做的最值的一件事，说实话不是把 AI 接进了 OA，是先把那份报销制度整理明白了。前者让我觉得爽，后者让我睡得着。