Can an AI Agent Pay a Supplier Invoice Through a Portal?
Yes, under conditions. An agent can pay a supplier invoice through a portal when a person approved the invoice first, the agent carries a credential that works for that payment only, and the portal knows which agent it is talking to.
Yes, under conditions. An agent can pay a supplier invoice through a portal when a person approved the invoice first, the agent carries a credential that works for that payment only, and the portal knows which agent it is talking to. What nobody has published is when the agent must stop. That is the gap this post fills.
What Visa, BILL and Billtrust launched
Visa, BILL and Billtrust announced a live pilot in which BILL’s payment agent pays approved supplier invoices by card through Billtrust portals, with no person typing in the portal. The flow has four steps.
- The buyer approves the invoice in BILL, as before.
- BILL’s agent, registered in Visa’s Agentic Directory under the Trusted Agent Protocol, pays with a tokenized card credential tied to that approved instruction.
- Billtrust recognizes the agent through the same protocol and lets it in without a login. Visa says this takes the place of CAPTCHA and other bot blockers.
- The supplier receives the payment under its own acceptance policy, with the remittance detail it needs to reconcile.
Visa’s FAQ puts it plainly. The agent makes no payment decisions. It carries out eligible payments the buyer already approved. The pilot is live with participating buyers and suppliers. The release gives no volume, no count of participants, and covers card payments only.
The three tests, applied
Last week, in Agents Can Look. Who Lets Them Pay?, I argued that an agent needs three things before it moves money: a limit, a narrow credential, and a named person who answers for it. The pilot, as described, meets all three. The release is thin on how.
| Test | What the pilot does | What the release leaves out |
|---|---|---|
| A limit | Payment controls tied to the buyer’s approved instruction, and a payment path tied to one invoice | What the controls check. Amount only, or also a date window and a retry count? |
| A narrow credential | A tokenized card credential for the payment, not a shared portal login. Visa’s FAQ says buyers no longer need to share logins | How long the token lives and whether it can be used twice |
| A named person | The buyer who approved the invoice in BILL | How that approval travels with the payment, and who on the supplier side can see it |
The design is the one the card networks built for consumers, moved into B2B. The yes happens before the payment, not at it. The agent’s job is to carry an approval to the portal and come back with proof it landed. That is the right split. It also means every risk that matters sits in the gap between the approval and the portal.
What the release does not say
The release treats approval as settled. Its FAQ says B2B payments already run inside established approvals, controls and the buyer’s rules. That is true of the first approval. It says nothing about what changes between the approval and the payment, which is where duplicate payments and payment fraud live.
Four things can change in that gap. The release does not mention any of them.
- The supplier’s remit-to details changed after the approval.
- The invoice in the portal is a duplicate, or was already paid another way.
- The invoice in the portal does not match the approved one in number, amount or due date.
- The approval has expired, the approver has left, or the policy changed since the yes.
None of these is a flaw in the pilot. They are the cases a second version has to handle, and the cases an AP team has to settle before it lets an agent near a portal. A person at the portal catches some of them by habit. An agent catches only what someone wrote down.
Where each check lives
The rule is simple. The agent pays when the invoice at the portal matches the approval it carries. Any difference is a stop, and a stop means the agent reports and waits. It never resolves the difference itself.
| Stop point | Who sees it first | Where the check belongs | What the agent does |
|---|---|---|---|
| Remit-to or bank details changed | The portal shows a new account, or the supplier’s agent does | The buyer’s AP system, before any approval is reissued. For card payments, the bank account never enters the flow, so the question becomes whether this is the right portal and the right merchant | Stops. Reports the change to AP with the old and new details. Does not pay to the new details |
| Duplicate invoice | The portal lists an invoice number already paid, or a match on supplier, amount and date | The buyer’s AP system, against its own payment history, including payments made by check or ACH outside the agent | Stops. Does not pay twice because the portal still shows a balance |
| Portal invoice does not match the approval | The agent, at the moment of payment | The agent, which holds both the approval and the portal record | Stops on any difference in number, amount, currency or due date. Pays the approved amount only if the policy says so, and says that it did |
| Approval expired, approver gone, policy changed | The buyer’s AP system | The buyer’s AP system, which sets an expiry on every approval and revokes the ones it cannot stand behind | Stops. Asks for a fresh yes. Never pays on an old one |
Two of these four checks belong to the AP system, not the agent. That is the point. The agent is the last step, and the last step must be the dumbest one. It must carry one approval, pay one invoice, and refuse everything else.
One more question the release leaves open. The Trusted Agent Protocol lets the portal confirm who the agent is. The release does not say how the agent confirms it has reached the right portal for that supplier. Until it does, the list of approved portals belongs in the buyer’s AP system too.
The case that matters most
The hardest stop is the expired approval, because nothing looks wrong. The agent has a valid credential. The portal recognizes it. The invoice matches the approval to the cent. The only thing missing is that the yes is three weeks old, the person who gave it moved to another team, and the policy now requires a second signer above $25,000.
A person at the portal does not catch that either. The difference is that a person’s yes expires on its own, because the person leaves, forgets, or asks again. An agent’s yes lasts until someone revokes it. So every approval an agent carries needs a date on it, and the agent needs a rule to check the date before it pays.
The pilot answers the question in its title. An agent can pay a supplier invoice through a portal. The question for the AP team that turns it on is the other one. When the agent finds a reason to stop, will it?
Defined in the glossary: network token , agentic commerce , AP portal , e-invoicing mandate
Published .
Cite this
Couch, C. (2026). Can an AI Agent Pay a Supplier Invoice Through a Portal?. Ends at Cash. https://chriscouch.ai/essays/ai-agent-pay-supplier-invoice-through-portal/
BibTeX
@misc{couch2026cananaiagentpayasupplier,
author = {Couch, Chris},
title = {Can an AI Agent Pay a Supplier Invoice Through a Portal?},
year = {2026},
howpublished = {Ends at Cash},
url = {https://chriscouch.ai/essays/ai-agent-pay-supplier-invoice-through-portal/}
}
