付款批次提交银行前，AI能查出重复付款和收款账户异常吗？

付款文件已经生成，银行提交窗口只剩半小时。复核人却发现，同一供应商的两张发票金额、日期和采购单都很接近，而且收款账户是在三天前刚改过。此时最危险的动作不是多问一句，而是因为批次已经排好就直接放行。

这类门禁要同时回答两个问题：钱是不是付过或正在别处等待支付，账户变更是不是真的经过了独立确认。AI适合把分散证据对齐并标出冲突，但它不应拥有网银提交权，也不能替代双人复核。

先冻结批次范围

先保存待提交文件的版本、生成时间、付款主体和总金额。批次生成后新增的发票或账户变更另开清单，不要在复核途中悄悄混入。这样发现异常时，才能准确说明哪些行被暂停，哪些行仍可按原计划处理。

• 批次行号、供应商编号、发票号、币种和金额
• 采购单、收货或服务确认及未清项状态
• 供应商主数据当前账户与最近一次变更记录
• 制单人、复核人、批准人和银行提交人

重复不是只看发票号

供应商可能重开发票、补传扫描件，或在不同系统里使用不同编号。应先做完全匹配，再检查同供应商、同金额、相近日期、相同采购单或相同服务期间的近似组合。命中规则只表示需要核对，不等于已经证明重复。

把账户异常单独设门

账户变更不能靠邮件截图或联系人一句话放行。复核包应包含变更申请来源、供应商主数据修改日志、独立回拨或既定渠道确认、审批人以及生效日期。付款对象、币种或国家发生变化时，按高风险例外升级。

AI可以比较字段和发现缺件，却无法确认电话另一端是否为真实授权人。确认动作必须由不参与主数据修改的人完成，并把时间、渠道和结论写入记录。

先用少量资料把判断链跑通

不要一开始就把整个批次交给模型。挑一组正常项、一组明确异常和一组边界不清的样本，确认字段能对应、规则不会互相覆盖，再扩大范围。小样本的目标不是证明模型聪明，而是发现资料缺口和误判方向。 对本任务，首轮只验证能否可靠支持这一判断：哪些付款可以释放，哪些属于重复、账户异常或证据不足而必须暂缓。

角色：负责应付账款付款批次的财务人员。
触发：付款文件即将提交银行，但同一供应商存在多张相似发票和近期账户变更。
资料：付款批次、应付明细、发票与采购单、供应商主数据、银行账户变更审批。
判断：哪些付款可以释放，哪些属于重复、账户异常或证据不足而必须暂缓。
交付：付款放行清单、异常证据、复核人与批准记录。
要求：逐条列出证据、未知项、规则冲突和需要谁确认，不执行任何高风险写入。

扩大处理范围前先做反向抽查

除了核对被标红的项目，还要从模型判定正常的结果中随机抽查。只看异常会漏掉最危险的假阴性。抽查发现同类遗漏时，应回到规则和输入修正，并重跑整个受影响范围。 验收终点应是可以交接的付款放行清单、异常证据、复核人与批准记录。

出现这些情况就停止自动处理

• 关键文件缺少版本、时间范围或唯一编号，无法确认是否属于同一任务
• 多个资料来源给出冲突事实，且没有被授权的基准可以裁决
• 结果会触发付款、权限、合同、生产、薪酬或对外承诺等高风险动作
• 可能造成的后果是重复付款或将资金转入未经批准的账户，追款困难并形成内控缺口

停止自动处理不等于停止工作。保留已经完成的证据整理，标出阻塞位置、责任人和期望回复时间，让人工从明确节点接手并继续完成付款放行清单、异常证据、复核人与批准记录。

形成可签字的放行结果

Reconciliation负责核对付款批次与应付、发票和往来余额；Audit Support负责检查账户变更证据、审批链和审计例外。两项能力的输出要前后衔接，不能只把同一份材料重复总结。

两项 Skill 整理差异和审计证据，不执行银行付款；最终释放必须由具备付款权限的复核人与批准人完成。