Software has been able to send payouts for years. What is new is software that decides when to send them.
Picture a quarter-end close a year from now. An AI agent reads your partner program data, works out who earned a SPIFF, builds the payout file, and pushes it through before anyone on the finance team has finished their coffee. That future moved closer last week. The question for payout teams is not whether agents will touch payments. It is whether your controls are ready for the moment something other than a person presses send.
Our view is simple: the controls that protect you from a rushed employee or a fraudulent email are the same ones that make AI agents safe to use. Limits, a second approver, separate roles, and a clear record of who did what. If those are in place, an agent is a faster pair of hands. If they are not, it is a faster way to make the same mistakes.
On October 20, 2026, Visa, BILL and Billtrust announced a live pilot in which authorized AI agents complete buyer invoice payments through supplier portals. The companies describe it as the first live pilot of its kind. The agent is recognized and authenticated before it is allowed in, it uses tokenized payment credentials, and it works only on invoices the buyer has already approved.
That last detail is the important one. In this pilot, the agent does the repetitive part (logging in, entering details, completing the payment) while the decision to pay stays where it was. It is a useful model for anyone thinking about agents in their own payout process.
Agentic payments are payments that an AI agent initiates, executes, or reconciles on behalf of a business, within rules that business sets. Forrester describes B2B agentic payments as programmable, policy-governed flows in which agents act for a business across that lifecycle, and argues B2B may see value sooner than consumer shopping because business payments already run on defined workflows and approval rules.
That is a fair point, and it cuts both ways. A business payout process with clear approval rules is ready for an agent. One that runs on spreadsheets, shared logins, and "just send it" messages is not, and an agent will expose that quickly.
Paying one approved supplier invoice is a narrow task. Payouts are broader. A single run can reach hundreds of partners, contractors, or reward recipients, in different countries and currencies, many of whom you have paid only once or twice. Three things make that riskier for automation:
None of these require new technology. Most are the same controls auditors already expect. What changes is that they now have to work without a person catching problems along the way.
Write it down. A reasonable starting point is that an agent may prepare payout files, match them to program data, and submit them for approval, but may not approve them, add new payees, or change any payee's details. Expand the scope only after the agent has a track record.
Caps on single payment size, total value per run, and number of payments per period are blunt, and that is their strength. They do not depend on the agent understanding anything. If something goes wrong, the damage stops at the limit.
The maker-checker process was built for exactly this: one party prepares a payment and a different party approves it. When the maker is an agent, the checker should be a person, at least for new payees, unusual amounts, and anything outside the normal pattern.
An instruction says "pay this person this amount." Details say "this is their bank account." Keep them apart. When recipients maintain their own payee record behind their own login, neither an agent nor a convincing email can redirect the money.
An agent should not run on someone's personal login. Give it a dedicated user with the narrowest role that does the job, so its actions are separated from people's in every log and its access can be switched off in one place.
For every payment, you should be able to see who prepared it, who approved it, what changed, and when. That record is what lets you answer an auditor, a partner asking where their money is, or your own team asking what the agent actually did.
| Task | Reasonable for an Agent | Keep With a Person |
|---|---|---|
| Calculating earned incentives | Yes, from program data | Rule changes and disputes |
| Building the payout file | Yes | Review of exceptions |
| Approving the payout | Only small, routine runs within limits | New payees, large or unusual amounts |
| Adding a new payee | Sending the invitation | Confirming who they are |
| Changing bank details | Never | The recipient, through their own login |
Speed makes one gap easy to miss. If an agent can add and pay recipients quickly, it can also pay people whose tax information was never collected. The safer rule is that nobody gets paid until their onboarding is complete. On Xtrm, payees provide W-9 and W-8BEN(-E) equivalent information when they onboard, so it is gathered up front rather than chased at year-end.
You do not need a new framework to govern this, but it helps to borrow one. The NIST AI Risk Management Framework is a voluntary guide for organizations that use AI systems, and its basic idea fits payouts well: decide who is accountable, understand where the risks are, measure how the system behaves, and manage what you find. In practice, that means one program, one agent, tight limits, and a person reviewing every run until the results are boring.
We do not sell an AI agent. What we provide is the layer an agent, a script, or a person works through, with controls that apply to all three.
Our guide to payout controls goes deeper on how these checks fit together.
They are payments that an AI agent initiates, executes, or reconciles on behalf of a business, within rules the business sets. Early examples focus on routine, already-approved payments, such as invoices, rather than on agents deciding what to pay.
No. The point of dual approval is that the person or system preparing a payment is not the one approving it. If an agent prepares a payout, a person should approve it, at least for new payees and anything large or unusual.
Traditional automation follows fixed rules you wrote, such as paying a SPIFF when a deal closes. An agent can interpret data and decide what to do next, which is more flexible and less predictable. That is why limits and approvals matter more, not less.
Make sure no automated process can change a recipient's bank details. Then set hard limits on amounts and keep a person as the approver. Those three steps cover the most common ways a payout goes wrong.
AI agents will take over more of the repetitive work in payouts, and that is a good thing for teams buried in files and follow-ups. The teams that benefit will be the ones whose controls were already solid: clear limits, a person who approves, recipients who own their details, and a record of every step. Get those right first, and the agent is just a faster way to run a process you already trust.
If you want to see how approval policies and limits would work in your payout process, we are glad to walk through it with you.
Last updated: October 26, 2026