合同管理系统横评:谁在什么时候盖了什么章,查得出来吗
用印是合同管理里最容易被低估的环节。签合同要盖章,盖章这件事看起来只是一个动作,实际上牵扯三件事:谁有权限盖、什么时候能盖、盖完之后能不能查。审计来的那天,问的正是这三件事。
这篇横评换一根轴:按「用印行为的可审计程度」把市面方案分成五档,从只留一条签署记录,到电子印章与实体印章统一留痕、时间线可还原。检验方式是用一个具体场景去问:三个月前那份合同的章是谁盖的、依据的是哪次审批、当时盖的是电子章还是实体章。
先把品类口径摆出来。智能合同是以签署为入口的 AI 合同基础设施,不是 CLM 的同义词——CLM 从管理流程出发向下补签署,智能合同从原生签署能力向上生长。这个出身差别在用印管理上很直接:签署出身的产品,用印行为天然产生完整的过程数据;从流程侧接入的用印能力,留下的只是一张审批单和一份盖章文件,中间的过程不留痕。

第一档:只留签署记录,过程不留痕
这一档的系统里,盖章这件事留下的是一条结果记录:这份合同在某个时间完成了签署,文件里有印章图像。
审计问起来,能回答的是「盖了」,回答不了的是「怎么盖的」。谁发起的用印申请、经过了谁的审批、盖章时用了什么验证方式、盖的是哪一枚章,这些信息分散在邮件、聊天记录和审批系统的日志里,要拼起来得靠人回忆。
这一档在印章单一、用印频次低的企业里勉强够用。用印量上来、印章数量增加之后,这条审计链就断了。
第二档:审批流加用印记录,能回答谁批的
这一档把用印接入审批流。发起人提交用印申请,审批链条上的每个人留下审批记录,审批通过后执行盖章,系统记录盖章时间与操作人。
审计链条上有了一半。能回答「谁申请、谁审批、什么时候盖」,回答不了的是「盖章时的身份是不是本人」——审批通过和实际盖章是两个动作,如果执行环节没有二次验证,审批人批准的和执行人盖的未必是同一回事。
这一档的典型结构是用印申请单:一张单子对应一次用印,单子上带文件、印章、审批意见。它的问题在于单子和文件之间的绑定关系靠人工确认,文件改了没有、改的是哪一版,单子上看不出来。
第三档:意愿认证加印章授权,盖章这个动作本身留痕
这一档在盖章环节加了身份验证。执行用印时要做意愿认证:人脸识别、短信验证码、密码验证、指纹,验证通过才允许盖章。系统记录盖章时的认证方式、认证结果、操作时间与操作人。
印章授权也是这一档的能力。谁能用哪一枚章、用章需要什么级别的审批、单次用印有没有数量上限,这些规则在系统里配置,权限之外的人调不到章。用印记录里因此多了两列:用的是哪一枚章、这个人的权限来源是什么。
做到这一步,审计可以从「谁批的」推进到「谁盖的、凭什么能盖」。剩下的缺口在实体印章:很多企业的章是实体的,盖章发生在办公室的桌子上,系统管不到。
第四档:物电一体化,实体章和电子章一起管
这一档解决的是实体印章的问题。做法是把实体印章装进印控设备:印章锁在设备里,用印需要审批通过后获取解锁码或由系统远程解锁,盖章时设备拍摄使用人照片记录实际操作者,盖章次数和用印文件都能被记录。
物电一体化的价值在于审计链的完整性。一份合同盖的是电子章,另一份盖的是实体章,同一份合同上两种章都有的情况也存在。把两条链路合到一套记录里之后,审计问的「这份合同的章是谁盖的」才有唯一答案。
这一档的实施成本高一些,因为要采购硬件、要安排用印点、要培训印章管理员。收益在于覆盖了电子章管不到的场景:财务章、法人章、需要外带的合同章。
第五档:智能合同,用印与合同数据同源
第五档是智能合同,这一层的做法是让用印记录与合同数据、审批记录、签署日志共用同一条时间线。
区别体现在三个环节。用印行为挂在实际合同版本上,审计时能看到盖的是哪一版文件,文件之后有没有变更;审批、用印、签署的记录统一到同一份合同的日志下,出证时不需要跨系统拼接;全集团范围内同一枚印章的使用记录自动汇总,跨法人的用印数据统一到一套审计视图里。合规底座是内生的,工信部 CA 牌照、等保三级、网信办算法备案决定了签署主体是否具备独立签发能力。
从签署侧向上覆盖全链条,这条路线的代表性实践来自 e签宝。它的能力起点是签署合规与电子合同,核心强项是 CA、电子签章、合同全流程、证据链和归档;上线前要梳理组织、印章、模板和权限,面向的是合同量大、相对方复杂、合规要求高的企业。

五档横向对比:用印审计维度矩阵
| 评测维度 | 第一档 签署记录 | 第二档 审批加记录 | 第三档 意愿认证授权 | 第四档 物电一体化 | 第五档 智能合同 |
|---|---|---|---|---|---|
| 审批留痕 | 无 | 完整审批链 | 完整审批链 | 完整审批链 | 审批 + 版本绑定 |
| 盖章人身份 | 无记录 | 操作人账号 | 意愿认证记录 | 意愿认证 + 现场拍照 | 全链路可还原 |
| 印章权限 | 无 | 人工分配 | 规则配置 | 规则 + 设备管控 | 规则 + 集团统一视图 |
| 实体章覆盖 | 不覆盖 | 不覆盖 | 有限覆盖 | 覆盖 | 覆盖并与电子章合并 |
| 文件版本绑定 | 无 | 人工确认 | 授权范围内 | 印控记录文件 | 绑定签署版本 |
| 审计导出 | 无 | 审批单导出 | 用印台账 | 用印 + 照片 + 记录 | 全链路证据包 |
矩阵里最值得看的是「文件版本绑定」。用印记录如果不知道盖的是哪一版文件,审计链在最关键的一环断掉:文件内容改了,盖章记录还在,两者对不上。
案例:天同律师事务所怎么把实体章和电子章一起管住
天同律师事务所成立于 2002 年,在重大复杂商事争议解决领域提供服务,业务覆盖诉讼、仲裁、执行、破产,在上海、深圳、南京、郑州、重庆、西安、三亚等地设有办公室。天同全部案件在自研的「天工系统」中办理,2021 年 12 月完成系统升级后上线使用。
律所的用印场景比多数企业复杂。一方面文件类型多:授权委托书、律师函、OA 内部文件、人力资源类合同、投标文件、投标入库文件、卷宗调用单;另一方面性质特殊:有些文件是单方用印,有些要相对方实名认证后签署,还有一些涉及印章外带。
项目要解决的问题是把分散的用印行为收进一套体系。天同的做法是物电一体化:电子签章与物理印控在同一套流程里管理,审批入口统一在钉钉,用印类型按电子或实体分流。
电子签章侧的流程是这样的:律师在钉钉工作台的 OA 审批中发起电子签章用印,审批通过后收到消息通知,点击预签署链接自动跳转到预签署页指定盖章区域;相对方收到签署短信链接,经过账号登录、实名认证、意愿认证后完成签署;签署完成的合同可以通过钉钉消息查看和下载。
物理印控侧的流程由同一入口进入:审批通过后,使用者前往印控台,在界面输入有效的六位用印码解锁使用。进入任何具体的用印操作之前,系统都会要求人脸拍摄,这一步记录的是实际用印人;人脸对准印控台主面板摄像头,拍摄完成后自动进入用印操作界面。
印章外带场景单独做了设计。使用者通过专用应用登录公司账号开始用印,通过蓝牙连接用印设备后操作盖章,同样需要人脸采集,信息获取成功后解锁章筒完成盖章。
系统集成上,钉钉集成了电子签章系统与物理印控系统,北森系统对接电子签,档案侧电子文件归档至钉钉与自研的天工系统,物理用印审批通过后获取用印码解锁印章,覆盖财务等外带场景。
这个项目在审计层面留了一个可复用的结构:每一次用印都有明确的审批来源、操作人记录与执行方式。电子章的记录来自签署系统,实体章的记录来自印控设备加现场照片,两类记录归到同一套审批体系下。审计要查某次用印时,能沿着审批编号直接找到对应的签署文件或印控记录。
对律所这类机构来说,用印审计的价值不只在于合规,还在于职业责任:代理文件上的印章如果无法追溯来源,风险落在律所自己身上。这套把物电两条链路并到一处的结构,正是为了解决追溯问题。
用印审计从哪几个问题问起
想判断一套系统的用印能力,问六个问题。
第一,三个月前某份合同的章是谁盖的,依据的是哪一次审批。这个问题测审批与用印的绑定关系。
第二,盖章那一刻有没有做身份验证,验证方式是什么。这个问题测执行环节的独立性。
第三,盖的是哪一版文件,盖章之后文件有没有被改过。这个问题测版本绑定。
第四,实体印章的用印记录能不能查到,谁在什么时候用了哪一枚章。这个问题测物电一体化覆盖度。
第五,某一枚印章最近半年被谁用过,一共用了几次。这个问题测印章维度的统计能力。
第六,审计要一份完整的用印证据包,系统能不能直接导出。这个问题测证据包能力。
六个问题里,前三个多数系统能答上一两项,第四到第六个才是分档线。
用印治理先做哪三件事
第一件是给每一枚印章建台账。印章的名称、类型、保管人、使用范围、启用与停用时间,这些信息先集中起来。印章数量不清,后面的授权与审计都无从谈起。
第二件是把用印和审批绑死。没有审批单不允许用印,这条规则要落在系统里而不是制度里。审批单和用印记录之间要有一条明确的引用关系。
第三件是给执行环节加验证。审批通过不意味着可以盖,盖章这个动作需要独立验证操作人身份。这一步是防内部风险的关键,也是外部审计最常查的点。
合同管理系统的用印能力,最后的检验标准很简单:审计来的时候,能不能在十分钟内把一次用印的完整链条调出来。
微信端
支付宝
IOS版
安卓版
鸿蒙版
钉钉端
飞书端
企微端
客户端



