Round CEO Pac O’Shea on Invoice Approval and Payment Controls

The gap between invoice approval and payment is where control over money is most easily lost, according to Pac O’Shea, chief executive of Round. An approval confirms that a bill is legitimate. It does not confirm that the payment being prepared still matches it.

Round builds finance automation across treasury, accounts payable and payroll, and is listed in the Accountio directory alongside other financial close and reconciliation software. The risk O’Shea describes is a live one: finance teams are already seeing deepfake fraud aimed at payment staff.

Finance teams often treat invoice approval and payment as a single step, because one system can handle both. O’Shea argues they are two separate decisions. One accepts that the company owes the money. The other authorises it to leave the bank, and a change to the payee’s bank details is where the two can come apart.

Accountio put five questions to O’Shea on invoice approval and payment. They run from changed bank details to one control any finance team can add this month, including small teams where one person both edits supplier records and releases payments. Each answer below is in O’Shea’s own words.

Where does the handoff between invoice approval and payment usually break down?

The weak point is the connection between what someone approved and what the bank is being asked to pay. An invoice approval establishes that a bill is legitimate. It doesn’t automatically establish that the payment being prepared still has the same amount, currency and destination.

When those details move between an invoice system, a spreadsheet and a banking portal, the approval can become detached from the instruction. A green tick on the invoice tells the next person very little about subsequent changes.

I think the useful distinction is between approving an obligation and authorising money to move. The payment needs a clear link to the approved details, with a check before release. Otherwise the finance team has to reconstruct that link by hand.

What should happen when a payee’s bank details or the amount change after an invoice has been approved?

The payment should stop while the changed details are checked and authorised again. The original approval is a record of the original instruction; it shouldn’t silently extend to a different amount or destination.

For bank-detail changes, verify the request with the supplier through contact details already held on file. Calling a number supplied in the change request doesn’t establish an independent check. For an amount change, establish the reason and check the revised invoice or supporting agreement.

Then apply the approval rules to the new instruction, including any higher threshold the new amount crosses. Keep the earlier version and show the approver what changed. Check those same details at payment release, so a later edit can’t slip through between the fresh approval and execution.

Who should be allowed to approve that change, and how should it be recorded?

Someone with authority for the revised payment under the company’s written approval policy. That isn’t automatically the person who approved the original invoice, and it shouldn’t become whoever happens to be available before the payment run.

The person editing supplier details should be separate from the person authorising the resulting payment. In a small team, that needs an explicit second-person review, rather than a separation that exists only on paper. Higher amounts should follow the relevant escalation rule.

Record the old and new details, who requested the change, how it was verified, who approved it and when. The decision should refer to the specific revised instruction. A general message saying ‘fine to pay’ leaves the next person guessing which version was approved.

What does a complete audit trail look like, from approval through to payment?

It should let a person who wasn’t involved reconstruct the decision and its outcome. Start with the invoice and supporting documents, then link the approved version to the payment instruction. Keep the approver, time and applicable authority alongside it.

Every material change needs its own history: what changed, why, who made it, how it was checked and who authorised the new version. The release record should then show exactly which instruction was sent, by whom or by which automated process, and its payment reference.

Keep the outcome too, including failures, cancellations or returns. ‘Submitted’ isn’t the same as ‘paid’. Reconcile the payment against the bank record and invoice, and retain any later attempt without overwriting the earlier one. That makes the record useful when something goes wrong.

What is one control a finance team could put in place this month?

Make every supplier bank-detail change a payment hold until an independent check and second-person approval are recorded. Give that hold a named owner so it doesn’t become an unattended queue.

Use a supplier contact already on file to verify the change, and record who you spoke to, when and what was confirmed. Have someone other than the person making the edit approve the revised destination before the payment is released. An urgent email shouldn’t remove that requirement.

This month, write the rule down, assign the two roles and check that the payment process enforces it. Review recent changes against the same rule. You don’t need to redesign the whole finance function to close this gap, but the control has to work where money moves.

About Pac O’Shea

Pac O’Shea is CEO of RoundTreasury.com, building finance automation across treasury, accounts payable and payroll.

Round website · Pac on LinkedIn · Round on LinkedIn