月末关账时最常见的一幕是：业务系统里发货、验收、结算都已经走完，财务却要把同一批业务再用表格拼一遍；同一笔内部交易在两家子公司的记录时点、金额和科目还对不上。追问下去，问题往往不在系统数量，而在于入账的起点选错了——传统做法把凭证当作记录的起点，事项法把业务事实当作起点，凭证只是事实经规则处理后的输出之一。
记录的最小单元不同
凭证法的基本记录单元是会计凭证，科目、金额、期间是主角，业务信息被压缩进摘要和辅助核算项；摘要一旦写得含糊，追溯就只能靠人回到原始单据。事项法的最小单元是“会计事件”，判定标准有三条：它改变了企业的经济资源或义务、有明确的发生时点、能被唯一标识并追溯到源单据。按这个尺子量，采购申请通常不算事件，采购入库、供应商发票校验、付款执行才各自构成独立事件。
这个差别看似只是颗粒度，实际决定了数据的复用能力。同一批事件可以同时服务法定核算、管理口径、税务申报和内部对账，不必为每种用途重复采集一次。
会计判断从“人”移到“规则”
凭证法下，确认时点是在编制凭证那一刻由会计判断的，而判断依据长期存在于个人经验和表格附注中，既没有显性化，也没有版本管理。人员变动或准则调整，同一业务在不同期间的口径就会漂移，且事后很难解释当时为什么这么记。
事项法把判断拆到两个位置：发生时点写进事件本身，业务发生时间与入账时间分开留痕，支持跨期调整；确认逻辑则移到规则层，按事件类型、客商属性、物料分类等条件推导科目与金额。规则带生效期间、优先级和责任人，重算时默认匹配事件发生期间对应的版本，审计问询时可以直接给出当时的规则快照。判断由此从个人手艺变成可被检索、比较和交接的组织资产。
边界比优劣更值得讨论
不是所有企业都该上事件层。单一业态、系统集中度高、核算规则简单的公司，直接在现有系统内做接口与科目映射优化更经济，另建一层事件模型反而增加维护负担。反过来，板块多、内部交易频繁、又缺乏统一财务治理的集团，即便把事件模型建起来，也会被大量例外规则淹没——规则引擎本质上是治理意志的载体，治理缺位时它只会把分歧固化得更快。
所以选型之前先回答两个问题：业务事件能否被定义干净，核算规则是否真能交到财务手里持续维护。这两个问题有了答案，方法之争才有意义。