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/