一笔款，打给了假供应商

三单都对上了为什么钱还能打给假供应商上一集我们讲过三单匹配拦的是多付、错量、错价。这一集说的是另一道门收款人是谁。很多老板默认「资料齐、匹配绿钱就该付」。行业里常见的情况是出事的那一笔订单、入库、发票一点都不差差的是主数据里那张「身份证」——银行账号被人悄悄换了。小核亮出止付老周对着一张打给假供应商的付款单皱眉*我的判断就一句付给假供应商往往不是三单对不上而是供应商主数据和银行账号被调包。三单管量价不管收款人。资料齐了为什么还能把钱打给假供应商先看一个虚构示例人物和公司都是编的用来把坑说清楚。采购小李新建供应商「某某五金」营业执照、合同都贴上了系统显示「V-8821已准入」。银行栏写的是开户名「某某五金有限公司」、对公账号。过了几天一封「紧急我司账户变更」的邮件进来发件域名只差一个字母。有人在系统里把收款账号改成了个人卡户名变成个人姓名没走第二人复核。订单、入库、发票照样匹配通过——因为量价没变。应付按绿灯做付款申请审批看金额和三单没人点开账号变更记录。直到正牌供应商催款「钱怎么还没到」老周一对银行回单钱已经进了个人卡。四格漫画建档资料齐 → 邮件诱使改成个人卡且未复核 → 付款照常过 → 正牌供应商催款才发现*这里有两个外行容易画错、也容易想错的点。一是付款账号取自主数据里的默认银行账号不是取自发票上的某行字。二是三单全绿只说明货和价对上了说明不了钱打给谁。这不是漫画夸张。公开报道显示美国马萨诸塞州阿灵顿镇在一起商业邮件欺诈里有人冒充高中建设项目的承包商要求把支票改成电子转账约四个月里付款被截损失约 44.6 万美元445,945 美元正牌供应商催款才发现。据 Insurance Journal 的报道这是美国市政的公开案例不是中国案例但手法和上面那个示例是同一类账单流程看起来正常被换的是收款信息。更大范围的数字也指向这件事。据 AFP 2025 年付款欺诈调查新闻稿521 名以美国为主的企业财务从业者里79% 的组织在 2024 年遇到过付款欺诈这个数含未遂其中冒充供应商欺诈占 45%。据 FBI IC3《2023 Internet Crime Report》美国 IC3 口径下商业邮件欺诈BEC当年有 2.1489 万起投诉报告损失约 29.5 亿美元。另据 ACFE 2024 年职务舞弊报告基于 2022 年 1 月至 2023 年 9 月调查的 1,921 起全球案例开票舞弊占 22%损失中位数 10 万美元通常 18 个月才被发现——ACFE 这组讲的是职务舞弊里的开票类手法含空壳开票等和 AFP 的「冒充供应商」不是同一套故事别混成一个数。知识点供应商主数据与银行账号才是付款的「身份证」供应商主数据可以理解成付款用的身份证法定名称、税号、地址、联系人以及最关键的——收款银行账号开户行、账号、账户名称、是不是默认账户。据金蝶云产品手册供应商档案里就有开户银行、银行账号、账户名称、币别、是否默认账户这些字段一个供应商只能有一个默认账户。付款跑批的时候系统取的是主数据里的默认账号。所以营业执照齐不等于账号变更走过复核。采购建档、财务付款分人了若同一人既能改主数据又能放行付款等于没分权。三单匹配再严也核对不到「这个账号是不是还姓这个供应商」。上一集说过三单匹配防多付防不了假供应商。这一集就是把那句钩子摊开——假供应商这一刀砍的是主数据不是匹配规则。系统怎么管准入审批、账号双人复核、首付款加严系统要管住的不是再加一张单而是三道闸。准入审批、账号变更双人复核、首笔/变更后加严「首付款白名单」是管控建议不是产品功能名自绘*第一道准入审批。证照、税号、合同齐全才准入开户名、对公账号、开户行一次录清楚维护人和付款放行人必须是两个人。第二道账号变更双人复核。新建、修改、设为默认账号都要第二个人批确认前冻结对该供应商的自动付款。据 Oracle 官方文档启用供应商档案内部变更审批并勾选银行账号后账号新建、修改、设为默认都须审批才生效待批期间不能再改银行账号。据 SAP 知识库对敏感字段双控的说明敏感字段被改后该供应商账户对付款运行冻结直到第二授权人确认或驳回。回拨核实必须用合同或主数据里已经有的电话不能用这封变更邮件新给的号码——这是内控常识不是某家软件的按钮。第三道首笔和变更后加严。新供应商第一笔、账号刚变更后的第一笔进人工清单不要当普通付款自动出。这里说的「首付款白名单」是我建议的一种管控设计账号在白名单里可以走快捷通道账号一变白名单就失效重新核验。它不是某一家 ERP 产品里的功能名别当成采购话术去对号入座。哪些企业先别急着堆 AI主数据还在 Excel 里维护、谁都能改的采购和财务共用一个管理员账号的变更邮件来了直接改、从不回拨的。这三样不补上再聪明的校验也是给漏斗上贴创可贴。AI 怎么拦账号异常提示不是自动拒付再看虚构示例的另一种走法。同样一封变更邮件系统要求提交「银行账号变更请求」并上传变更函状态「待审批」默认账号还没生效。小核做校验账号是否有效、账户所有人是否等于供应商法定名称。结果 Failed——个人卡户名对不上公司名。提示「账户所有人与供应商名称不一致已挂起待人工复核。」老周用合同里的旧手机号回拨正牌供应商说「我们没改账号」。他点驳回权限日志留下申请人、审批人、校验结果、时间戳。即便以后真要改账号也得双人确认才写进主数据变更后第一笔付款仍强制人工。四格漫画变更待批 → 户名不符挂起 → 旧电话回拨后驳回 → 挂起不等于拒付变更后首笔仍加严据 Oracle 官方说明其银行账号校验服务会查「账号是否存在且有效」「账户所有人是否与供应商一致」状态分 Verified、Failed、Inconclusive文档同时写明校验状态仅供审批参考不自动阻止向该账号付款。而且该能力目前以美国账户为主中国企业不能照搬成「接上就自动拦」。所以 AI / 第三方校验适合落在这些点上账号无效、户名不符、校验说不清、账号变更后的首笔。它给的是提示和挂起不是替你拒付。挂起不等于拒付——先停一下人看完再决定。FBI / IC3 的一贯建议也是这个方向支付与采购请求尽量当面或电话核实账号或付款流程变更要和请求人核实且不要用邮件里新给的联系方式。我刻意不写「某国产厂商已经用证照 OCR 自动比对银行账号」这类话——我没在公开产品文档里核到对应能力写了就是编。金蝶手册能确认的是供应商主数据里有银行字段不能据此写成金蝶已内置账号变更双控。用友的具体设置我也没找到可核的官方帮助不写。异常来了拦截清单、人工复核、权限与留痕拦截点 → 挂起 → 人工复核 → 留痕后放行或驳回并与上一集三单匹配对照自绘异常来了按这个顺序走就够用拦截点亮了账号校验失败或 inconclusive、户名不符、变更后首笔——挂起付款或新账号暂不生效。人工复核用旧电话回拨打开变更留痕对照合同和变更函。说不清的驳回维持旧账号。权限与留痕谁申请、谁审批、校验给了什么结果、几点几分全部留下。批准才写主数据写完变更后首笔仍走人审。再出账人点了放行钱才能走。系统挂起从来不是「这辈子不付」是「先别自动付」。适合认真上这套管控的企业供应商多、付款频、已经在上三单匹配、但主数据变更还靠人情的中型企业。不适合现在就幻想「AI 一接上就永不出事」的企业主数据权限还没收口的审计日志都查不到谁改过账号的老板觉得「回拨太麻烦」的——那是流程问题不是模型问题。上一集拦多付这一集拦付错人。两道闸都要。下一集老周要碰的大概是挂起之后谁有权解冻解冻会不会变成另一道人情口子。