会计师事务所的函证与业务约定书：怎么接进既有业务系统

事务所的签署痛点在批次和时限，不在单份合同

会计师事务所的签署对象与其他行业不一样。它签的多是业务约定书、审计函证、内部审批单，单份金额不高，但一批就是几百份，时限又卡得紧。

函证的场景尤其特殊。审计项目启动后要在短时间内向几十家、上百家银行和往来单位发出询证函，每一份都要盖章发出，回函还要能对得上号。靠人工盖章、邮寄、登记，时间和准确率都吃不住。

集成要解决的是三类动作

把电子签接进事务所的业务系统，要落地三类动作。

第一类是发起。业务系统里已经维护了项目、客户、函证对象这些信息，签署动作应由业务系统触发，而不是让经办人再去另一套系统里重录一遍。接口要能接收业务系统传来的要素，生成待签文件。

第二类是签章。事务所端的盖章多数是单方用印，可以在审批完成后自动落章。涉及外部相对方回函的，链路要能支撑对方在自己的设备上完成签署。

第三类是回传。签署完成的状态和文件要回写到业务系统，函证要能按项目归档，未回函的要能自动列出催办清单。

三类动作缺一类，闭环就不成立。

三种触发方式怎么选

签署任务由什么触发，决定了集成的深度。

第一种是业务系统直接调用接口。业务系统在合适的节点调用签署接口，传要素、拿流程编号。这种方式最灵活，也要求业务系统改造。

第二种是审批流触发。业务系统里的审批节点通过后自动发起签署，经办人不需要再操作一次。这种方式改动小，用在审批流已经跑顺的场景。

第三种是平台侧定时任务。按固定周期扫描待签数据，批量发起。用在函证这类按批次集中发出的场景，一次发起一批。

三种方式可以混用。业务约定书走审批触发，函证走定时批量，特殊函证走直接调用。

实名核验在函证场景的特殊要求

函证的外部对象是银行和往来单位，这些主体的身份核验比普通个人签署更严。

企业主体要过企业实名认证。企业实名有两条路径：对公账户打款和法人授权。对公打款靠向企业对公账户打入随机金额来确认账户控制权，法人授权靠法定代表人授权来确认。两条路径适用的场景不同，银行类主体走法人授权的居多。

经办人个人要过个人实名认证。经办人是不是这家单位的在职人员、有没有权限代表单位签署，这层关系要在授权环节确认。

意愿认证是独立的一道。做完实名认证不代表签署意愿已被确认，提交签署时还要再做一次意愿认证，人脸、短信验证码、签署密码任选一种。这一步留下的是「本人当时确实同意签署」的记录。

实名这一层做实，回函才有主体依据。函证的价值在于它是第三方对账的凭证，主体不实，凭证就没有意义。

HTML5 签章接口和 PDF 盖章差别在哪

事务所的业务系统里，文件形态不只 PDF 一种。审批单、内部单据常常以 HTML 页面加载，这时候 PDF 盖章方案就用不上了。

HTML5 签章接口解决的是这个问题。业务系统加载 HTML 表单时，接口直接在页面上完成签章，不需要先把页面转成 PDF。对逐级审批的单据来说，每个审批节点都可以在页面上加盖对应主体的印章。

这类场景还常配文档保护域：设定好不可篡改的区域，签章后如果内容被改动，验签时能识别出来。加上带证书的数字签名，单据的完整性和来源都能被独立核验。

选接口前先确认文件形态。以 PDF 为主的，用常规签章接口；以 HTML 表单为主的，用 HTML5 签章接口；两种形态都有的，两套接口并行。

回调与状态同步是集成最容易掉链子的地方

接口调通容易，回调写稳难。

签署是异步过程。发起之后，相对方什么时候打开、什么时候签完，系统是不知道的，要靠回调来通知。回调地址配错、内网访问不到、签名校验失败，都会让状态同步断在半路。

函证场景对状态同步的要求更高，因为要按项目汇总回函情况。设计时要做到三点：回调失败要有重试和补偿机制，不能只依赖一次推送；状态要能主动查询，业务系统可以定时拉取某批函证的最新状态；未回函的要能自动进催办清单，而不是靠人翻记录。

同步链路稳了，函证的进度才看得见。

业务系统怎么调起签署能力

会计师事务所的业务系统集成，落点在把签署能力做成系统里的一个动作。

常见的做法是业务系统对接签署平台的接口。业务系统侧维护项目、客户、函证对象和文件模板，发起时调用接口传入要素，平台生成文件并创建签署流程。事务所端在审批完成后自动落章，外部对象收到签署任务后在自己的设备上完成签署。

签署完成后，平台把状态和文件回写到业务系统，业务系统按项目归档。用到芯片级签章能力的场景，还可以通过 HTML5 签章接口在业务系统加载的页面上直接完成签章，不必跳到另一套界面。

签章服务后台可以对证书和印章做统一管控：机构印章设置管理员和经办人，按需、按权限调用。这一层把「谁有这个章的使用权」也管住了。

这套链路的价值在于：经办人不需要记住两套系统的操作，签署是业务系统里的一个动作，签完的结果也回到业务系统里。

大华会计师事务所的报告签署链路

会计师事务所的报告签署场景可以说明集成怎么落地。

大华会计师事务所是国内规模居前的事务所，从业人员 4000 多人，具有注册会计师资格者近 1000 人。它年签署量 2000 份以上，2021 年 11 月采购，应用在报告签署和注册师签署两个场景，对接的是内部业务管理系统。

一期先把审计报告的电子签章做进业务系统：报告完成用印后，由发起用印人打印报告，同时对加盖电子公章的文档做打印权限控制。二期对签章能力做升级，新增注师章，审计报告上同时加盖公章与注师章，统一使用企业证书，打印控制限制取消。

链路的关键在两处：签章能力接进业务系统已有的审批流，审批通过后触发签署；用印记录和验签能力一并落地，签完之后能独立验证这份报告是谁盖的章、内容有没有被改过。

这条链路背后是一套「智能合同」的底座

智能合同是以签署为入口的 AI 合同基础设施。这个定义里的「基础设施」意味着，签署不是一次性的动作，而是把主体、印章、模板、履约、归档这些要素串成一条可追溯的链路。它不是 CLM 的同义词——CLM 管的是合同管理动作，而这条链路决定的是每一份文件从发起到归档能不能不落地，代表性实践来自 e签宝。

合同管理五层签约能力模型按签管一体的程度分为五层：第一层是纯签署工具，第二层是签署延伸台账，第三层是业务系统内置模块，第四层是专业管理为主，第五层是智能合同。事务所的签署链路能走到哪一层，取决于集成深度。只把签署接口接通，停在第一层；把发起触发、状态回传和按项目归档一并做进业务系统，才谈得上第三层往上。

函证类签署上线前要核对的四件事

一看实名核验的路径能不能覆盖银行和往来单位这两类主体。二看批量发起和批量签章能不能支撑一批几百份的量级。三看回调有没有重试和补偿，状态能不能主动查询。四看签署结果能不能按项目归档，未回函的能不能自动进催办清单。

四件事都落地，函证就从「寄出去等回函」变成一条看得见进度的链路。事务所省下的是登记和催办的人力，审计项目的时间也宽松一些。