财务四流合一：一个高规则密度场景的本体化实践

过去几个月我一直在折腾一件事：把财务审核里“四流合一”的判断逻辑，从老会计的脑子里搬到一套可执行的本体和规则里。这篇算是阶段性复盘。

为什么是四流合一

所谓四流，指合同流、发票流、货物（服务）流、资金流。企业付款审核的核心，就是核对这四条线能不能对上。选它做本体化试验，是因为它规则密度极高：一笔单据过审，背后可能有二十多条判断标准在同时起作用，这些标准一部分写在制度文件里，剩下的在老会计心里。

规则密度高的场景有个好处：值不值得建模，一眼就能看出来。规则少的场景，人肉判断成本低，建模是杀鸡用牛刀；规则密到人都记不全的时候，显性化的收益才真正出现。

合同约定分期回款，发票开在上一期，钱到账在下一期，审核基准日又卡在中间，到底算不算逾期？老会计的原话是“看合同约定的账期，再看有没有书面展期”。翻译成规则，就得先把“账期”“展期函”“基准日”都建成实体和字段，逾期判断才能变成一个纯粹的日期比较——但前提是这些日期字段真的存在。

一次付款对应多张发票、多份合同，金额是多对多的勾稽关系。这里我犯过错：一开始试图用一条规则算总账，金额对上就放行。老会计一句话点醒我：“总额对上不等于每一笔都对得上。”最后拆成了两层规则：先逐笔核对映射关系，再核对合计数。

一份合同被拆成多笔付款走审批，单笔都在权限线以下——这是典型的规避行为。识别它需要跨单据视角：同一供应商、相近时间窗口、合计金额越线。这条规则单看任何一笔单据都永远发现不了，必须在本体层面把“同源单据”建成一种关系。

老会计说得最多的一句话是“看情况”。我的经验是别急着追问定义，改问案例：“上次遇到这种情况，你怎么判的？为什么？”两三个具体案例问下来，“情况”就会露出结构。比如“金额差一点点没关系”，追问后变成了“税额尾差一元以内可接受”——这就可以写了：

rule: invoice_amount_match
when: abs(invoice.total - payment.amount) <= 1.00
then: PASS
else: REVIEW
source: 《付款审核办法》第十二条

每条规则我都强制自己标注制度出处。写不出出处的规则，要么是隐性经验需要补访谈，要么就是老会计的个人偏好，需要跟制度负责人确认是否升格为正式条款。

规则写出来的那一刻，价值只有一半；另一半在于它终于可以被讨论、被质疑、被回归测试。

建模之前，两个审核员对同一笔单据给出不同结论是常事，谁也说不清对方错在哪。建模之后，分歧变成了具体的：要么是规则本身有争议，要么是某个字段抽取错了。争议第一次有了落点，这大概是这几个月最大的收获。