Settlement Isn't Confirmation

Your payment provider sends a webhook: status: settled. Your system marks the transaction complete. Your customer sees their balance update. Everybody moves on.

Two weeks later, the funds reverse. Your ledger says the money arrived. Your bank account says it didn't. Your customer already spent it.

The gap between "settled" and "final" is where payment systems break.

What "settled" actually means

Settlement is an accounting event between banks. It means the originating bank and the receiving bank have agreed on a net position and moved funds between their reserve accounts at the Federal Reserve. For ACH, this happens through the Fed's settlement process. For card networks, it happens through Visa or Mastercard's clearing system.

What settlement does not mean: the transaction is irreversible.

An ACH debit can return for insufficient funds up to two business days after settlement. An unauthorized ACH debit can return up to 60 calendar days after settlement. A credit card chargeback can arrive 120 days after the original transaction. In each case, the money already settled. The banks already moved it. And then it came back.

The status problem

Payment APIs compress this reality into status fields. You see pending, settled, failed. Three states. Clean, simple, wrong.

The actual lifecycle looks more like this: a transaction is initiated, submitted to the network, accepted for processing, settled between banks, and then enters a window where it can still reverse. The length of that window depends on the payment method, the reason code, and sometimes the relationship between the banks involved.

If your data model treats settled as a terminal state, you have no place to put a reversal when it arrives. The transaction is "complete" in your system. A return creates an orphan event that doesn't map to any status transition you've defined.

Your System

Your Bank

ACH Network

Receiving Bank

The ledger consequence

This matters because your ledger is downstream of your status model. When a transaction settles, your system records it: credit the customer, debit the funding source, update the balance. Done.

When a return arrives and your status model has no transition for it, one of two things happens. Either the return fails to process and sits in an exception queue until someone manually investigates, or it processes but creates a balance discrepancy that your reconciliation catches days later.

Both outcomes are expensive. Manual investigation doesn't scale. Late reconciliation means your displayed balances were wrong for the entire gap between the return and its discovery.

The timing problem

Different payment methods have different return windows, and none of them are zero:

ACH: 2 business days for standard returns (wrong account, insufficient funds, account closed). 60 calendar days for unauthorized returns.

Card networks: 120 days for most chargebacks. Some dispute categories extend to 540 days.

Wire transfers: Generally final once settled. This is why wires cost more and require stronger authentication. Finality has a price.

RTP and FedNow: Irrevocable by design. No enforceable return mechanism. A receiving bank can voluntarily return funds if asked, but there's no right to claw them back. This is the closest thing to "settled means done," and it shifts the risk entirely to the sender.

The pattern: cheaper and more accessible payment methods have longer reversal windows. The convenience comes with uncertainty.

What your system needs

The fix is a status model that acknowledges the return window as a distinct state.

After settled, a transaction enters a settlement_pending_finality period. The length depends on the payment method. During this window, the transaction is settled but not final. Your ledger records the settlement, but your risk system knows the funds could still move.

When the window closes without a return, the transaction transitions to final. Only then is the money truly yours.

This means your displayed balances need to distinguish between settled funds and final funds. Your accounting system needs to handle reversals as first-class events, not exceptions. Your customer communication needs to reflect that settlement is a waypoint, not a destination.

The reconciliation anchor

The practical test: can your system answer the question "how much money do we actually have right now" at any moment?

If your system counts settled funds as available, the answer is wrong by the sum of all transactions still inside their return windows. For a payment processor handling volume, that number can be significant.

Reconciliation isn't a batch job you run at end of day. It's a continuous assertion about the state of your money. Every incoming webhook, every status change, every return event either confirms or challenges that assertion. If your system can't absorb a return at 2am on a Saturday without human intervention, your reconciliation has a gap.

Your system treats settlement as the finish line because the status field says settled. The return that arrives two weeks later doesn't care what your status field says.