Visa 联手 BILL、Billtrust 试水 AI 代理付发票：企业应付流程首次接入 Agent

Visa 与 BILL、Billtrust 三方启动了一项面向 B2B 发票支付的 AI 代理试点：由 AI 代理读取发票、发起付款，经 Visa 的商用支付通道完成结算，BILL 提供应付自动化与付款执行能力，Billtrust 侧承接发票与应收账款环节的数据。据 Fintech News SG 报道，这是三方在真实企业应付（accounts payable）流程中验证代理发起支付的一步，而非实验室演示。

把这件事放回 Agent 支付的演进线上看，它的分量不在“又一个试点”，而在场景选择。过去一年围绕 x402、MCP 的讨论大多停留在 API 计费、小额机器对机器付款这类原生数字场景；B2B 发票支付则是另一套完全不同的约束条件——金额大、笔数少、有采购订单与合同背书、有账期、有审批链，付款失败或付错对象的代价远高于一次 API 调用。AI 代理要在这里拿到付款权限，等于要同时穿过财务内控和支付网络两道门。

第一道门是授权。企业应付的核心不是“能不能付”，而是“这笔该不该付、谁批的、额度多少”。代理发起付款时，授权意图（mandate）必须可被机器读取和校验：对应哪张发票、对应哪个采购订单、单笔额度与单日累计上限是多少、收款方是否在既有供应商白名单内。Visa 的商用支付通道本身带有对商户与交易类型的控制能力，BILL 的应付系统则掌握审批流与供应商主数据，两者叠加，理论上可以把传统上靠人工点击“批准”的动作，转成一套代理可执行、事后可审计的规则集。试点要验证的，正是这套规则在真实发票上是否足够严密。

第二道门是对账与不可抵赖。发票支付天然带凭证需求：付款之后要能回答“这笔钱对应哪张发票、由哪个代理在什么授权下发起”。代理参与后，归因链条多了一环——不是财务人员操作，而是一个自动化实体在既定规则内动作。这就要求付款记录与发票状态、审批记录能够对上，且在争议发生时可以还原决策路径。BILL 与 Billtrust 分别握有应付执行与发票/应收数据，三方打通的意义在于让这条链在系统间闭合，而不是靠人工在多个门户之间比对。

第三道门是供应商门户集成。B2B 付款的摩擦很大一部分不在支付网络，而在收款方：供应商可能要求走自己的门户、指定汇款信息、附带汇款通知（remittance advice）。代理若只完成“打款”而没把汇款信息送达，对账在对方一侧仍会断掉。Billtrust 所在的应收侧恰好是这一环的落点，这也是三方组合比单一支付方更有解释力的地方。

从合规与安全的角度看，这类试点把几个此前偏概念的问题推到了必须回答的位置。其一是 KYA——了解你的 Agent：企业需要能识别是哪个代理、在哪个授权范围内、代表哪个实体发起付款，并在代理行为异常时及时切断。其二是结算前拦截：在资金离开企业账户之前，对收款方做制裁名单与账户污点筛查，而不是事后追查。其三是额度与频次的硬约束：单笔额度、单日累计、收款白名单这些参数，必须由企业侧策略下发，而不是由代理自行判断。这三项在卡片与 ACH 通道上并非全新，但当发起方从人变成代理，校验的时点、粒度与留痕要求都会变。

对相关方的含义也不一样。对发卡与支付网络，这是把商用卡从“人持有、人使用”扩展到“企业授权、代理使用”的通道设计问题；对应付自动化服务商，竞争点从工作流效率转向谁能提供可审计的代理授权层；对企业财务，真正的门槛不是接不接代理，而是内控框架能否把代理纳入现有的职责分离与审批矩阵。试点阶段能验证的只是流程跑通，规模化取决于这些控制能否标准化——这也是围绕代理支付授权与凭证的标准讨论（如 RAP 一类倡议）正在试图填补的空白。

值得留意的是时点与节奏：三方尚未披露参与试点的企业数量、覆盖的发票规模或商业化时间表，据该报道仅确认试点启动。在数字缺位的情况下，更稳妥的判断是把它看作一次结构性验证——Agent 支付第一次被放进有账期、有审批、有供应商主数据的企业应付流程里跑，而不是又一次小额转账演示。跑通之后，剩下的问题会从“能不能付”变成“出了错谁负责、凭证够不够硬”。

---

原文来源：Fintech News SG · https://fintechnews.sg/139329/payments/visa-ai-agents-b2b-invoice-payments-pilot/