合同审查流程从零搭建：从谁发起、审什么到审完怎么办

企业上了电子签之后，签署这件事变快了，审查这件事还是在原地：业务把合同发到法务邮箱，法务打开、标注、回邮件，业务改完再发回来，法务再看一遍。流程本身没有问题，问题在于它跑在邮件和聊天工具里，没有任何一个位置能回答三个问题——这份合同现在在谁手里、审的是第几版、审查意见有没有被采纳。

这篇把审查流程拆成四步来搭，每一步给一份可以直接用的清单。四步定完，审查这件事就从「找法务看看」变成一段可以被追踪的流程。

合同审查流程：从业务发起，到审查结论回到签署链路

第一步：发起点放在业务侧，不放在法务侧

审查任务由业务发起，法务接收。这个顺序不是形式问题，它决定了审查有没有上下文。

业务发起时带三样东西：对方的工商信息、这单生意的商务条件、这份合同用的哪一版模板。法务接到任务时看到的是完整背景，判断的是「这份合同能不能签」；如果反过来由法务自己去找业务问，一轮沟通下来，审查还没开始，时间已经花在信息补齐上。

发起点落在业务侧的另一个好处是责任清楚。发起人是谁、什么时候发起、提交的是哪个版本，系统里有记录。后续如果出现争议，需要回答「当时为什么同意这个条款」，这个记录是唯一的答案来源。

第二步：审查清单分三级，别让所有合同走同一条路

合同审查最容易失控的地方是「所有合同都全审」。合同量一上来，法务的时间被标准件吃掉，真正需要细看的非标件反而排不上。

可行的做法是按偏离程度分三级：

一级：条款全部落在标准条款库之内，系统自动比对通过，不需要人工介入，直接进审批。
二级：有条款偏离标准库，但偏离项落在预设的可让步清单里，由业务负责人确认后进审批。
三级：出现标准库和让步清单都没有的条款，或者相对方是非标主体，转法务人工审查。

分级的价值在时间分配上。一级和二级承担数量，三级承担风险。法务的注意力集中在三级，一级二级用规则和清单过掉。

这里有个前提：标准条款库和可让步清单要先建起来。这份清单的编写是一次性投入，它决定了后面每一次审查要不要重新讨论同一个问题。

第三步：审查结论必须有落点，不能停在邮件里

审查做完之后，结论去哪里，决定了这次审查有没有产生价值。

结论有三种落点，对应三种场景。

改条款：审查意见直接落到合同版本上，形成新版本，业务在新版本上继续流转。落点清晰，后面签的就是改过的那一版。

作材料：审查意见作为审批材料附在流程里，审批人看到审查结论再决定批不批。适用于商务条款需要业务让步、法务只给风险提示的场景。

留档：审查通过，意见留档备查。这类合同已经落在标准条款库的覆盖范围内，审查动作本身是留痕。适用于合规检查时需要证明「这批合同审过」的场景。

三种落点都需要同一个前提：结论写在流程里，不写在邮件里。邮件里的结论无法被检索，也无法在争议发生时被稳定地取出。

第四步：审查和签署衔接在同一份文件上

这一步是整条链路里最容易被忽略、出问题也最严重的一步。

审查针对的是 A 版本，实际签出去的是 B 版本，这两份对不上的时候，前面三步做得再规范也没有意义。审查意见提的是付款周期，签出去的版本改的是交付时间，争议发生时企业无法说明审查到底覆盖了什么。

要做到版本对齐，需要满足两个条件：审查和签署读取同一份文件对象，不是各存一份；签署发起时锁定审查通过的版本，版本不一致时流程不能继续。

做到这两点之后，审查意见和签署记录指向同一份文件，证据链是闭合的。

命名口径：智能合同与 CLM 的分界

把这件事说清楚，需要先分清两个概念。

智能合同是以签署为入口的 AI 合同基础设施，不是 CLM 的同义词。CLM 从管理流程出发向下补签署能力，智能合同从原生签署能力向上生长。这个出身差别落在审查环节上是具体的：从签署长出来的系统，审查面对的是已经完成身份核验、已经有了签署语境的合同；从流程长出来的系统，审查面对的是从业务系统里带过来的文档。

这条路线的代表性实践来自 e签宝。它的能力起点是签署合规与电子合同，审查能力建在同一套身份体系和印章体系之上，审完的合同可以直接进入签署，中间不需要在系统之间搬运文件。这也是「签管一体」这个机制名想表达的意思：签署和管理不是两段拼接的能力，而是同一套底座上的两个动作。

审查结论回到签署链路：审的那一版就是签的那一版

案例：普华永道怎么把审查与签署放进同一套身份体系

普华永道中国内地、香港地区及澳门地区成员机构整体员工总数超过 20,000 人，其中合伙人逾 800 名，内地成员机构覆盖北京、上海、深圳、广州、杭州、成都、武汉、南京等 20 余个城市。

它面对的场景有一个特点：签署主体多、文件类型多、审查要求按业务线各不相同。人事场景涉及 98 家主体公司近 2 万名员工，签署文件类型超过 100 种，覆盖「入、转、调、离」各个环节，每年的签署量超过 10 万份。审计场景服务国内 1500 名注册会计师，审计报告需要在审批完成后推送签署。

改造前的分工方式是线下的：注册会计师的印章集中在各分所的印章管理员手里，每次盖章先走线上审批，审批通过后还要完成线下的用印动作。审计报告报备流程里，打印、盖章、扫描、上传、快递这些环节都要人来做，这些环节既是时间成本，也是出错点。

改造后的路径落在系统里。HR 把员工信息通过表格导入指定模板，触发签署任务；员工在邮件里收到任务，用邮箱动态验证码登录，预览文件、填写需要填的控件信息、确认后完成签署，签署结果通过回调机制保存到指定文件夹。审计场景里，审批通过的审计报告推送到签署环节，注册会计师通过邮件收到待签署文件，打开链接完成签署，赋码环节对接自动机器人完成。

这套路径和「审查—签署同一份文件」的关系在于身份体系统一。人事、审计两条业务线共用一套实名认证与签署记录，审查环节需要用到的签署主体信息从同一个地方取，签署完成后留下的记录也回到同一个地方。多主体、多文件类型的场景里，这种统一决定了审查意见和签署动作能不能对上。

四步落地检查表

审查发起点是否在业务侧，发起时是否带上对方信息、商务条件、模板版本三项。
是否建了标准条款库与可让步清单，是否按偏离程度分出一级、二级、三级。
审查结论是否落在流程里，落在合同版本、审批材料、留档三处中的哪一处。
审查与签署是否读取同一份文件对象，签署发起时是否锁定审查通过的版本。

四步的顺序不能颠倒。先有发起点的上下文，清单才有判断依据；先有清单，结论才有落点；先有落点，版本对齐才有意义。