Why Accounts Payable Is Where AI Agents Are Starting to Pay: What Finance Leaders Should Check Before an Agent Releases a Payment
When an AI agent can release a payment, the question changes. It is no longer whether the agent can read an invoice, but whether it should be allowed to move money, within what limits, with whose approval and with what record. Finance leaders who start with the technology tend to discover the answers late. Those who start with the controls find the technology easier to judge.
Recent reporting points to accounts payable as one of the places agent payments are beginning to appear. That makes the control questions practical rather than hypothetical. This guide sets out what has been reported, how much weight it can bear, and the six checks we would want satisfied before an agent releases a payment on your behalf.
What has been reported, and how much weight it carries
The evidence is recent, US-led and limited. It is worth stating in plain terms.
Visa, BILL and Billtrust were reported in October 2026 to be running a live pilot of AI agents paying business-to-business invoices through Visa Intelligent Commerce. The reporting describes this as among the first production-style agent payments, and we want to be clear that the "first" is Visa's own claim. We have not verified it and we are not asserting it.
Mastercard announced Early Access to Agent Pay for Machines, with buyer-side and seller-side APIs and a sandbox. The product is aimed at machine-to-machine payments, with agents paying for services, rather than only consumer shopping. Early access in a sandbox is a step toward production, not production itself.
Finance operations more broadly appears in the same coverage as a place where large organisations deploy agents early. Nestlé's use of SAP agents is one reported example, and the reporting names collections, accounts payable and banking operations as early homes for agents. Separately, Ramp has shipped a card designed for AI agents, which suggests that vendors are building the spending controls that agent payments will need.
Taken together, this is a consistent direction, not a body of proof. It rests on a small number of announcements and one pilot, mostly from US companies. None of it tells us how reliably agents pay invoices, how often they err, or how UK finance teams, banks and suppliers will experience them. Anything we say beyond that is analysis, and we will label it as such.
Why accounts payable rather than open-web checkout
If agent payments are going to start somewhere, accounts payable is a logical candidate. This is our interpretation, but it fits the reporting.
An agent buying on the open web acts among strangers. It must decide which seller to trust, whether a price is fair and whether a checkout is legitimate, often with no pre-existing relationship and little record. Accounts payable is a different environment. The suppliers are known. The invoices relate to purchase orders, contracts or goods received. Approval routes already exist. There is a record of who authorised what, and an audit function that expects one.
In other words, many of the controls that make delegated payments risky to authorise elsewhere already exist in accounts payable. The reporting reflects this, noting that where approvals, supplier relationships and audit trails exist, delegated payments are easier to authorise and insure than open-web consumer purchases. That is a helpful observation, but it is also a warning. If an agent is introduced into an accounts-payable process whose controls are weak, the agent will inherit the weakness and operate at greater speed.
For teams thinking about where agentic payments fit in their wider payments architecture, this is the angle that matters. The reason accounts payable works as an entry point is not that agents are good at it. It is that the surrounding controls make it testable. The same logic runs through our agentic payments work, where authorisation and accountability come before capability.
The principle: delegated authority must be bounded, visible and reversible
Every payment an agent releases is a delegated payment. Someone with authority has handed a decision to software. Three properties should hold whatever the technology.
The authority must be bounded. The agent can do specific things, up to specific limits, for specific suppliers, and nothing else.
The authority must be visible. At any moment, someone can see what the agent has done, what it is about to do and why.
The authority must be reversible. If something goes wrong, there is a way to stop the agent and, where possible, to recover.
Each of the six checks below is a way of testing one or more of these properties.
Six checks before an agent releases a payment
These are Innovify's analysis of what a finance leader would sensibly want in place. They are not drawn from any standard or from the reporting above, and they are not exhaustive.
1. Authority limits
Define what the agent may pay, to whom and up to what amount. The questions to ask are specific. Is there a per-payment limit, and a cumulative limit over a period? Are limits different by supplier, category or payment type? What happens when a payment would exceed a limit: does the agent stop, or does it find a way around it by splitting the payment? A limit that can be circumvented by the agent's own behaviour is not a limit.
2. Approval routing
Decide which payments the agent can release alone, which need a person and which need more than one. Approval routing should be set by risk, not convenience. Check that the routing is enforced by the system rather than by the agent's own judgement, that approvers see enough information to make a real decision and that an approval cannot be given on behalf of someone else. A human approval that amounts to clicking through a queue is a control in name only.
3. Supplier verification
Payments go wrong most expensively when they go to the wrong place. Establish how the agent confirms that a supplier is on the approved list, that bank details match what is held and that any change to those details is verified through a separate route before it takes effect. A request to change bank details is a classic point of attack in payables, and an agent that treats it as routine data entry is a risk. Decide in advance that such changes always escalate to a person.
4. Matching and duplicate prevention
Confirm what the agent matches an invoice against: a purchase order, a contract, a goods receipt. Define what counts as a sufficient match, what happens on a partial match and how duplicates are detected, including near-duplicates where an invoice is resubmitted with a small change. Agents work fast, so a duplicate that a person might catch by recognition has to be caught by design.
5. Audit trail
For every payment, a reviewer should be able to reconstruct what the agent saw, what it decided, which rule or limit applied, who approved it where approval was required and when the payment was released. Check that the record is held outside the agent, cannot be altered by it and is complete enough for an auditor who was not involved. If you could not explain a payment to an auditor from the record alone, the agent is not ready to release it.
6. Stop and recovery
Decide how the agent is paused, who can pause it and how quickly. Define what happens to payments in flight, how an erroneous payment is recalled or recovered and who is notified. This is the reversibility check, and it is the one most often left until after something has gone wrong. It should be tested, not just documented.
What the evidence does not tell you
A controls-first article invites a temptation to treat the checklist as settled. Four limits are worth keeping in view.
First, the performance evidence is absent. The reporting describes pilots and early access, not results. We have no figures on accuracy, error rates, savings or time saved, and we are not offering any. If a vendor offers them, ask how they were measured, on what data and by whom.
Second, the reporting is US-led. The examples above, from Visa, BILL, Billtrust, Mastercard and Ramp to Nestlé's use of SAP agents, come from US-led coverage. We have no UK-specific evidence on how agent payments in accounts payable work with UK banks, UK payment rails or UK supplier practice, and we would treat any confident claim about that as unsupported. The FCA has said that it is applying existing frameworks, including senior-manager accountability, to AI in financial services, but that statement is about AI generally and is not specific to accounts payable. UK finance teams should take their own advice on how accountability applies.
Third, the companies named are third parties. Nothing here implies that any of them has an arrangement with Innovify, or endorses this article.
Fourth, "first" remains a claim. It is Visa's, and it has not been tested by an independent source in the evidence we hold.
Start with a scoped proof of concept
Given those limits, the sensible way to begin is small and measured. A scoped proof of concept lets you test the six checks against your own invoices, suppliers and approval rules before you commit to anything larger. It should have a defined scope, a baseline, real users and a rule agreed in advance for deciding whether to stop, extend or scale.
We cover that process in a companion guide to running an agentic accounts-payable proof of concept: what to test, what to measure and when to stop. The two pieces are meant to be read together. This one asks what must be true before an agent releases a payment. The companion asks how to find out whether it is, in your own environment, and how to decide what to do next.
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance, and we design compliance in from day one. We are not suggesting that any particular agent or vendor is ready for your payables process. We help teams work out whether their controls are ready for one.
Our Agentic Commerce & Payments work covers how agent-initiated payments are authorised, limited, monitored and evidenced, from the delegation design to the audit trail. Let's build your next AI or financial product with the controls in the specification from the first day.
FAQ
Why are AI agents starting with accounts payable?
Accounts payable already has known suppliers, invoices that can be matched to something, approval routes and an audit trail, so delegated payments are easier to authorise and measure than in open-web checkout. Reporting in October 2026 includes a live Visa, BILL and Billtrust pilot of agents paying business-to-business invoices. The evidence is limited and mostly US-led.
Is an AI agent paying invoices already in production?
Reporting describes a live pilot in which Visa, BILL and Billtrust run AI agents paying business-to-business invoices, which the reporting frames as among the first production-style agent payments. That "first" is Visa's own claim and we have not verified it. Mastercard's Agent Pay for Machines is in early access with a sandbox, which is earlier still.
What should finance leaders check before an agent releases a payment?
Check six things: authority limits, approval routing, supplier verification, invoice matching and duplicate prevention, the audit trail, and the ability to stop the agent and recover a payment. Together they test whether the agent's authority is bounded, visible and reversible. These are Innovify's analysis, not a regulatory or industry standard.
Can an AI agent change a supplier's bank details?
It should not do so without verification through a separate route. Changes to bank details are a well-known point of attack in payables, so we would set the rule that any such change escalates to a person and is confirmed independently before it takes effect. An agent that treats a change as routine data entry adds risk.
How should a finance team start with autonomous accounts payable?
Start with a scoped proof of concept that tests the controls against your own invoices, suppliers and approval rules. Agree the stop, extend or scale rule before the test begins, put real users in the process and measure control failures before speed. Avoid relying on vendor claims about savings or accuracy until you have your own evidence.
Conclusion
Accounts payable may well be where AI agents pay first, and the reporting suggests that is the direction, but the claim is Visa's and the evidence is thin. What finance leaders can control is whether an agent's authority is bounded, visible and reversible before it moves money. Check the six controls, be clear about what the evidence does not show and test in a scoped proof of concept before scaling anything.
