When the payout arrives before the report

Money lands. You go to reconcile it and the settlement report covering it is not available. It arrives a day later, sometimes two.

This is normal with several gateways and it is not an error. It is also the reason a great many reconciliation processes are designed badly, because the design has to accommodate a gap that nobody mentions during evaluation.

Why the gap exists

The payout is a bank instruction. The report is a document assembled from the gateway's own reconciliation of its position with the card networks, banks and wallet providers upstream.

Those are separate processes. The instruction goes out on a schedule; the document is produced when the underlying data is final. Where an upstream party is slow, the report waits and the money does not.

Some gateways publish both together. Some publish the report first. Some pay first and explain later. It is worth knowing which yours does before designing anything around it.

The two bad responses

Reconcile from the bank. Tempting, because the bank data is what you have. It is also how revenue ends up recorded net of fees, with the fees never recorded at all — the single most common accounting error in ecommerce. See how Shopify reconciliation actually works.

Wait for everything, then do it all at month end. Which converts a daily task with a small queue into a monthly project with a large one, arriving exactly when the finance team has least capacity. By then a query about a two-week-old fee is a research exercise.

What works instead

Treat the deposit and its explanation as two events, and expect them to be separated.

Record the deposit as unallocated. A bank credit that has arrived and has not yet been attributed. Not revenue, not income — a holding position awaiting its report.

Allocate when the report lands. Decompose the payout, attribute the transactions and fees, clear the holding position. See decomposing a payout line by line.

Age the holding position. Anything unallocated beyond the normal gap is an exception. A payout whose report never arrived is either a gateway problem or a payment from a source you have forgotten you have.

That last point catches a genuine class of error: a directly settled e-wallet or a dormant gateway still paying out occasionally, whose credits sit unexplained because nobody remembers the arrangement — see e-wallet payments and how they settle.

Why the holding account matters

It is the difference between a reconciliation that is behind and one that is broken.

With a holding position, at any moment you can say exactly how much money has arrived that you have not yet explained. That number should be small and should clear on a predictable rhythm. If it grows, something has stopped working, and you know within days.

Without it, unexplained credits are absorbed into revenue or into a suspense account nobody reviews, and the drift is invisible until an auditor or a bank asks a question — see keeping automated books healthy.

The practical rhythm

Daily: deposits recorded as unallocated. A mechanical step, minutes.

As reports arrive: allocate, decompose, clear. Automated where the report is machine-readable.

Weekly: review what is still unallocated and why.

Month end: confirm the holding position is at its expected steady-state size rather than reconstructing the month.

The point is that month end contains no reconstruction. Everything has been allocated as it arrived, and the close is a confirmation rather than an investigation — see month-end without the scramble.

Common questions

Why does a gateway payout arrive before its settlement report?

Because they are produced by separate processes. The payout is a bank instruction sent on a schedule, while the report is assembled once the gateway has finalised its own position with the card networks, banks and wallet providers upstream. When an upstream party is slow the report waits, but the money has already moved.

Should you reconcile from the bank statement when the report is late?

No. Bank deposits are net of fees, refunds and any withheld amounts, so recording revenue from them understates sales and leaves the fees unrecorded entirely. The deposit should instead be held as an unallocated credit until the report arrives and the payout can be decomposed properly.

What is the right way to handle the gap?

Record the deposit as an unallocated bank credit — a holding position rather than revenue — then allocate it when the report arrives by decomposing the payout and attributing transactions and fees. Age the holding position so anything outstanding beyond the normal gap becomes a visible exception.

Why does a holding account matter for reconciliation health?

Because it tells you at any moment how much money has arrived that you cannot yet explain. That figure should be small and clear on a predictable rhythm, so growth in it signals a problem within days. Without it, unexplained credits get absorbed into revenue or a suspense account and the drift stays invisible until someone external asks.

Related: decomposing a payout line by line · month-end without the scramble · how to read a payment gateway settlement report