The money that has moved and not moved
A customer pays for an order. Their banking app says the money has left. Your dashboard says the payment succeeded. And yet your bank balance is unchanged, and will be unchanged tomorrow morning too. Somebody in finance asks where the money is, and the honest answer is that it is in transit, in a place nobody in your company can see.
This is not a fault. It is how payments work. The confusion comes from treating "payment" as one event when it is at least three.
Authorisation, clearing, settlement
Take a card payment as the clearest example. The first step is authorisation. The merchant asks the customer's bank whether the card is valid and the funds are there. The bank says yes and places a hold. This takes seconds, and it is the only step the customer ever sees. Crucially, no money has moved. A promise has been made.
The second step is clearing. Records of the transactions are gathered, usually in batches, and exchanged between the institutions involved. Each party works out who owes what, to whom. Clearing is about information: agreeing on the facts of what happened, checking them, and calculating the obligations that result. Disputes, duplicates and mismatches are caught here.
The third step is settlement. Now value actually moves between the institutions, typically through accounts held at a central bank or at a settlement bank, and then onwards into your merchant account. Only at this point is the money yours to spend.
The same three ideas apply to bank transfers, direct debits and wallet payments. The names differ and the gaps between steps vary, but the shape does not: a promise, an agreement on the numbers, then the movement of value.
Why the gaps exist
It is tempting to assume the delay is laziness. Mostly it is design, and it exists for reasons that were once sensible.
- Batching is cheaper. Settling thousands of payments as a single net position is far less costly than settling each one individually.
- Netting reduces risk and liquidity needs. If bank A owes bank B a hundred and bank B owes bank A ninety, only ten needs to move.
- Cut off times follow working hours. Many settlement systems run on business days. A payment made on Friday evening may wait until Monday.
- Fraud and dispute windows need time. Holding funds briefly gives the system room to catch problems before value is irreversible.
Some systems have removed much of the gap. Instant payment schemes, such as Faster Payments in the UK or NIP in Nigeria, make the funds available to the recipient within seconds. Even then, the interbank settlement behind the scenes often happens in cycles. The customer sees immediacy because the receiving bank is willing to extend credit for a short while, on the strength of a guarantee that the settlement will follow. The delay has not vanished. It has been absorbed by someone who is prepared to carry the risk.
What it does to a business
For a company, the practical effect is a difference between what you think you have and what you can use.
Picture a retailer that takes a large volume of card payments over a weekend. Sales figures look excellent on Sunday night. But supplier invoices fall due on Monday, and the settlement for most of that weekend has not arrived. The company is profitable and short of cash at the same time.
This is why treasury teams talk about float, the money that exists in the system but is not yet in your hands. It also explains a few problems that otherwise look mysterious:
- Reconciliation that never quite matches, because your records show sales and your bank shows settlements, net of fees, on different dates.
- Refunds that leave your account before the original sale has arrived.
- Chargebacks that land weeks after the sale, against revenue you have already spent.
- Cross border payments that take days because several intermediaries each clear and settle in turn.
None of these is a bug. Each is the visible edge of a process you do not control.
What to do about it
You cannot compress a settlement cycle you do not own. You can stop being surprised by it.
Keep two numbers, not one. Track what has been sold or paid, and separately what has been settled and is available. A cash position built only from the first number is a forecast, not a balance. Make the difference visible, by provider and by currency, so that the people deciding what to pay can see it.
Learn each provider's actual schedule. Settlement timing is rarely identical across processors, schemes and banks. Write down, for each route, when funds typically arrive, which days it does not run, and what happens on public holidays. Then check it against reality regularly, because it changes.
Reconcile on settlement, not on sale. Match your internal records to the settlement reports your providers issue, line by line, including fees. Matching at the batch level hides errors. Matching at the transaction level finds them while they are small.
Plan liquidity for the gap. If you pay out before you are paid in, the gap is a funding need. Size it deliberately, rather than discovering it when a payroll run fails.
Tell customers the truth. For refunds and transfers that genuinely take several days, say so at the moment of the transaction. Most frustration comes from a silent wait, not from the wait itself.
A better question to ask
When money seems to be missing, "where is it?" is a good start, but a sharper question is: which of the three steps is it in, and who is carrying the risk while it waits? The answer tells you how long to expect, who to ask, and whether the delay is normal.
Faster rails will keep shrinking the visible gap. Underneath, the same sequence of promise, agreement and movement will continue. Teams that understand the sequence build cash forecasts they can trust, and spend far less time chasing money that was never lost.