前面我们用2篇文章把会计引擎的原理和凭证模板设计解释清楚了，今天一起来看下真正的流程，也就是会计引擎怎么驱动凭证生成、反写，日志怎么记录。

具体内容如下：

一、产品介绍

1.1 三个核心概念

首先，我们来搞清楚三个最基本的概念。它们是会计引擎最核心的三件事，理解了这三件事，后面所有的内容都会清晰很多。

1、凭证生成

什么叫凭证生成？

简单说，就是把一笔业务变成一张会计凭证，自动写进财务账本。

举个最直观的例子：

采购部门今天入库了一批原材料，价值5万元。

这个时候，财务需要记一笔账：借方记原材料增加，贷方记应付账款增加。在没有会计引擎之前，这个动作需要财务人员手工操作；有了会计引擎，系统接收到采购入库这个事件后，自动匹配规则、生成借贷分录，写入总账，全程无需人工干预。

所以凭证生成的关键词是：自动触发、规则匹配、借贷计算、合规校验、自动过账。这五个词串联起来，就是凭证生成的完整链路。

2、凭证反写

第二个概念是凭证反写。

凭证生成之后，系统会把“这张凭证已经过账成功”这个状态，回写到原来的业务单据上。比如采购订单从“待付款”变成“已入账”，应付账款从“待核销”变成“已核销”；这个回写动作，就叫凭证反写。

为什么需要反写？

因为业务流程是闭环的。财务记了账，业务侧需要知道这笔单子的钱已经到账了，或者这张发票已经入账了，才能推进下一个环节，比如付款、交货、确认收入等等。

所以反写是连接财务与业务的重要纽带。

反写还包括另一种场景：当凭证被冲销的时候，原来的业务单据状态也要跟着回退，这个叫冲销反写，我们在后面会详细讲。

可以把凭证生成+反写比喻成一个收据的双向确认：我们去超市买东西，收银员给你开了收据，这是凭证生成；同时你的购物记录里也标记了已结账，这是凭证反写。

3、会计日志

第三个概念是会计日志。这个比较好理解，就是把整个凭证生成过程中发生的所有事情，原原本本地记录下来。

包括：

谁在什么时间做了什么操作（操作日志）；

这条规则是怎么匹配上的（规则命中日志）；

中间出了什么错（异常日志）；

规则或者模板有没有改动过（变更日志）。

会计日志的价值在于：出了问题可以追溯，审计的时候可以举证，排查故障可以定位。可以说，会计日志是整个引擎的黑匣子。

1.2 三者的整体逻辑关系

我们来看凭证生成、反写、日志的整体逻辑：

会计引擎处于业务系统和财务系统的中间地带。

资金系统、采购系统、销售系统、HR系统等业务系统层，每天产生大量业务事件，比如付款成功、发票确认、薪资发放等。

这些业务事件进入会计引擎之后，引擎做三件事：

第一，规则匹配，找到对应的凭证模板；

第二，借贷生成，完成平衡校验；

第三，过账、反写、记日志。

过账之后，凭证写入财务系统层，包括总账GL、应付账款、应收账款、报表BI；同时，通过红色虚线所示的反写机制，把凭证状态回写到业务单据；全程日志写入日志审计层。

可以看出，会计引擎是一个事件驱动、规则匹配、自动记账、闭环反写、全程留痕的中台系统。

1.3 业务范围边界

接下来我们划定一下这个系统的业务范围，这对产品同学和研发同学尤其重要，明确边界可以防止范围蔓延。

凭证生成的范围：

从业务事件接入开始，经过规则匹配、凭证生成、合规校验，到过账写入总账结束。

反写的范围：

凭证过账成功或失败或冲销之后，状态和金额同步回业务单据，并触发下游流程推进。

日志的范围：

全流程操作日志、规则命中日志、异常日志、变更日志，全量留存，不允许删除或修改。

会计引擎不负责总账本身的展现、不负责报表生成、也不负责业务系统的单据管理。这些是它的上下游系统的职责，大家在设计和开发的时候要注意这个边界。

1.4 典型凭证示例

最后我们来看几个具体的凭证例子，这样大家对凭证这个东西会有更直观的感受。

1、资金系统发起银行付款成功，凭证分录是

借：应付账款

贷：银行存款

反写内容是付款单状态变为已付款。

2、采购系统发票认证通过，凭证是

借：应付账款

贷：预付账款

发票状态变为已入账。

3、销售系统客户回款，凭证是

借：银行存款

贷：应收账款

合同状态变为已收款。

二、产品架构

2.1 使用角色

了解了产品是什么之后，我们来看产品架构，先看使用角色。

会计引擎的使用者不只是财务人员，它其实服务于六类角色：

第一类：会计规则配置员

这类同学负责维护会计规则库与凭证模板，配置科目映射和金额公式，测试新场景的规则匹配，管理会计期间和汇率参数。

简单说，就是把财务的记账规则翻译成系统能理解的配置。

第二类：财务会计

他们的日常工作是审核自动生成的凭证，处理异常凭证时进行人工干预，执行期末凭证汇总与过账，以及对账和凭证差异核查。

第三类：系统集成工程师

负责对接业务系统的消息接口，配置事件订阅与触发规则，处理跨系统数据格式转换，以及监控引擎的运行健康状况。

第四类：内审/合规审计员

他们需要查阅完整的会计日志，追溯凭证与原始单据的关联，核查规则变更历史记录，出具合规审计报告。

第五类：财务主管/CFO

他们关注的是审批重大规则变更，监控自动化记账率和异常率，决策月结关账时间节点，以及查看引擎产出的财务报表。

第六类：产品经理/实施顾问

负责设计引擎功能需求文档，与财务沟通规则落地方案，负责用户培训与系统上线，持续迭代优化规则配置。

不同角色使用的功能模块不同，这就引出了下一个话题：权限矩阵。

2.2 权限矩阵

权限矩阵是系统安全设计的核心。

规则库维护：

规则配置员有读写权限，财务会计和集成工程师只能只读，内审员只读，财务主管有审批权。

这意味着规则的修改需要经过审批，防止随意改规则导致账务混乱。

凭证审核/过账：

只有财务会计和财务主管能操作，规则配置员和集成工程师无权审批凭证。

体现了业务操作和财务审计的职责分离。

手工冲销申请：

财务会计可以发起申请，财务主管审批，其他角色无权操作。

这是一个高风险操作，需要双人控制。

日志全量查询：

内审员拥有全量查询权限，其他角色只能查看部分日志。

这保障了审计的独立性和完整性。

接口配置：

仅集成工程师有权限，其他人均无法操作。

防止非技术人员误操作接口配置。

这个权限矩阵的设计体现了财务系统职责分离、最小权限的核心原则。大家在设计权限功能时，一定要把这个矩阵作为需求基线。

2.3 产品架构

接下来是本部分最重要的内容，产品架构图。这张图把整个会计引擎的技术架构分为五层，我们从上到下来看：

第一层：事件接入层

这是整个引擎的入口。

业务事件可以通过四种方式进来：消息队列MQ、REST API、批量文件导入、定时任务触发、手工补录。

设计要点是：多种接入方式并存，适配不同业务系统的技术栈和场景需求。

第二层：规则引擎层

这是整个架构的大脑，包含四个核心模块：

规则库/模板库：

存储所有会计规则，支持规则配置、优先级设置、冲突检测、版本管理和测试沙箱。

事件解析器：

对接入的业务事件进行格式标准化，完成字段映射、幂等去重。

规则匹配引擎：

基于事件类型、组织、业务参数，进行条件匹配、策略路由、多规则优先级处理。

科目/金额计算：

执行公式计算，支持辅助核算、汇率折算、成本分摊。

第三层：凭证处理层

这一层负责凭证的生成和过账：

凭证生成与借贷校验、合规校验（期间/组织）、审核与自动过账、反写处理。

第四层：存储层

所有的数据都持久化在这一层，包括凭证主表/分录表、规则库/模板库、会计日志库、事件溯源记录和反写记录。

第五层：输出层

最终产出给下游系统：

总账GL、财务报表、业务单据状态、审计日志报告/BI看板。

整体来看，这五层是一个从事件输入到数据输出的完整管道。在做技术设计的时候，要注意每一层的职责边界不要越权，保持各层的低耦合高内聚。

2.4 架构设计六大原则

最后，分享一下我们在设计这套架构时遵循的六大原则，这些是业界成熟实践的总结：

原则一：事件驱动。

采用异步订阅业务事件的方式，把业务系统和会计系统解耦。

这样任何一侧出现问题，不会直接拖垮另一侧，同时也提升了系统的吞吐量。

原则二：规则外置。

会计规则以配置形式存储，不写死在代码里，财务人员可以自助维护。

这是非常重要的设计，新业务场景上线，不需要发版，配置完成后即可生效，极大降低了上线成本。

原则三：幂等性。

同一个业务事件，不管因为网络重试还是消息重发，传进来多少次，只生成一张凭证，防止重复记账。

这是系统最核心的安全设计之一。

原则四：完整审计链路。

从原始事件→规则命中→凭证输出→反写状态，每一步都有不可篡改的日志。

这是合规要求，也是出问题时快速定位的关键。

原则五：多组织隔离。

按法人或业务单元隔离账套，支持集团管控与多主体独立核算。

特别是在跨境、跨法人的业务场景下，这个设计至关重要。

原则六：多币种支持。

本位币和外币并行，汇率自动换算，汇兑损益自动生成相应分录。

这对有境外业务或外币结算的公司来说是必备能力。

这六大原则，既是设计目标，也是评估会计引擎成熟度的六个维度。做产品规划和技术评审时，可以把它们作为检查清单。

三、产品设计深度解析

3.1 凭证生成反写全流程总述

进入产品设计部分，这是今天内容最密集的一块，我们花最多时间在这里。

先看一个完整的流程示例，以采购入库为例：

业务事件：

事件类型是采购入库，金额5万元，华东分公司，2024年12月，来源单PO-20241201。

规则匹配：

命中规则RUL-001，规则内容是“采购入库→存货增加，借原材料贷应付账款”，优先级P1。

凭证输出：

生成凭证号2024-12-0088，借方1401原材料5万，贷方2202应付账款5万，借贷平衡校验通过，期间有效，摘要是PO-20241201入库。

过账写入GL：

状态POSTED，过账时间2024-12-01 10:02:34，操作人SYSTEM，GL写入成功。

反写业务单：

PO-20241201状态从“待付款”变为“已入账”，凭证号回填，反写成功。

这个流程是整个引擎的核心主线。

更详细来说，整个链路可以如下图所示，业务单据→会计事件→规则匹配→凭证草稿→正式凭证→总账过账，以及并行的幂等检查→主数据校验→会计校验。

如果处理失败，进入失败队列，同时记录处理日志，再通过反写服务完成业务闭环。

注意：幂等检查必须在规则匹配之前完成，防止重复处理；主数据校验必须在凭证生成之前完成；任何一个节点失败，都不能静默丢弃，必须进失败队列，等待人工介入。

3.2 凭证生成模块详解

1、主流程七步

凭证生成的主流程分七步：

事件触发→事件解析→规则匹配→凭证生成→借贷平衡→审核/过账→写入GL。

事件触发：

支持MQ消息、API调用、定时触发、手工操作四种方式，保证所有业务事件都能被接收。

事件解析：

做字段映射、格式校验、幂等去重。这一步失败不记凭证，记异常日志。

规则匹配：

按业务类型和组织找到最匹配的凭证模板。这是整个系统的智能核心。

凭证生成：

填充科目、金额、辅助核算信息，生成凭证草稿。

借贷平衡：

∑借=∑贷，期间有效，科目有效。这是会计恒等式，必须严格保证。

审核/过账：

可配置是否需要人工审核节点，通过后进入过账。

写入GL：

可以异步或同步写入总账，异步写入需要有补偿机制。

2、核心数据模型

凭证主表的关键字段如下表所示：

其中，source_id是连接凭证和业务单据的关键字段，它让反写成为可能，让溯源成为可能，一定不能缺失。

页面示例如下：

3、凭证分录模型

分录表记录每一条借贷明细，如下表所示：

辅助核算维度的设计非常重要，它决定了财务系统能提供多细粒度的分析能力。在设计时，需要和财务确认清楚，哪些维度是必须的，哪些是可选的。

3.3 凭证反写模块详解

1、四种触发时机

凭证反写有四种触发场景：

第一种：过账成功反写

这是最常见的场景，GL写入完成后，将业务单据状态更新为已记账，并把凭证号回填到业务单据。

第二种：冲销反写

红字凭证过账后，将业务单据状态回退到冲销前，并清空关联凭证号，仿佛那张凭证从来没有存在过。

第三种：审核拒绝反写

人工审核拒绝时，单据状态回退至待审核，并发送通知给业务操作人，提示需要修正后重新提交。

第四种：部分核销反写

支持分批核销，每次反写时更新已核销金额和未核销余额两个字段，这在应收应付的部分收款场景下非常常见。

2、反写流程

完整的反写流程是：凭证过账→通过source_id关联找到业务单据→更新状态→更新核销金额→通知下游业务系统→记反写日志。

重点讲一下反写设计原则：

反写必须用异步事件通知，不能用同步调用。

原因是如果是同步调用，业务系统出故障，会导致整个凭证过账流程挂起，这是不可接受的。

反写失败时，业务单据状态维持原状，不能因为反写失败就把已过账的凭证自动回滚。凭证一旦过账，就具有法律效力，不能轻易撤销。失败了进告警队列，人工处理。

3、反写数据模型

反写记录表记录以下内容：

相同voucher_id和source_id组合，只执行一次状态变更。这防止了因为消息重发导致状态被错误地更改多次。

3.4 会计日志模块详解

1、六种日志类型

会计日志分六种类型，每种都有其特定的用途：

操作日志：

记录所有人工操作，谁、何时、对哪张凭证、做了什么。

主要用于权限核查和行为审计，出了安全事件可以第一时间找到责任人。

规则命中日志：

记录每次生成的规则匹配过程，包括候选规则列表、最终命中规则、未命中原因。

这是排查【为什么这笔单子没有自动记账】或者【为什么记到了错误科目】的核心依据。

异常日志：

记录校验失败、规则未命中、过账失败、反写失败等异常，带错误码和处理建议。

这是运维人员和财务人员处理问题的工作台。

性能日志：

记录引擎处理耗时和批量吞吐量，用于性能优化和容量规划。

变更日志：

记录规则库修改、模板变更、科目调整的完整变更记录，包含变更前后对比。

这是合规审计最重要的日志之一。

反写日志：

记录每次反写的执行结果，与凭证日志形成完整的业务闭环轨迹。

2、页面设计要点

会计日志页面有四个关键设计要点：

多维筛选：

支持按时间范围、凭证号、业务单据号、操作人、日志类型、处理结果等多维度组合筛选，帮助用户快速定位目标日志。

关联穿透：

从凭证可以直接查看该凭证的全链路日志；从日志可以跳转到原始业务单据；用trace_id在分布式系统中串联同一事件的所有日志，实现端到端追踪。

异常工作台：

异常日志提供重试/忽略/手工补录三个操作入口，支持批量处理，让运维人员能够高效地处理异常队列。

日志导出：

按筛选条件导出CSV或Excel文件，用于外部审计提交或内部分析，这是很多企业内部审计和外部合规检查的标准诉求。

3、日志数据模型

日志表的关键字段，如下图所示：

在微服务架构下，一个业务事件可能经过多个服务处理，trace_id能把这些分散的日志全部串联起来，让你能看到完整的处理链路。这对排查问题极其重要。

3.5 规则引擎配置模块

规则引擎是整个会计引擎的大脑，它的配置能力直接决定了系统的适配范围和灵活性。

1、规则配置分层

规则配置分为五层：

事件规则：定义哪类业务事件触发哪类会计处理，比如销售发票确认→生成应收凭证。

科目规则：定义按产品类别、客户类型、业务类型如何映射到具体科目。

金额规则：定义如何计算金额，比如含税金额、不含税金额、税额、价税合计、汇率折算等。

维度规则：定义辅助核算维度，如部门、项目、成本中心、客户、供应商等。

汇总规则：定义多笔业务事件是否需要汇总成一张凭证，比如按法人+币种+税码汇总。

2、核心校验清单

每张凭证在过账前必须通过五项校验：

借贷平衡，借方合计=贷方合计。

期间状态，会计期间打开，过账日期有效。

主数据校验，科目、客户、供应商、成本中心都是有效的。

币种税码，汇率存在，税额与税率一致。

重复入账，同一业务事件不能重复生成有效凭证。

3、主要功能点

页面示例如下：

3.6 冲销（红字）凭证设计

冲销凭证是财务系统中一个非常重要但也容易出问题的功能。

设计冲销凭证的核心原则是：

已过账凭证不得直接修改，只能通过生成红字冲销凭证的方式纠错。这是会计准则的基本要求，也是审计可追溯性的保证。

冲销流程六步

第一步：发起冲销申请

可以是人工申请，也可以是系统自动触发，比如发票被红冲后，系统自动触发凭证冲销申请。

第二步：原凭证锁定

系统立即将原凭证锁定，防止在冲销处理期间被并发修改。这是并发控制的关键。

第三步：审批流程

由财务主管或授权人审批冲销申请，确保重大操作有人把关。

第四步：生成红字凭证

生成与原凭证借贷方向完全相反、金额相同的冲销凭证。比如原凭证借原材料5万/贷应付账款5万，冲销凭证就是借应付账款5万/贷原材料5万。

第五步：过账冲销

红字凭证过账后，GL中相关科目余额相互抵消归零。

第六步：反写原单据

业务单据状态回退至冲销前，关联凭证号清空；日志全程记录，原凭证和冲销凭证建立关联关系，审计时可以追溯完整的纠错链条。

这里特别强调两点：

第一，冲销凭证不是删除原凭证，而是新增一张抵消凭证，两张凭证都保留在系统里；

第二，凭证关联关系（原凭证↔冲销凭证）必须建立，这是审计追踪的基础。

页面示例如下：

3.7 引擎运行监控指标

最后讲一下引擎的运行监控。

一个生产级的会计引擎，必须有完善的监控体系，这四个指标是核心：

自动化记账率：

自动生成凭证数÷总凭证数。

目标值≥95%，低于阈值时自动触发告警。这个指标反映了引擎规则覆盖的完整性，如果这个值下降，说明有新的业务场景没有被规则覆盖，需要补充配置。

凭证生成时延：

从业务事件触发到凭证过账的耗时。P99目标<30秒。

如果时延升高，可能是规则匹配效率下降，或者GL写入出现瓶颈，需要及时排查。

异常凭证率：

生成失败或规则未命中的凭证占比。目标<1%，超标需要即时处理。

这个指标如果持续走高，通常意味着业务系统的数据质量出了问题，或者规则配置需要更新。

反写成功率：

反写成功次数÷反写总次数。目标≥99.5%，失败的进入补偿队列。

低于目标值说明业务系统接收反写的接口不稳定，需要联合排查。

这四个指标建议接入公司的监控大盘，配置相应的报警规则和处理SLA，确保引擎的健康运行。

四、案例分析

4.1 案例：发票红冲引发的凭证冲销与反写

理论讲完了，我们来用一个真实案例把所有知识点串联起来。这个案例非常典型，在实际业务中高频出现。

1、场景描述

采购部门之前对一张采购发票（金额80,000元）完成了入账，系统生成了凭证2024-12-0088：

借应付账款 8万

贷预付账款 8万

后来发现该发票开错了，需要红冲。

此时，财务需要冲销已生成的凭证，并将采购订单PO-20241201状态从“已入账”回退为“待确认”。

2、处理过程

第一步：

财务人员在系统中发起冲销申请，指定原凭证2024-12-0088。此时原凭证状态自动锁定为LOCKED，防止并发修改。

第二步：

财务主管在系统中审批通过该冲销申请。审批操作自动记录至操作日志，含审批人、时间、原因。

第三步：

引擎自动生成红字凭证2024-12-0089：

借：应付账款 8万

贷：原材料8万

 

与原凭证2024-12-0088方向完全相反。

第四步：

红字凭证2024-12-0089过账至GL，原材料和应付账款科目余额相互抵消归零。

第五步：

触发冲销反写。

采购订单PO-20241201状态从“已入账”回退为“待确认”，关联凭证号被清空。

第六步：

系统建立0088和0089两张凭证的关联关系，日志全程记录，审计时可以完整追溯这条纠错链条。

3、案例总结

这个案例综合体现了我们今天讲的所有知识点：

凭证生成（原凭证0088）→凭证冲销（红字凭证0089）→冲销反写（采购单状态回退）→日志全程记录（两张凭证关联，审计可追溯）。

整个流程有严格的操作控制，先锁定、再审批、再生成红字凭证、再过账、再反写，每一步都有日志，不允许绕过任何一个节点。这是会计系统安全性的体现。

看完不过瘾，那就自己发一篇吧！