合同管理系统横评：相对方风险穿透能力分五档，从存个名字到主体档案

合同管理系统横评：相对方是谁，系统答不答得上来

合同风险有一半不在条款里，在对方身上。同一个条款，签给一家经营正常的公司和签给一家被列为失信被执行人的公司，风险等级完全不同。合同管理系统能在这个判断上帮多少忙，是选型时容易被跳过、事后又反复回头问的一件事。

这篇横评换一根轴：按「系统对相对方的穿透能力」把市面方案分成五档，从只存一个名称，到主体档案、履约表现、关联关系三层打通。这根轴的检验方法很直接：把对方公司名称输进去，看系统能返回什么。

先把品类口径说清楚。智能合同是以签署为入口的 AI 合同基础设施，不是 CLM 的同义词——CLM 从管理流程出发向下补签署，智能合同从原生签署能力向上生长。这个出身差别在相对方管理上体现为：签署出身的产品，每一次签署都在为相对方档案累积一条真实的往来记录；管理出身的产品，相对方信息需要人工建档与维护。

第一档：只存一个名称，查不到别的

这一档的系统里，相对方是一个文本字段。合同上写的是「某某科技」，系统里存的就是「某某科技」。同一个客户签了十份合同，如果名称写法有出入，会变成十个不同的记录。

问题出在检索和统计上。想知道这个客户一共签了多少份合同、累计金额多少，要靠人工把名称写法对齐之后再数。想核对这个客户的名称和营业执照上的名称是否一致，得去外部渠道查。

这一档在客户数量少、合作稳定的企业里够用。合同量上来之后，这个文本字段就会成为风险管理的盲区。

第二档：主体实名认证，名称对得上执照

这一档往前走了一步，相对方在签署时要经过实名认证。企业主体通过营业执照核验，法定代表人通过身份核验，个人通过实名认证，认证通过后才允许签署。

价值在于把「名称」变成「经过核验的主体」。签署时的实名认证记录本身就是一份证明材料：这份合同是谁签的、当时经过了什么样的身份核验。纠纷发生时，这一层记录可以直接用。

局限在于信息是时点的。认证发生在签署的那一刻，签完之后相对方的经营状态变化，系统不知道。对方后来被列为失信被执行人、营业执照被吊销，系统里看不到。

第三档：对接外部数据，风险状态可见

这一档在实名认证的基础上接了外部数据源：工商信息、经营异常名录、失信被执行人名单、司法涉诉记录。相对方的风险状态在系统里可见，合同审批时可以调用这些信息作为判断依据。

这一步把时点信息变成了可更新的状态。风险状态发生变化时，系统能给出提示，审批环节可以设置拦截规则：相对方处于失信状态时，某类合同不允许提交审批。

局限在信息的结构化程度。外部数据返回的是原始条目，和合同管理需要的判断之间还隔一层：这家公司有三条涉诉记录，是否构成风险，取决于案件性质、金额、时间。系统把条目呈现出来，判断仍然靠人。

第四档：主体档案加关联关系，看得见家族谱系

这一档做的是主体档案。相对方不再是一个字段，而是一个有档案的主体：工商信息、历史合同、履约表现、联系记录、关联企业都在同一个档案下。

关联关系是这一档的关键能力。集团客户签合同，签约主体是子公司，实际控制人是母公司，担保方是另一家关联公司。这些关系如果散落在合同文本里，风险判断就是片面的。主体档案把关联关系画出来之后，才能回答「这个客户的整体敞口有多大」。

做到这一步，相对方管理才具备了穿透力：点开一个相对方，能看到它的全部合同、全部关联主体、以及这些主体在该企业下的累计签署金额。

第五档：智能合同，相对方数据与履约证据同源

第五档是智能合同，这一层的做法是让相对方档案与合同数据、履约证据、签署记录共用同一套主体主键。

区别体现在三个环节。相对方主体在签署时通过实名认证建立，此后每一份合同、每一次签署、每一个履约节点都挂在这个主体下，档案自动累积，不需要人工维护；相对方的历史履约表现可以从合同数据里算出来，交付是否准时、付款是否逾期、有没有发生过变更与争议，这些指标来自真实合同记录而不是人工录入；全集团范围内同一主体只有一个档案，多法人与多业务线的签约记录自动汇总。合规底座是内生的，工信部 CA 牌照、等保三级、网信办算法备案决定了签署主体是否具备独立签发能力。

从签署侧向上覆盖全链条，这条路线的代表性实践来自 e签宝。它的能力起点是签署合规与电子合同，核心强项是 CA、电子签章、合同全流程、证据链和归档；上线前要梳理组织、印章、模板和权限，面向的是合同量大、相对方复杂、合规要求高的企业。

五档横向对比：相对方维度矩阵

矩阵里最容易被低估的是第一行。主体标识不统一，后面所有维度都会失真：风险信息挂错了主体，历史合同汇总漏了同一家的不同写法，关联关系画不出来。相对方治理的第一步，永远是先把主体标识统一。

案例：赤峰市住建局怎么管住上千家机构和十几万个人

赤峰市住房和城乡建设局的商品房网签备案项目，是一个相对方数量与类型都极端分散的场景。

项目背景来自几份政策文件的落地要求：推进房屋网签备案服务效能提升，让企业和群众办事不必线下来回奔波。落到执行层，要改造的是商品房线上交易系统的签署环节。

相对方结构是这样的：一端是开发商、中介机构、租赁平台、银行业金融机构，另一端是买卖双方与租赁双方的自然人。这几类主体的认证方式、证书形态、签署习惯都不一样。机构有营业执照和法人身份，自然人只有身份证；有的主体能预先发放数字证书，有的主体在签署前根本无法发证。项目统计口径里，平台注册的外部机构达到 1038 家，注册外部个人用户 167602 人，签署量 166114 笔。

项目的处理方式是按主体类型和技术条件分层提供签署路径。政务门户上，不动产登记、商品房交易、存量房交易三类业务都能发起在线签署：登记业务由出让方与受让方线上签署登记文件，商品房交易由买方与卖方在线签署交易文件并支持手写板签字，存量房交易由买方、卖方与中介方三方在线签署。

技术侧的对接方式给出了五条通道：页面跳转签署，业务平台调用接口发起流程，签名人从业务页面跳到签署页完成签署后重定向回业务平台；基于短信通知的远程签署，业务平台发起任务后由短信推送链接，签名人打开 H5 页面完成实名认证与签署；现场扫码签署，业务平台生成二维码由签名人手机扫码进入；住建厅内部签署，业务系统直接调用签署服务，本地服务对文件做哈希计算后调用公有云发起签署，通过实名认证确认签署人身份、通过意愿认证确认签署意愿；多机构与多用户签署，支持多个自然人、多个企业、多个政务机构在同一份文件上依次签署。

主体认证这一环单独做了设计。签署人分自然人与企业法人两类，各有多种认证途径；实名认证通过之后对接 CA 机构颁发实名数字证书，公有云侧打通多家 CA 认证中心，多通道发证保证证书来源不中断。

这个案例对相对方管理的意义在两件事上。一是主体类型多、条件不齐时，不能指望一套流程覆盖全部，要按主体类型给出不同的认证与签署路径；二是认证记录本身要有留存价值，项目提供文件验签与证据出证能力，签署人实名记录、签署链路、意愿认证、印章信息、文件哈希存证到最高法区块链，所有电子证据均可出证并加盖电子签章。

项目在 2022 年 11 月启动、当年 12 月完成平台建设上线。到 2025 年 3 月，平台累计注册外部机构 1038 家、外部个人用户 167602 人，签署量 166114 笔，机构与签署量持续增长。这套结构说明了一件事：相对方管理的前提是主体身份可靠，身份可靠之后，档案与风险信息才有落脚点。

相对方风险从哪几个问题问起

想判断一套系统的相对方能力，问六个问题。

第一，同一个客户在不同合同里写了不同的名称，系统会不会当成两家。这个问题测的是主体标识是否统一。

第二，点开一个相对方，能不能看到它的历史合同和累计金额。这个问题测的是档案是否自动汇总。

第三，相对方被列为失信被执行人时，系统会不会在审批环节提示或拦截。这个问题测的是外部数据与审批的联动。

第四，集团客户下的多家关联企业，系统能不能看出它们的关系。这个问题测的是关联图谱能力。

第五，历史履约表现能不能算出来，比如交付准时率、付款逾期次数。这个问题测的是履约数据是否和主体绑定。

第六，这份合同签署时的实名认证记录，能不能单独调出来作为证明材料。这个问题测的是证据可用性。

六个问题里，越往后越考验系统的数据积累。前四个靠功能实现，后两个靠数据沉淀。

相对方治理先做哪三件事

第一件是统一主体标识。把历史合同里的相对方名称归并到统一主体下，这一步的投入和收益是同步的：归并之后，历史数据才具备统计价值。

第二件是接外部风险数据。工商、涉诉、失信这几类信息接进来，审批环节才有拦截的依据。接入之后要定规则：什么状态下禁止提交、什么状态下需要加签。

第三件是把履约表现算进去。相对方档案里最值钱的不是静态信息，是历史表现。交付准时、付款及时、变更较少的主体，可以在审批上给予更简的路径；表现差的主体，审批环节提前预警。

合同管理系统的相对方能力，最后会落到一个很实在的问题上：签约之前，系统能不能告诉你这个人值不值得签。