When your gateway settlement does not match your orders

You compare a week of storefront orders against what the gateway paid you, and the numbers disagree. Now what?

The instinct is to assume an error somewhere and start hunting. In practice the difference is almost always one of six causes, and only two of them need action. Knowing which is which turns a day of investigation into twenty minutes.

Six reasons the numbers differ

1. The settlement period is not your period. The batch covers whatever window the provider uses, so orders near either boundary fall into an adjacent settlement. This accounts for most first-time differences and is not a problem at all. It only looks like one because you compared two different date ranges.

2. Fees came out. Obvious once stated, and still the second most common cause. The gross was your sale, the deposit is net. If you are comparing order values to a deposit, you are comparing gross to net and they will never agree.

3. A refund landed. Refunds reduce a later settlement, not the one containing the original sale. So a week with several refunds settles low against its own orders, and the week those sales originally landed in settled high.

4. Something is still in flight. Authorised but not captured, pending, or held for a risk review. The order exists in your system; the money has not settled yet and may settle next period.

5. A chargeback or dispute. The money is reversed, sometimes with an administrative charge, typically weeks after the sale. This one arrives with no relationship to the period you are looking at.

6. A settlement that never arrived. The rarest and the only one that costs you permanently if unnoticed. A batch that failed, a payout to a bank account detail that changed, or something held and then forgotten.

Causes 1 to 5 are explainable. Cause 6 is why any of this is worth doing.

The order to check them in

Work from cheapest to most expensive.

Align the periods first. Pull the exact settlement window from the report and compare against orders in that window, not your week. A surprising share of differences vanish here.

Then add the fees back. Compare gross-to-gross. If the settlement gross now matches your order total, everything is accounted for and the difference was only ever the fee.

Then locate refunds and chargebacks. These are individually identifiable in the report. Tick them off against the orders they belong to.

Then look at what is pending. Orders with no settlement line at all, where the payment status suggests it is still processing.

What remains is the real question. Orders that were paid, are not pending, have not been refunded, and have no settlement line anywhere. That short list is the only part that needed a human all along.

The one that costs money

Delivered orders with no payout against them is the finding that justifies the entire exercise.

It is rarely dramatic. A settlement failed silently. A hold was placed during a fraud review and never released because nobody responded to an email that went to an address no longer monitored. A bank detail was updated and one batch went to the old one.

None of these announces itself. Gateways are not adversarial about it and will generally sort it out once asked. But nobody is going to tell you, because from the provider's side there is nothing obviously wrong.

The only way this surfaces is if something is systematically comparing orders that were paid against settlements that arrived. Not a spot check — a standing comparison, because the gap between the two is exactly where money goes missing quietly.

Why this gets harder with more than one gateway

Everything above assumes one settlement stream. Run three and the difficulty is not three times greater, it is worse than that, because an order paid through one gateway and refunded through the same one still has to be found among three sets of reports with three different formats and three different settlement calendars.

At that point matching by hand stops being a monthly chore and starts being a role. The work itself has not changed; there is just more of it, and it is the kind of work that scales badly with people and well with rules.

What good looks like

An order carries its payment through to settlement without anyone assembling that chain by hand. You can open a sale from four months ago and see what the customer paid, which gateway took it, what was deducted, which batch it settled in, and whether any of it later came back.

That is the difference between a reconciliation you can perform and a reconciliation you can trust. The first proves the totals agree this month. The second lets you answer a question about one specific transaction, years later, without reconstructing anything — which is the point of keeping records traceable in the first place.

Common questions

My deposit is lower than my sales. Is that a problem?

Almost certainly not by itself. It should be lower, because fees came out, and it may be lower still because refunds from an earlier period landed in this one. It becomes a problem only when you have accounted for period alignment, fees, refunds and pending payments and a gap remains.

How do I find an order that was paid but never settled?

By comparing paid orders against settlement lines and listing the ones with no match, after excluding anything still pending. Doing this once is tedious. Doing it continuously is the only way it gets caught early enough to query.

Should I chase every small difference?

No. Set a threshold below which a difference is written off, and be honest that you have set one. What matters is that the write-off is a decision you made rather than a residue nobody looked at, and that the same small difference recurring every month gets investigated rather than absorbed.

How long should I wait before treating a settlement as missing?

Longer than the provider's stated settlement time plus any hold period, which varies. The practical answer is that you do not need to decide up front, as long as pending items stay visible rather than disappearing from view.

Two numbers that were never going to match

Comparing orders to a deposit is comparing gross to net across mismatched dates. Of course they differ.

The useful exercise is not making them equal. It is being able to explain every ringgit of the difference, and noticing the part of it that has no explanation.