实施指南
多子公司合同权限最容易踩的七个坑
集团型企业做合同权限设计时特有的七类问题：集团可见性与主体隔离的优先级、多协同租户的身份对齐、授权阈值、关联交易、数据驻留、台账口径与人员调动后的权限残留。
- 作者
- Zico 团队
- 发布
- 更新
约 4 分钟阅读
结论
单主体企业的合同权限基本是部门加职级两个维度，规则不多。集团型企业多出一个主体维度之后，复杂度不是线性增加的：同一个人可能在三家主体里有不同角色，同一份合同的两方可能都属于本集团，不同主体的数据还可能受不同司法辖区约束。
下面七条都是多主体结构特有的，不是通用的权限常识。它们的共同点是在单主体阶段完全不会暴露，在我们经手的项目里，多在第二家主体接入后的第三到第六个月集中出现。
一、集团可见性与主体隔离没定优先级
集团法务希望看到全部主体的在途合同，各主体又希望自己的商务条款不被兄弟公司看到。这两个诉求天然冲突，而多数项目在设计阶段回避了它，做成「原则上隔离，需要时开放」，等于把决定权推给了后续的个案审批。
可行的做法是把可见性拆成两层：元数据层（主体、对方、金额区间、状态、到期日）对集团法务默认可见，正文与条款细节按主体隔离，需要时走申请。这样集团统计和风险扫描能做，商业敏感信息也不会默认外泄。拆不开的时候，至少要在项目启动时明确哪一方优先，而不是留到上线后吵。
二、多个协同租户，身份体系对不齐
几家主体各自开了协同平台租户，或者一部分在飞书、一部分还在旧 OA，是集团里的常态。问题在于同一个人在两个租户里是两个账号，组织架构树也是两棵，合同系统同步过来之后会出现同名不同人、同人不同号。
这一步如果不先解决，后面所有权限规则都建在流沙上：按部门授权会漏人，按人授权会重复。处理顺序应该是先确定一个人员主数据源（通常是 HR 系统而不是任何一个协同租户），再由合同系统从主数据取人，协同租户只负责登录和待办推送。
三、授权阈值只做了一套
集团通常有一份统一的合同授权制度，规定多少金额以上需要哪一级审批。落到系统里常见的做法是配一套全局阈值，但实际上各主体的规模差异可能有一两个数量级：对总部是小额的金额，对一家新设子公司可能需要董事会。
阈值应该可以按主体分别配置，同时保留一条集团兜底规则。另一个容易漏的是币种：出海主体的合同以外币计价，阈值判断必须先换算，汇率取哪一天的也要写进规则，否则审批层级会在汇率波动时漂移。
五、数据驻留要求按主体不同
境内主体和境外主体受不同规则约束，有的合同数据不能出境，有的则相反。统一部署在一个实例里，意味着最严格的那条要求会变成全集团的约束，成本上不划算；完全分开部署，集团视图又拼不出来。
折中的方式是正文按实例驻留、元数据集中，即合同文件留在各自合规的存储里，主体、金额区间、状态、到期日这类不敏感的结构化字段汇总到集团层。评估阶段要问清的是这种拆分是否被产品原生支持，还是需要定制；如果对 AI 推理也有不出境要求，还要确认模型的运行位置，私有化 LLM 的当前状态以产品页标注为准。
六、台账字段口径不统一
这一条不属于技术权限，但会让前面所有权限设计白做。各主体自行定义合同类型、风险等级和状态，集团层拿到的数据无法汇总：同样叫「框架协议」，A 公司指的是采购框架，B 公司指的是销售框架；同样标「高风险」，判断标准差了一截。
必须在上线前统一的字段不多，通常是合同类型、状态机、风险等级、主体和币种这五项，其余允许各主体自定义。统一的成本在启动阶段是一次会议，在运行两年之后是一次数据清洗工程。
七、跨主体兼职与调动后的权限残留
集团里一人身兼数职很常见：某人是 A 公司的法务负责人，同时在 B 公司挂名。调动或离职时，HR 通常只处理主任职关系，兼职身份留在系统里，合同权限跟着残留。
权限模型要能表达「同一人在不同主体的不同角色」，并且回收要按主体逐个进行，而不是按人一刀切。稳妥的做法是定期做一次权限复核，把当前有效授权导出来与 HR 的在职名单比对。这件事没有捷径，但它是多主体结构里最容易出事、也最容易被忽略的一项。
一个可以现在就做的自查
导出当前能访问集团任意一家主体合同正文的全部账号，按主体分组，逐个确认是否仍然必要。多数企业第一次做这件事时会发现超出预期的条目，尤其是在完成过并购或主体重组之后。