Human approval for AI-prepared payments: a practical setup

When an AI agent prepares payments, set it up so that the agent never releases money, a named person approves each payment or batch, nobody who can change vendor bank details can also release payments, and every step is written to a log. Approval rights then scale with the amount and the risk, not with how convenient it is for the agent.

That is the whole design. The rest of this note covers the parts that go wrong in practice: what the approver actually sees, how to set thresholds, and what the audit trail must hold. It builds on why our agents never move money on their own.

Who should approve a payment an AI agent has prepared?

The person who owns the budget or the relationship behind the invoice, not whoever happens to be nearest the banking screen. Accounts payable guidance from Corpay makes the same split for human teams: approval belongs to the budget owner, and the person who builds a payment batch is not the person who reviews and releases it.

With an agent, the agent is the one who builds the batch. So the agent takes the "maker" role and a person takes the "checker" role. The agent never holds the right to release, and where several agents work together, one agent does not sign off another's work in place of a person.

What should the agent prepare before the approver sees it?

An approval is only as good as the pack in front of the approver. A bare list of amounts invites a click-through. For each payment, the agent should assemble:

1. The invoice itself, linked, not summarised.
2. The contract, order or purchase request it was matched to, and whether the amounts agree.
3. The payee name and account details, and whether they are new or changed since the last payment.
4. Anything unusual: a first-time vendor, a duplicate amount, a due date that moved, a mismatch with the contract.
5. A clear recommendation: pay, hold or query, with the reason.

Corpay's advice for human releasers applies here too: look at payee, amount and any change since approval, rather than clicking through a summary screen. The agent's job is to make that check fast. The approver's job is to actually do it.

How do approval thresholds work?

Thresholds decide how many people look at a payment and how senior they are. The amounts are yours to set, because they depend on your cash position and your risk appetite. The structure is what matters:

Tier	Typical trigger	Who approves
Routine	Known vendor, matches contract, small amount	One named approver
Raised	Larger amount, or any change in bank details	Two people, one of them senior
Exceptional	First payment to a new vendor, cross-border or off-contract payments	Two people, plus a call-back to the vendor on a number you already hold

Corpay lists mandatory dual approval above a dollar threshold among the compensating controls for small teams, alongside owner review of the payment register and independent bank reconciliation. Small organisations rarely have enough people for full separation, so the practical aim is that no single person can both change who gets paid and release the money.

Why keep the agent away from vendor details?

Because a fake request to change a payee's bank details is a classic route into a fraudulent payment, and the losses are large. According to Nacha's summary of the FBI's 2024 Internet Crime Report, business email compromise was only the seventh most reported crime, with 21,442 complaints, but second by dollar losses, at close to $2.8 billion.

An agent that reads email will read the fraudulent "we have changed our bank" message too. So the agent may flag a change, and should flag it loudly, but it should not apply the change. A person confirms it through a channel the email did not come from, and only then does the vendor record change. The person who maintains vendor records is not the person who releases payments.

Does the bank's payee check replace the approval?

No. In the euro area, payment providers have had to offer a payee verification service since 9 October 2025. According to the European Central Bank, it applies to standard and instant credit transfers, and the payer gets a result of "match", "close match", "no match" or "other" before the payment is initiated.

It is a useful last check on the name against the account. It cannot tell you whether the invoice is genuine, the amount is right or the work was done. Treat a "close match" or "no match" as a hold that goes back to the approver, never as something the agent clears itself.

What belongs in the audit trail?

Enough that a year later someone who was not there can see what happened and why. For each payment, record:

• What the agent prepared, and the documents it used.
• Who approved it, when, and in which tier.
• Anything the approver changed or rejected, and why.
• Any change to vendor details, who confirmed it and how.
• The cost of the agent's work, against its fixed budget.

Rejections are the most valuable entries. They show where the agent needs better instructions or a narrower scope.

Where to start

Pick one payment run with a clear owner. Write down what the agent may prepare, who approves at each tier and who alone may change vendor details. Run it with approvals on every item for a few cycles and read the rejections before changing anything.

The back office of our own group of companies runs on the same principle: agents line up the payments and a person approves them, as described in the back office case. It is the kind of work we do under agentic implementation. If you have a payment process in mind, get in touch and we will look at it with you.