Payments Now Settle in Seconds. Reconciliation Still Takes Three Days.

By Daniel Okafor

A payment can settle in seconds and still leave the books wrong three days later. That gap, argues the author of the piece, is the core operating problem facing finance teams as faster payment methods spread.

The numbers explain why the question is urgent. A 2025 Federal Reserve Financial Services survey summary reported that 92% of businesses now use some form of faster payments, including Same Day ACH and digital wallets. Yet the same summary found that businesses still name cost, security concerns and lack of timeliness as their leading payment challenges.

Speed, in other words, has arrived. Visibility has not.

What does faster settlement actually change?

The author frames the problem as two clocks. The payment clock measures how quickly money moves. The close clock measures how quickly the business can explain and reconcile that movement.

"A company has not meaningfully improved its payment operation if it shortens the payment clock while making the close clock harder to manage," the piece states.

The mechanism is straightforward. Money can move quickly while invoice data, approval history, remittance details and accounting records remain scattered across different systems. Faster settlement does not automatically create a faster finance operation. It moves the bottleneck downstream, from the payment desk to the reconciliation queue.

The Federal Reserve itself distinguishes clearing from settlement. Clearing involves payment information and related activities. Settlement is the debiting and crediting of accounts. They are connected, but they are not the same step.

The author saw this firsthand while running Tyler Petroleum. The company used different payment providers for different vendors, which created cost and time burdens. Every additional system created another place where payment information had to be tracked, matched and understood.

Why does the finance record lag the money?

A payment has two journeys: the movement of funds, and the movement of information through approval, accounting and reconciliation.

The question is not simply, "How quickly can we send this?" The author puts it differently: "What will finance need to know after we send it?"

Before changing a payment method or adding automation, the author recommends mapping the workflow from invoice approval through payment initiation, settlement, remittance delivery, accounting entry, reconciliation and exception resolution.

Then measure both clocks. If settlement falls from a day to a few seconds while an unmatched transaction still takes three days to resolve, the company has improved payment speed, not visibility.

Assign an owner to every stage, especially the exception stage. The author calls this one of the most important payment controls. If the answer to an unmatched payment is "accounts payable will find it later," the workflow is not ready.

How should a company choose a payment method?

Not every payment needs the same speed or the same data. A payroll correction late on Friday may justify a faster method. A routine invoice due next week may not.

The author proposes three questions before switching methods:

• Does this payment actually need speed? If not, faster settlement may add cost or process complexity without improving the outcome.
• What information must travel with the money? A payment without a usable invoice number, vendor identifier or remittance detail creates work for someone else.
• What happens when something goes wrong? Decide who handles a duplicate, changed instructions, a returned payment or an unmatched remittance before the first transaction is sent.

The right method fits the urgency, approval process, accounting workflow, cash forecast and exception plan.

What is the five-payment test?

Before scaling a new method, the author says, test five cases:

• A normal payment. Can the team trace it from approval to the accounting record?
• A duplicate attempt. Does the workflow catch the risk before two payments leave the business?
• Changed instructions. Is there a review step before new details are used?
• A failed or returned payment. Who receives the exception, and how quickly is the recipient informed?
• An unmatched remittance. Can finance identify the payment's purpose without searching across several systems?

If the team cannot explain all five cases, the process is not ready to scale. "Real finance work is defined by payment exceptions, not by the one payment that works as planned," the author writes.

Should reconciliation come before launch?

Yes, the author argues. Reconciliation should be designed before a payment project goes live, not after.

The prescription is concrete:

• Require one usable identifier to follow the transaction from approval through settlement and into the accounting system.
• Define a daily exception queue.
• Set a deadline for resolving unmatched items.
• Keep an audit trail connecting the original approval, the actual payment and any correction.

Nacha has noted that many payment back offices still rely on manual intervention for exception handling, returns and reconciliation. Automation can reduce repetitive work, but it does not remove the need for judgment.

"A system that can send a payment in seconds but cannot explain it is only partially controlled," the piece concludes.

Before approving a project, the author writes, ask whether the business can identify every payment's purpose, assign responsibility for unmatched transactions and distinguish timing differences from actual errors at close. If the answer is no, slow the rollout. Faster payments are useful. Faster confusion is not.