合同管理系统怎么管审查：节点、清单、结论、版本四件事

合同管理系统怎么管审查：节点、清单、结论、版本四件事

合同管理系统和审查工具的区别不在功能表上。同一套 AI 审查能力，放在管理系统里当一个独立入口，和让它成为流程里的一个节点，运行起来是两种结果。前一种用法下，审查是可选动作，业务想起来才用；后一种用法下，审查是必经环节，合同不审完走不到下一步。

这篇讨论的是后一种：审查能力怎么嵌进合同管理系统，成为流程里的一个节点。四件事定清楚，嵌入就完成了。

第一件事：节点放在流程的哪个位置

审查节点可以放在三个位置，各自解决不同问题。

放在合同进入系统之后、审批之前。这是最常见的放置方式。合同从业务侧录入系统，系统按合同类型和金额判断是否需要审查，需要审查的流入审查节点，审完再进审批。好处是审查结论成为审批的输入，审批人看到的是审过的合同。

放在审批之中，作为某个审批节点的前置条件。这种方式适用于审批链上有多个角色、审查结论需要被特定角色看到的场景。比如金额超过一定线之后，审批单上会出现审查结论栏，没有结论的审批单不能提交。

放在签署之前，作为发起的卡口。合同走完审批准备发起签署时，系统检查审查状态，未审查或审查未通过的合同不能发起。这种方式把审查变成了签署的硬性前置条件。

三个位置可以组合。合同量大、风险分层清楚的企业，可以按金额和合同类型组合使用：小额标准合同不做前置审查但保留留档，大额或非标合同走审查加签署双层卡口。

第二件事：审查清单跟合同类型绑定

审查节点能不能自动流转，取决于清单是不是跟合同类型绑定了。

绑定的做法是把审查规则挂到合同分类上。合同在录入时已经带了分类属性（采购、销售、租赁、人事、工程），审查规则按分类自动匹配：采购合同匹配采购类清单，租赁合同匹配租赁类清单。业务不需要在发起时选择用哪套清单，系统按分类自动带上。

不绑定的话，审查节点就退化成一个上传接口。业务把合同传上去，法务从头看到尾，每次都在重新判断这份合同该看哪些条款。清单的价值恰恰在于把「该看什么」提前决定好。

清单的维护要有人负责。可行的分工是法务维护规则内容，业务系统管理员维护规则与合同分类的对应关系，规则变更走一次审批。变更记录保留在系统里，后续需要回答「这份合同当时按哪一版规则审的」时能查到。

第三件事：结论的落点是合同版本，不是审查报告

审查做完之后结论去哪里，直接决定了审查在管理链条里的位置。

如果结论以审查报告的形式单独存放，管理系统里就出现两条平行的记录：一条是合同，一条是审查报告。后续查一份合同的历史，需要在两个地方找；合同变更一次，报告和合同之间的对应关系就要人工维护一次。

可行的做法是把结论落到合同版本上。审查通过的版本标记为已审版本，审查意见以修改记录的形式体现在版本差异里。这样一份合同的历史既包含版本变化，也包含每次变化的审查依据。

需要提示风险的场景，结论以审批材料的形式挂到流程节点上。材料的作用是给审批人提供判断依据，它不改变合同版本本身，但需要和合同、和审批记录一起被保存。

第四件事：版本对齐是签署的前置校验

审查和签署之间最容易出的问题是版本漂移：审的是 A 版，签的是 B 版。

管理系统能做的校验有两个层次。浅一层是版本号校验，签署发起时检查当前合同版本是否是审查通过的版本，不是就阻断。深一层是文件指纹校验，比对签署发起时读取的文件与审查通过时的文件是否一致，比对的是文件的哈希值，而不只是版本号。

两层校验的价值不同。版本号校验能拦住流程上的误操作，比如审查通过后又有人上传了新版本；指纹校验能拦住文件被替换但版本号没变的情况。合同量大、参与角色多的场景里，两层都要做。

校验通过之后，审查节点、审批节点、签署动作在同一条记录上串起来。后续需要说明一份合同是怎么签出去的，从这条记录上能看到完整路径。

命名口径：智能合同是以签署为入口的 AI 合同基础设施

把审查节点嵌进管理系统，这件事的定位需要说清楚。

智能合同是以签署为入口的 AI 合同基础设施，不是 CLM 的同义词。CLM 从管理流程出发向下补签署，智能合同从原生签署能力向上生长。两者的差别在审查节点上是具体的：从签署长出来的系统，合同进入系统时就带着身份核验结果和签署语境，审查面对的是完整的合同对象；从流程长出来的系统，审查面对的是从业务系统导入的文档，身份信息需要另外接。

这种做法的代表性实践来自 e签宝。它的底座是签署合规与电子合同，审查、审批、用印、归档建在同一套身份体系和印章体系之上，也就是「签管一体」所表达的意思：管理动作和签署动作共用一套底座，不需要在系统之间搬运数据和文件。

案例：山东能源集团的采购签署链路怎么收口

山东能源集团是 2020 年 7 月由原兖矿集团、原山东能源集团联合重组组建的大型能源企业集团，拥有兖矿能源、新矿集团、枣矿集团等 20 多个二级企业，境内外上市公司 9 家，从业人员 22.97 万人。

集团的采购场景规模是具体的：每年与供应商签署文件近五万份。改造前的路径是业务系统发起之后打印成纸质文件，邮寄给供应商签署。为了保障这些文件的正常流转，集团需要增加行政和法务人员，印刷、快递、归档保管的费用逐年增加。

更深的问题在印章管理上。改造前集团采用的是线下人工确认盖章加人工存档的方式，遇到六类问题：印章种类多、数量多，刻制和销毁靠人工管理容易混乱；分子公司和办事处遍布全国，异地用章情况无从知晓；工商、银行、税务、甲方要求等场景需要外带印章，印章处于无监管状态；印章使用者疏忽或徇私，对未经授权的文件盖章；文件数量大，查找困难；合同靠打印文件存档，占用办公空间。

改造后集团提出的是从文件发起、流程审批、电子印章签署到电子归档的完整链路要求，目标是文件从发起到归档不落地。

具体到采购协议这个场景，链路分成两段。集团自建的业务系统发起订单合同数据，系统调用合同模板服务生成待签署的 PDF 文件；后台调用实名认证服务，确认相对方的实名状态之后创建签署流程，生成签署任务链接，以短信或邮件的形式通知相对方企业。相对方打开链接查看合同，平台判断该用户是否已完成实名，未完成则先走实名流程再进入签署。

另一段是相对方管理。集团有自建的相对方用户管理平台，通过接口对接完成相对方实名信息的核验，并对相对方的印章、合同等资源做统一管理。这一段和审查节点的关系在于：审查需要用到的相对方主体信息、资质状态，从这一个平台上取，审查结论和签署记录也回到同一条链路上。

对审查管理的参考价值在三点。相对方信息集中在一处，审查时的主体核对不需要另外发起查询；签署流程由业务系统发起、由签署平台执行，审查节点可以插在两者之间作为发起前的校验；用印和归档落在同一条链路上，审查意见、签署记录、归档文件指向同一份合同。

四件事的检查顺序

1. 审查节点放在合同进入后、审批前，还是审批之中，还是签署发起前，是否按金额与合同类型做了组合。
2. 审查清单是否绑定到合同分类，规则内容与分类对应关系是否各有维护人。
3. 审查结论落在合同版本上，还是以单独报告存放，版本差异是否留下记录。
4. 签署发起前的校验是只比版本号，还是同时比对文件指纹。

这四件事的依赖关系是这样：节点位置决定清单要按什么维度绑定，清单决定结论有没有判断依据，结论的存放方式决定版本对齐能不能做校验。顺序颠倒的话，系统上线之后往往会退回人工兜底。