Agentic payments reconciliation. Proving what an agent actually paid.

The short answer

Reconciling an agent’s payments means proving three things for each one: that the agent was allowed to make it, that it was made exactly once as approved, and that the money actually moved. Ordinary payment reconciliation already covers the last point by matching your records with the provider’s status, its settlement file and your bank statement. Agent payments add two records to the match: the authority the agent acted under, and the intent it submitted.

The matching itself should stay deterministic. The same evidence under the same rules gives the same answer, every time. AI is useful for investigating and explaining the payments that don’t match, not for deciding that they do.

What changes when an agent is the one paying

• Volume and speed. An agent can prepare in minutes what a team prepares in a week, so breaks pile up faster if nobody is matching as payments land.
• Retries. Agents retry tool calls when something times out. Without an idempotency key per intent, a retry becomes a second payment.
• Authority is evidence. For a person, authority is their role. For an agent, it is a mandate with a version, and the payment has to be matched to the version in force when it was made.
• Several rails at once. One agent may pay by bank transfer, instant payment and card in the same hour, each with its own references and timing.
• Proposals that never execute. Refused and expired intents need to be recorded too, or you can’t show that the controls worked.

The records that must agree

For a payment an agent starts, reconciliation compares five records. The first two are yours; the last three come from organisations outside your control.

How agent payments are matched

Match on keys that survive every hop, not on descriptions an agent wrote:

• The intent’s idempotency key, sent to the provider with the payment, ties the provider’s record to exactly one intent.
• The mandate identifier and version tie the intent to the authority in force when it was made.
• The provider’s reference ties the status to the settlement file.
• Amount, currency, payee and value date, within agreed tolerances, tie the settlement to the bank line.

Every tolerance used (a fee rounding, a timing window around a cut-off) is logged against the payment, so any match can be explained by the rule that produced it.

The exceptions only agents create

Agent payments produce the usual breaks (a missing settlement line, a fee mismatch, a reversal after success) and a few of their own. Each one should be a typed exception with an owner, not a note in a spreadsheet.

Deterministic matching, AI for the exceptions

It is tempting to let a model reconcile what another model paid. Auditors will not accept it, and they are right: a match has to be reproducible from the evidence and a versioned rule. Use deterministic rules for matching and closure. Use AI to read the evidence around an exception, correlate it across sources and draft an explanation for a person to accept or reject.

In Flominzo, the Recon Agent does exactly that. It never closes an exception, accepts a settlement or writes off a difference on its own, and every action it takes is recorded with the agent as the actor.

A worked example: forty supplier invoices

Say an accounts-payable agent proposes forty supplier payments on a Friday under a mandate that allows approved invoices from allow-listed suppliers, up to £5,000 each and £60,000 a day. Thirty-eight are approved and sent. One is refused because the supplier’s bank details changed on Thursday and are still in their waiting period. One times out at the provider.

On Monday the provider’s settlement file lists thirty-seven payments. The bank statement shows thirty-seven debits and one fee line. Reconciliation matches thirty-seven payments end to end. The timed-out intent is resolved by a status lookup with its key: the provider accepted it and it appears in Tuesday’s file, so it closes a day later. The refused intent is recorded as refused, with the rule that refused it, which is exactly the evidence a risk team will ask for. Nothing was sent twice, and nothing was assumed paid.

How Flominzo applies this

Flominzo AgentPay records the mandate and the intent; the deterministic payment core enforces the mandate; Flominzo Recon matches each payment against the provider’s records, the settlement file and the bank statement, and raises a typed exception, with an owner, for every break. That is what we mean by 100% reconciliation: every payment is matched or explained, with evidence: it ends either matched against independent evidence - the provider’s records, the settlement file and the bank statement - or as an open exception with an owner and a reason. None is silently assumed paid.

Recon also works on payments you make outside Flominzo, so it can start read-only alongside the systems you already run.

Setting up reconciliation before the first agent payment

1. Carry the keys end to end. Make sure the intent’s idempotency key reaches the provider and comes back in its status and, where possible, its settlement file. If the provider drops it, map its own reference to the key the moment it is returned.
2. Record the mandate version on every intent. A payment is judged against the authority in force when it was made, not the one in force today.
3. Declare expectations per rail. For each rail the agent may use, say which evidence should arrive, from which source and by when. A missing file then raises an exception instead of silence.
4. Agree tolerances and owners. Decide the fee and FX rounding you accept, the timing windows around cut-offs, and who owns each exception type, before the first payment, not after the first break.
5. Close every day. A daily close with open items listed by owner and age keeps agent speed from turning into a backlog.

What to report to finance and risk

A single match rate hides the things that matter. For agent payments, report:

• Payments by mandate: how many, how much, and how close each mandate came to its caps.
• Refused and expired intents: how often the controls said no, and why. A mandate that never refuses anything may be too wide.
• Open exceptions by type, owner and age, with agent-specific types shown separately.
• Unknown outcomes: how many, and how long each took to resolve by lookup or evidence.
• Payments closed against cash: the share proven by a bank statement line, not just a provider status.

These numbers answer the question a risk committee actually asks: is the agent staying inside its authority, and would we know if it didn’t?

Common mistakes

• Trusting the agent’s own summary. An agent reporting "all 40 paid" is a claim, not evidence. Only the provider’s records and the bank statement settle it.
• Matching on descriptions. Free-text references that an agent wrote drift across hops. Match on keys and amounts.
• Reconciling weekly. At agent speed a week of breaks is a backlog. Match as evidence lands and close daily.
• Forgetting the mandate version. A payment that was within limits on Friday can look like a breach against Monday’s mandate.
• Letting the reconciling agent close items. It can explain; a person or an agreed rule closes.

Questions

Related