什么是合同审查清单？
合同审查清单是签署前用于系统核对文件范围、交易事实、权利义务、风险分配和最终版本的工作框架。它不仅提醒审查者“看什么”，还应记录问题来自哪里、影响什么、怎样处理、由谁决定以及是否已经关闭。
高质量审查不是按页寻找“不利条款”，而是验证合同能否准确表达交易、能否被组织执行，以及出现变化或失败时后果是否可理解、可承受。清单提供覆盖面，却不能取代对交易背景、法域规则和组织政策的专业判断。
这套清单适合商业合同的第一轮系统审查和签署前复核。具体合同可能涉及消费者、劳动、金融、医疗、出口、竞争、数据或其他专门规则；遇到重大责任、陌生结构或受监管事项时，应交由具备相应资格与经验的专业人员审阅。
先定义审查任务与完整合同包
开始逐条阅读前，先写清交易目的、审查阶段、己方角色、计划签署日期、不可变的商业条件和需要决定的问题。确认审查对象包含主协议、订单、工作说明、附件、政策、价格表、数据处理文件、担保、既有修订以及合同通过引用纳入的材料。
范围确认问题：这次审查是初稿、对方红线还是待签终稿？哪些附件仍为空白？哪些网页条款可能随时更新？是否存在同一交易的旧协议、口头承诺、招标文件或采购订单？缺失材料应作为待办记录，而不是默认“不适用”。
同时确定交付形式：问题清单、带修订稿、商业选择表或签署建议。审查者、业务负责人、财务、信息安全和专业法律人员各自回答不同问题，避免所有事项无差别地堆给一个角色。
核对主体、签署权限与文件优先顺序
确认合同上的完整法定名称、注册信息、地址和关联方范围与实际交易一致；明确谁提供服务、谁付款、谁使用成果、谁承担责任，以及签署人是否代表正确主体。集团品牌、部门名称和法律实体不能混用。
把所有文件画成简单层级：主协议控制什么，订单或工作说明补充什么，附件适用于哪些服务，冲突时哪份文件优先。若“订单优先”和“主协议优先”同时出现，或不同文件对同一事项给出不一致答案，应直接列为问题。引用的政策、技术规范和在线条款也要保存当时适用的版本。
用商业事实检验合同是否写对了交易
向业务负责人核实实际交付物、时间表、使用场景、依赖条件、价格模型、关键假设、数据流、知识产权来源、第三方参与、实施地区和退出安排。合同文本即使内部一致，也可能与真实运营方式不同。
| 需要确认的事实 | 常见文本错位 | 审查动作 |
|---|---|---|
| 服务和交付边界 | 销售材料承诺的功能未进入附件 | 把关键承诺转成可验证要求 |
| 时间与资源依赖 | 一方负责的输入未写入进度条件 | 明确前置条件与延误后果 |
| 数据与系统访问 | 协议未覆盖实际处理的数据类别 | 核对数据路径与安全文件 |
| 商业容忍度 | 责任、退出或排他承诺超出业务预期 | 确认授权人和可接受替代方案 |
检查定义是否覆盖正确对象并贯穿全文
定义决定条款适用范围。检查重要定义是否过宽、过窄、循环引用、与附件冲突或包含未提供的文件；特别留意“关联方”“保密信息”“数据”“服务”“成果”“适用法律”“工作日”和“重大违约”等词。
对每个关键定义做一次代入测试：把定义的完整含义放回付款、授权、责任和终止条款，观察结果是否仍符合交易。检查“包括”是否限制范围，“书面”是否包含电子方式，“合理”由谁判断，以及标题、单复数、优先语言和解释规则会不会改变理解。定义错误往往会同时扩散到多个章节。
让范围、交付、验收与变更形成闭环
交付物应能够识别，质量要求应可判断，里程碑与前置依赖应可追踪。核对谁提供人员、系统、资料和场地；若一方延迟输入，日期怎样调整；分包是否允许；成果何时视为交付。
验收条款要说明测试标准、审查期间、拒收理由、整改次数、重新提交、默示验收和未解决问题的后果。避免一边写“以客户满意为准”，另一边又默认到期自动验收。变更机制应明确谁能提出、如何评估费用与工期、何时批准，以及批准前是否继续工作。
把价款、付款、税费和调整机制算到可执行
逐项核对计价单位、数量、币种、税费、折扣、最低承诺、可报销费用、开票条件、付款日期和逾期后果。用一个真实账期演算付款条款，验证“收到发票后”“月末后”和“验收后”等触发是否清楚，发票争议是否只影响争议部分。
对价格调整、用量计费、汇率、指数化和自动续费，检查计算基准、数据来源、通知期、生效时间、上限、异议方式和退出选择。若付款义务依赖订单、采购编号或验收记录，确认这些流程在组织内确实可完成，并避免合同正文与价格附件互相矛盾。
检查生效、续期、终止与退出后的连续动作
区分签署日、生效日、服务开始日、初始期限和各订单期限。核对自动续期的周期、提醒窗口、价格变化与非续约方式；将通知最晚日期按实际日历演算，避免期限存在但无法操作。
终止权应与现实风险匹配：因重大违约、持续未履行、资不抵债、监管变化、安全事件或便利而终止时，是否有通知、补救期和部分终止安排。退出后还要处理未付款项、预付费用、数据返还、迁移协助、库存、设备、账户访问、保密和继续有效条款。终止本身不是退出计划。
把每项重要承诺写成责任、触发、期限与证明
对关键承诺回答六个问题：谁负责、为谁做、何时触发、何时完成、依赖什么、用什么证明完成。检查义务是否单向失衡、是否依赖第三方、是否需要不受控制的结果，以及权利与对应的配合义务是否成对出现。
留意通知、报告、记录保存、审计配合、培训、许可维护、保险证明和合规证据等容易散落在附件中的持续义务。对无法实际监控的承诺，决定是改写为可操作标准、增加责任人和证据，还是明确接受执行成本。
区分事实陈述、持续承诺与补救方式
确认陈述与保证由正确主体作出，时间点和知识限定清楚，内容与尽调材料一致。避免对无法控制的第三方、绝对无错误结果或所有法域作出无限范围承诺；也不要用过宽免责声明消除交易不可缺少的基本保证。
检查违反保证后是整改、重做、退款、赔偿、终止还是多种救济并存，是否设置通知或专属救济。合规承诺应连接实际业务、地区与角色；发现未知事项时，记录需要事实核实或专业意见，不要仅凭清单判断法律结论。
按具体失败场景核对赔偿、责任限制与保险
先列出对本交易最重要的失败场景，例如服务中断、数据泄露、知识产权主张、人身或财产损害、延误、监管调查和第三方索赔。再检查谁控制风险、谁能预防、损失如何发生，以及合同中的责任分配是否覆盖这些场景。
责任限制需要同时阅读上限基数、计算期间、损失类型排除、例外、相互性和多个索赔如何累计。赔偿条款还要核对触发条件、被保护主体、通知、抗辩控制、和解同意、配合和费用。保险名称或额度不能自动证明风险已转移，应确认保单范围、除外和证明要求是否与承诺相符。
审查重点：不要只标记“有上限”或“有赔偿”。应记录上限在一个现实损失场景中的实际结果、哪些请求不受上限保护、救济之间是否重复，以及组织中谁有权接受剩余暴露。
分开审查保密、数据、安全与知识产权
保密条款应明确保护对象、允许用途、可披露人员、保护标准、法定披露、例外、期限和返还销毁。数据条款则要覆盖数据角色、类别、目的、地点、访问、分包、事件响应、保存、删除、审计和跨境安排；保密义务不能替代必要的数据处理与安全安排。
知识产权部分应区分既有材料、项目成果、通用工具、第三方内容、反馈、数据和衍生成果，明确所有权与许可的范围、地域、期限、转许可、修改和退出后使用。确认履约所需的每项权利都已获得，也确认授权没有意外覆盖与交易无关的技术或内容。
检查转让、分包、排他与控制权变化
转让和控制权变化条款可能影响融资、重组或交易退出；核对是否需要同意、是否有集团内例外、同意能否被不合理拒绝，以及转让后原主体是否继续负责。分包安排要说明是否需批准、主承包方是否继续承担责任，以及数据和安全要求是否传递。
对排他、最惠待遇、竞业或渠道限制，明确产品、客户、地区、期限、例外和解除条件，并验证组织是否能够持续监测。此类约定可能受到不同地区规则影响，不能只凭模板决定可执行性；需要时应取得针对事实与法域的专业意见。
预演不可抗力、通知、适用法律与争议路径
不可抗力条款要检查事件范围、受影响义务、通知、减损、持续时间、付款义务和长期中断后的退出，而不是只看是否出现标题。对灾难恢复、供应短缺或监管变化等可预见事件，另行确认是否需要业务连续性要求。
通知条款应提供可用地址、接收角色、允许方式和生效规则，并与终止、索赔和价格调整的通知要求一致。争议机制要明确升级人员、协商或调解步骤、法院或仲裁地、适用规则、临时救济、语言和费用。把一个实际争议走一遍，检验时间与地点是否现实。
在通用清单上叠加合同类型的专属检查
通用清单解决覆盖面，专属层解决交易差异。不要把所有检查项强行套给每份合同，也不要因为使用模板就忽略实际服务。
| 合同情境 | 需要额外确认 |
|---|---|
| 软件或云服务 | 可用性计算、支持级别、版本变化、数据导出、停服与迁移 |
| 专业服务 | 人员资格、成果标准、工时费用、客户依赖、验收与替换人员 |
| 货物供应 | 规格、预测与订单、所有权和风险转移、检验、召回与备件 |
| 许可与内容 | 权利链、使用范围、报告、版税、署名、下架与侵权处理 |
| 场地或资产使用 | 交付状态、维修、费用分担、保险、进入权、恢复与腾退 |
专属层应由熟悉该业务和适用规则的人维护，并随着事故、争议、政策变化和谈判经验更新。
把审查发现转成可决策的问题日志与谈判计划
每个重要发现都应连接文件、条款和原文位置，并写明问题是什么、在什么场景下产生影响、需要补充什么事实、建议立场、可接受替代、决策人、责任人、截止时间和状态。不要只写“高风险”或“建议修改”，否则业务无法判断选择。
| 字段 | 记录要求 |
|---|---|
| 来源与现状 | 文件、版本、条款位置、当前文字或缺失项 |
| 情境与影响 | 触发场景、受影响业务、后果和证据确定度 |
| 处理建议 | 首选修改、可接受备选、所需事实或控制措施 |
| 决定与权限 | 决定人、理由、条件、日期和绑定版本 |
| 关闭证明 | 最终文字、附件、外部控制、批准或明确接受 |
谈判顺序应围绕目标而不是条款页码：先解决会改变交易是否成立的问题，再处理责任与退出，最后清理一致性和文字。对方拒绝修改时，区分是否能通过价格、流程控制、保险、技术措施或退出权降低风险，并确认这些补偿措施确实有人执行。
签署前做一次独立的版本、附件与决定核验
- 锁定文件包。确认主协议、附件、订单和政策均为最终版本，没有空白字段、批注或未接受修订。
- 对照问题日志。逐项验证修改是否进入正确位置，未修改事项是否获得适当决定且条件已满足。
- 复核交叉引用。检查定义、编号、日期、金额、主体名称、通知信息、附件名称和优先顺序。
- 确认签署条件。验证内部批准、对方权限、必要证明、先决条件和签署方式。
- 准备履约移交。记录生效日、重要期限、责任人、付款、续期、通知和保存位置。
- 保存签署证据。保存完整签署件、签署记录、最终决定和适当的审查轨迹。
最终复核最好由未参与逐字修改的人按清单完成。它不是重新谈判，而是发现“已同意但未写入”“附件遗漏”“签错主体”和“红线合并错误”等交付缺陷。
让 AI 辅助定位与整理，但把判断留在明确责任链中
AI 可以清点文档、定位候选条款、比较版本、抽取待确认事实并生成问题日志初稿。提示应要求返回原文位置、未知项和冲突，不应让模型用常见条款填补缺失内容。高影响发现要回到完整上下文与有效文件，由适当人员确认。
在上传合同前，核对是否获得授权，工具如何处理、保存和传输数据，谁能访问输入与输出，以及结果是否会被用于训练。评估工具时使用经过授权的代表性材料，测试遗漏、错误关联和版本混淆，而不只是观察摘要是否流畅。
先提供明确审查目的和完整文件，再要求结果连接原文、事实缺口与建议责任人；最后由合格人员核对重要事项，并把已确认结果带入谈判与签署决定。
合同审查清单的十二个常见错误
未确认交易目的和完整文件包。
没有检验范围、条件和实际结果。
同一个词在多处扩大或缩小责任。
权利、付款和责任落到错误实体。
关键范围、价格或安全标准并未确定。
忽略基数、例外、损失类型和救济叠加。
承诺没有对应地区、角色和证据。
没有场景、来源、处理方案和决策人。
没有准备可交换条件和替代控制。
未核对最终文件是否真正合并。
义务、续期和通知没有移交。
忽略法域、行业与交易特有问题。
合同审查清单常见问题
合同审查清单是签署前用于系统核对文件范围、交易事实、权利义务、风险分配和最终版本的工作框架。有效清单不仅列出问题，还记录来源、影响、拟议处理、责任人和状态，使审查结果能够进入谈判与签署决定。
先确认审查目的、完整文件包、正确主体、签署权限、交易结构和关键商业事实，再进入定义、履约、价款、期限、责任、数据、知识产权与争议等条款。若文件边界或事实基础错误，逐条审查也可能得出错误结论。
不能。清单可以提高覆盖率和记录一致性，但不能自行判断特定事实下的法律效力、监管要求或可接受风险。涉及重大责任、复杂结构、受监管事项或不熟悉法域时，应由具备相应资格和经验的专业人员审阅。
同时考虑发生可能性、财务与运营影响、纠正难度、时间紧迫性、证据确定度和组织承受能力。优先级必须连接具体条款、业务情境和决策人，不能只依赖脱离上下文的统一分数。
AI 可协助整理文件、定位相关文字、比较版本、生成候选问题并把发现连接到原文。对关键遗漏、条款适用、法律解释和风险接受仍需人工确认；敏感材料还应先核对上传授权、访问、保留和数据处理条件。