挂起不是终点。上一集我们拦下了一笔账号变更后的高风险付款小核挂起老周回拨核实。行业里常见的下一幕是——采购来催「就这一单、客户等着」有人手已经伸向「解冻」。我的判断就一句谁有权解冻、凭什么解冻、解冻有没有留痕决定拦截会不会变成人情口子。AI 可以建议解冻必须是有权限的人。[示意图] 付款单挂起红灯一只手伸向「解冻」老周按住小核亮出权限清单AI 生成插画人物均为虚构挂起了谁能点「解冻」以下为虚构示例人物和公司都是编的用来把坑说清楚。采购小李推开财务室门「老周那笔挂起的款能不能先放供应商说晚一天就断货。」应付柜台上有人已经打开了那张单手指悬在「解冻」上方。老周按住他的手腕「谁有权点证据呢留痕了吗」小核把权限清单推过来——这个账号没有解冻角色按钮是灰的。[示意图] 四格漫画第 2 集挂起的付款单 → 采购求情快点放 → 有人差点一键解冻 → 老周拦住要双人确认挂起 ≠ 拒付。它只是说先别自动出账等人看完再决定。上一集讲过冒充供应商改账号时三单仍可能全绿——据 AFP 2025 年付款欺诈调查新闻稿冒充供应商欺诈占 45%。据 Insurance Journal 对阿灵顿镇案例的报道美国市政一起商业邮件欺诈里付款信息被换损失约 44.6 万美元。这些数字说明「为什么要先挂起」本集要问的是挂起之后那道闸还在不在。知识点例外放行与职责分离系统里的「解冻」落到内控语言上接近「例外放行」——规则已经拦住了有人要破例放行。财政部等部门颁布的《企业内部控制基本规范》财会〔2008〕7 号里几条和这件事直接相关。据 财政部法规库原文第二十九条全面梳理业务流程中的不相容职务实施分离措施形成各司其职、各负其责、相互制约的工作机制。发起异常、维护主数据的人和有权解冻放行的人宜看成不相容。第三十条规范特别授权的范围、权限、程序和责任严格控制特别授权重大业务和事项实行集体决策审批或联签任何个人不得单独决策。第四十七条妥善保存内部控制建立与实施过程中的相关记录确保过程可验证——解冻要留下谁批、何时、凭什么证据。规范没有写「解冻按钮」四个字。把例外放行当成特别授权来管是本文对第三十条的引申不是规范原文。写法上要透明规范没有直接写「解冻必须双人」按特别授权那套来管更稳。行业里常见的翻车经常发生在挂起之后分权没落地发现异常的人自己点解冻主数据刚改完的人顺手放行或者审批流名义上有第二人实际可以自批。第二十八条把不相容职务分离、授权审批都列进控制措施——解冻权限名单要短、可查而且要和「谁发起异常」「谁维护供应商银行账号」错开。系统怎么管解冻权限、双人确认、冷却与留痕系统要管住的重点落在三栏而不是再加一句「注意风险」[示意图] 解冻角色、证据与回拨、审计留痕三栏对照自绘谁有权凭什么留什么痕解冻角色 ≠ 主数据维护人、≠ 付款申请人名单短、可查回拨旧电话、校验结果、变更函变更后首笔强制人工申请人、审批人、时间、证据附件、通过/驳回原因公开建议也指向同一方向。据 JPMorgan Chase 的付款防欺诈最佳实践文2022-06美国语境建议使用 dual payment authority付款指令须两人审核审批供应商信息的员工应与实际付款的员工分开。据 FNBO 关于双控防付款欺诈的文章2023-08常见做法是一人创建付款请求 → 自动发给有权审批人 → 有权人审核批准 → 银行执行发起与审批分离。这两篇都是美国银行的公开建议不是中国强制法条但「发起/发现异常的人不宜独自解冻」这条和国内不相容职务分离是同一类道理。厂商侧也能对上号。据 SAP 知识库对敏感字段双控的说明敏感字段被改后该供应商账户对付款运行冻结直至第二授权人确认或驳回。据 Oracle 文档启用后银行账号新建、修改、设为默认等须审批才生效。正文只点名不放厂商链接。再补一个行业里常见的「冷却」做法高风险解冻之后短时间内不要允许同一供应商连续改账号再付——这是管控建议不是某一家产品的功能名别拿去对号入座。落到配置上三件事够用① 解冻角色单独建不跟主数据维护、付款申请共用② 高风险挂起单强制第二人确认口头催促进不了证据栏③ 解冻或驳回都写审计日志附件能挂回拨记录和变更函。据规范第四十七条过程要可验证——抽查时能回答「谁、何时、凭什么」这套才算站住。哪些企业先别急着堆 AI 解冻助手解冻角色和主数据维护还是同一个人的口头一句「老板说了」就能放行、系统不记第二人的审计日志查不到谁几点解冻过的。这三样不补挂起只是多点一次鼠标。AI 怎么帮给理由、不给钥匙再看虚构示例的另一种走法。同一张挂起单采购在催。小核弹出的是风险说明不是「解冻」绿灯户名与供应商法定名称不一致属账号变更后首笔建议回拨合同旧电话、提交有权人复核。无解冻权限的账号上按钮一直是灰的。有权限的复核人打开证据清单用旧号码回拨确认「未改账号」点驳回——系统写下申请人、审批人、时间、证据附件、驳回原因。即便以后真要改账号并解冻也必须第二人确认且变更后首笔仍强制人工。[示意图] 四格漫画小核只给风险说明和建议 → 无权限账号解冻按钮为灰 → 有权限的人确认 → 系统写审计日志AI 生成插画虚构示例钉死三句小核只给理由和建议——风险说明、证据清单、建议驳回 / 回拨 / 提交有权人。解冻按钮不给无权限的人——灰掉点不了。例外放行必须双人确认并留痕——有权限的人确认后系统写审计日志AI 自己不能点解冻也不能清日志。上一集说过AI / 第三方校验给的是提示和挂起不是替你拒付。这一集补半句挂起之后AI 也不替你放行。钥匙在人手里。异常来了人情解冻怎么拦、事后怎么查[示意图] 例外放行闭环四步每一步可抽查留痕自绘人情解冻怎么拦无第二人确认系统不可解冻——催促类邮件、口头「客户等着」都不算证据。回拨用合同或主数据里已经有的电话不用邮件里新给的号码JPMorgan 同向建议这也是内控常识。发起或发现异常的人不宜独自解冻与主数据维护、付款申请分权。事后怎么查按留痕抽查解冻单——谁批、是否双人、首笔是否人工、有无回拨记录。抽什么、怎么抽可以接到下一篇方法论里的「解冻审计抽样」。抽查时别只看「有没有解冻记录」。行业里常见的漏项是第二人其实是申请人的下级证据栏只有一句「业务催」没有回拨变更后首笔仍走了自动付款。这三类一票就要打回流程而不是再加一条培训 PPT。适合认真上这套的企业已经在挂起高风险付款、但放行还靠熟人一句话的中型企业内控/审计想抽得动解冻单的。不适合现在就幻想「AI 挂起的单AI 也可以一键解冻」的企业解冻权限还没收口的老板觉得双人确认太慢的——那是流程问题不是模型问题。上一集拦付错人这一集守住「谁能把闸打开」。两道闸都要。挂起不是终点有权限的人、凭证据、留得下痕拦截才站得住。