ERP

业财通识29：审批流设计——从纸质签字到电子化流转

2026/3/3116 min read

ERP审批流工作流引擎权限设计十三Tech

大家好，我是十三。

开篇：权限之后，还有审批

在第 28 篇文章中，我们聊了 RBAC 权限体系。权限设计解决的是"谁能看、谁能改、谁能批"的问题——它给每个角色划定了操作边界，确保库管不能改订单、销售不能审付款。

但权限只回答了一半问题。剩下的一半是：即便一个人有操作的权限，他的每一次关键操作，是否都应该被允许？

举个例子。销售员小张有权限创建销售订单，但如果他接了一笔 100 万元的账期订单，而客户信用额度早已透支，这笔订单能直接放行吗？显然不能。

又比如，采购员小李有权限创建采购订单，但如果订单金额高达 50 万元，是否需要更高级别的管理者确认？答案也是肯定的。

权限决定谁能操作，审批决定操作是否被允许。 两者合在一起，才构成企业内控的完整闭环。

今天这篇文章，我们就来拆解审批流的设计逻辑。

审批流解决什么问题

业务定义

审批流是企业将内部管理制度电子化、自动化的一套规则引擎。它定义了"什么操作，在什么条件下，需要经过谁的确认，才能生效"。

通俗地说，审批流就像一张纸质的请假条或报销单在办公楼的流转过程：你填完单，交给主管签字，主管签完给经理，经理签完给财务，财务确认后你才能拿到钱。审批流要做的，就是把这套"逐级签字"的逻辑，搬到系统里自动执行。

为什么必须电子化

纸质审批有三个天然缺陷，在规模稍大的企业里会被无限放大：

找不到人：审批人出差、休假或只是暂时离开工位，单据就卡在那里，没人知道它停在哪一层。
责任不清：签过字的纸质单据可能遗失，事后追查时，谁批的、什么时候批的、批了什么意见，都很难还原。
规则不透明：新员工不知道 1 万元的报销和 10 万元的报销需要找谁签字，每次都要口头问人，效率极低。

电子化的审批流，本质上是用系统规则替代口头约定，用流程轨迹替代纸质留痕，让"谁该批、怎么批、批到哪了"变得完全透明。

ERP 中需要审批的环节

回顾我们这个系列前面的文章，审批流其实一直穿插在各个业务流程中。只是当时我们的关注点是业务本身，没有专门停下来看"审批"这个横向能力。

采购流程（P2P）中的审批

在第 1 篇文章中，我们讲过采购申请（PR）和采购订单（PO）。PR 创建后，需要主管审批确认需求合理性，财务审批确认预算充足。PO 创建后，如果金额超过一定阈值，还需要更高级别的审批才能发给供应商。

销售流程（O2C）中的审批

在第 9 篇文章中，我们讨论了信用检查。当客户信用额度不足时，销售订单不会直接被拒绝，而是进入审批流程：先由销售经理评估客户关系，再由财务部门评估风险，两级都通过才能放行。

财务流程中的审批

在第 4 篇文章中，采购结算后的付款申请，必须经过审批才能实际打款。费用报销、预付款申请、借款单，这些财务单据几乎无一例外都需要审批。

库存流程中的审批

库存盘点发现盘盈或盘亏，需要审批后才能调整系统库存。跨仓库调拨、物料报废、库存成本计价方法变更，也都涉及审批环节。

把这些场景放在一起看，审批流不是一个独立模块，而是一个横跨采购、销售、财务、库存的通用能力。它的设计质量，直接影响所有业务流程的运转效率。

审批链配置：三种路由规则

审批链，就是一张单据从提交到最终通过，需要经过哪些节点、以什么顺序流转。设计审批链的核心挑战是：如何让规则既满足管理要求，又不过度僵化。

在实际系统中，审批链通常通过三种路由规则来配置。

规则一：按金额分级

这是最常见、最直观的规则。金额越大，风险越高，需要的审批层级也越高。

一个典型的金额分级审批链如下：

graph TD
    A[提交单据] --> B{金额 < 1万}
    B -- 是 --> C[主管审批]
    B -- 否 --> D{金额 < 10万}
    D -- 是 --> E[经理审批]
    D -- 否 --> F[总监审批]
    C --> G[审批通过]
    E --> G
    F --> G

按金额分级的优点是规则清晰、易于理解。缺点是金额阈值需要随业务变化定期调整，否则可能出现"9.9 万元的订单只需经理批，10.1 万元的订单就必须总监批"这种边界上的刚性跳跃。

规则二：按部门路由

同一类单据，在不同部门可能有不同的审批路径。例如，研发部门的采购申请需要技术总监审批，而市场部门的采购申请则需要市场总监审批。

按部门路由的本质是组织映射：系统根据单据的所属部门，自动找到对应的审批人和审批层级。

规则三：按角色匹配

角色匹配是比"指定具体人"更灵活的做法。审批节点上不写"张三审批"，而是写"部门经理审批"。系统根据单据的提交人，动态查询他所在的部门的经理是谁。

角色匹配的优势在于人员变动时无需修改流程。如果销售经理换人，只要更新组织架构中的角色绑定，所有审批流会自动适配。

这三种规则通常组合使用。一个完整的审批链配置可能是：先按部门确定审批模板，再按金额确定审批层级，最后用角色匹配找到具体的审批人。

会签与或签

审批链里的单个节点，还可能涉及多人审批的情况。这时候就要区分两种模式：会签和或签。

会签：所有人都必须同意

会签要求节点上的所有审批人都给出"同意"意见，该节点才算通过。只要有一人拒绝，单据就被打回。

适用场景：风险较高、需要多方共同把关的环节。例如，一笔大额付款申请需要财务经理和财务总监同时确认；一个新供应商准入需要采购、质量、财务三个部门共同审核。

或签：任一人都可决定

或签要求节点上的审批人只要有任意一人处理，该节点即算完成。其他审批人自动跳过。

适用场景：审批人互为备份、需要保证时效的环节。例如，销售经理出差期间，其审批权限可由代理经理行使；或者一个审批节点设置了"部门经理或副经理"，谁有空谁批。

两种模式的对比：

维度	会签	或签
通过条件	所有人同意	任一人同意
风险特征	严控风险，多人把关	追求效率，互为备份
典型场景	供应商准入、大额付款	日常报销、代理审批
超时影响	任一审批人超时即卡死	其他审批人仍可处理

在设计审批流时，会签和或签的选择不是非此即彼。一个审批链里，某些节点用会签，某些节点用或签，是很常见的组合。关键在于：这个节点承担的职责是"控制风险"还是"保证效率"。

金额分级审批：决策表与实现逻辑

金额分级审批看似简单，但产品化设计时有很多细节需要考虑。

审批决策表

下面这张表可以作为金额分级审批的基础模板。实际使用时，企业根据自身规模和风险偏好调整阈值和层级。

单据类型	金额区间	审批层级	预计时效
采购申请	< 1 万元	部门主管	≤ 4 小时
采购申请	1 - 10 万元	部门经理	≤ 1 个工作日
采购申请	> 10 万元	总监 + 财务	≤ 3 个工作日
费用报销	< 5 千元	直属上级	≤ 4 小时
费用报销	5 千 - 2 万元	部门经理	≤ 1 个工作日
费用报销	> 2 万元	总监 + 财务	≤ 2 个工作日
销售订单（超信用）	< 5 万元	销售经理	≤ 4 小时
销售订单（超信用）	≥ 5 万元	销售经理 + 财务	≤ 2 个工作日

这里要注意两个设计细节：

第一，金额区间必须无重叠、无遗漏。 如果一个订单金额恰好是 10 万元，系统必须明确它属于"1 - 10 万"还是"> 10 万"，不能出现规则真空。

通常的做法是，让上限包含在区间内，如"1 万 ≤ 金额 ≤ 10 万"。

第二，不同单据类型应独立配置。 采购申请和销售订单的金额含义完全不同，不能共用同一套阈值。产品设计上，审批规则应该与单据类型解耦，各自维护。

分级审批的伪代码实现

以下是一段简化的金额分级审批判定逻辑，展示系统如何根据单据类型和金额自动选择审批链：

function getApprovalChain(docType, amount) {
  const rules = [
    { type: "PR", max: 10000,  chain: ["DEPT_LEAD"] },
    { type: "PR", max: 100000, chain: ["DEPT_MANAGER"] },
    { type: "PR", max: Infinity, chain: ["DIRECTOR", "FINANCE"] },
    { type: "EXPENSE", max: 5000, chain: ["DIRECT_LEAD"] },
    { type: "EXPENSE", max: 20000, chain: ["DEPT_MANAGER"] },
    { type: "EXPENSE", max: Infinity, chain: ["DIRECTOR", "FINANCE"] },
  ];

  const matched = rules
    .filter(r => r.type === docType && amount <= r.max)
    .sort((a, b) => a.max - b.max);

  return matched[0]?.chain ?? ["DEPT_LEAD"];
}

这段代码的核心思路是：先按单据类型过滤，再按金额上限排序，取最小匹配值对应的审批链。如果没有任何规则命中，就回到一个默认的安全审批链，避免系统因为规则配置不全而直接放行。

超时处理：审批不能无限期等待

审批流设计中最容易被忽视、但实践中投诉最多的问题，是超时。

一个审批任务发出后，如果审批人迟迟不处理，单据就会无限期挂起。下游流程无法推进，提交人反复催促，最终审批流于形式，大家转而走"线下找人打招呼"的捷径。

解决超时问题，产品层面通常有三种策略：自动升级、自动催办、超期自动拒绝。

策略一：自动升级

当审批任务超过设定时间（如 24 小时）未处理时，系统自动将该任务升级给更高一级的管理者。

场景拆解：销售订单因信用超限进入审批，销售经理 24 小时内未处理。系统自动将任务升级给销售总监，并通知销售经理该任务已被升级。这样既保证了时效，也对审批人形成了软性约束。

自动升级的关键设计点是升级边界。如果一直升上去，最终可能升到 CEO 面前，这是不合理的。产品设计上，通常设置"最高升级层级"，超过后不再升级，而是转入人工催办。

策略二：自动催办

系统在超时前和超时后，向审批人发送催办通知。催办频率可以逐步递增：超时前 2 小时提醒一次，超时后每 4 小时提醒一次。

催办的渠道可以多样化：系统消息、邮件、企业微信、短信。对于特别重要的单据，还可以同时抄送审批人的直属上级。

策略三：超期自动拒绝

对于某些时效性极强的单据，系统可以配置"超期自动拒绝"策略。超过一定时间未审批，单据自动被拒绝，提交人需要重新发起。

适用场景：限时促销活动的价格审批、月末关账前的紧急付款申请。这类单据如果错过时间窗口，即使后来审批通过，业务价值也已经丧失，自动拒绝反而比无限期挂起更合理。

三种策略并不是互斥的。一个完善的超时处理机制通常是：先催办，再升级，对特殊单据设置自动拒绝底线。

审批流引擎的可配置化思考

审批流引擎是 ERP 系统的通用基础设施。不同企业、不同部门、甚至同一企业在不同阶段，审批规则都可能不同。如果每换一个规则就要改代码，系统维护成本会高到无法接受。

所以审批流引擎的核心设计目标，是可配置化。

配置化的三个层次

第一层：规则可配置

审批节点、审批人、金额阈值、会签/或签模式、超时策略，都应该在管理后台通过界面配置，而不是写死在代码里。

第二层：流程可编排

除了修改规则参数，业务人员还应该能够编排审批流程本身：增加节点、删除节点、调整节点顺序、设置条件分支。低代码或可视化流程编排器，正在成为现代审批流引擎的标配。

第三层：日志可追溯

每一次审批操作，系统都必须记录：谁、在什么时间、对哪张单据、做了什么操作、附了什么意见。这个审计日志不仅是内控要求，也是事后纠纷处理的关键证据。

审批流配置清单

如果你在评审一个审批流引擎的产品设计，可以用下面这张清单做快速检查。

检查项	是否支持	说明
按金额分级	是 / 否	不同金额区间匹配不同审批层级
按部门路由	是 / 否	同类型单据在不同部门走不同流程
按角色匹配	是 / 否	不绑定具体人，绑定角色
会签模式	是 / 否	多人全部同意才通过
或签模式	是 / 否	任一人同意即通过
超时升级	是 / 否	超时自动转交上级
超时催办	是 / 否	自动发送催办通知
超期拒绝	是 / 否	超时可配置自动拒绝
审批记录	是 / 否	完整记录谁、何时、做了什么
流程回退	是 / 否	审批不通过时可退回修改

这张表的价值在于，它把"审批流引擎是否够用"这个问题，从主观感受转化成了 10 个可逐项验证的功能点。

总结：从纸质签字到规则引擎

审批流是企业管理制度在系统中的投射。纸质时代，审批靠"人找人、纸传纸"；电子时代，审批靠"规则引擎自动路由"。

但技术只是手段，不是目的。审批流的真正价值，在于让企业的内控制度变得可执行、可观测、可优化。

可执行，意味着规则不再是口头约定，而是系统里的明确配置。可观测，意味着每一张单据走到哪一步、卡在谁那里，都一目了然。可优化，意味着企业可以通过分析审批时长、驳回率、超时率，不断调整规则，让流程越来越顺畅。

我们在第 1 篇中看到的 PR 审批，在第 9 篇中看到的信用审批，在第 28 篇中讨论的权限设计，再加上今天这篇文章的审批流设计，共同构成了企业操作的完整控制框架：权限划定边界，审批验证操作，日志记录痕迹。

下一篇文章，我们将进入这个系列的全新篇章：DDD 战略设计。我们会从产品设计视角切换到架构视角，聊聊如何用领域驱动设计的方法，划分业财系统的业务边界。敬请期待。

往期回顾

关于十三Tech

资深服务端研发工程师、架构师、AI 编程实践者。
专注分享真实的技术实践经验，持续记录企业系统、架构设计与 AI 编程实践。