Reconciling two gateways into one bank account

Running more than one payment gateway is normal and usually sensible. Reconciling them is where it becomes expensive, and the expense is entirely avoidable.

The problem is not that there are two sets of data. It is that both sets end up as credits in one bank account, at overlapping times, in amounts that carry no indication of where they came from.

Why merchants end up with two

Rarely by design. The common routes are all incremental.

One gateway was added for FPX because the original one was card-first. A second was taken on for a specific wallet, or because a marketplace channel required it. A cheaper provider was signed and the old one was kept running for the customers already on it. Or a gateway had an outage once and a backup was arranged and never removed.

Each decision was defensible. The cumulative result is two or three settlement streams, each with its own cycle, fee structure, report format and reference scheme — see running more than one payment gateway.

The narration problem

Open the bank statement and the difficulty is immediate.

Bank narration for a gateway payout is short, often abbreviated, sometimes identical between cycles, and frequently the same for two different providers using the same settlement bank. There may be a reference number that appears nowhere in the gateway's own report.

So the only reliable distinguishers are amount, date and pattern, and all three degrade in exactly the conditions where you need them: when both gateways pay on the same day, when volumes are similar, or when a payout is unusually timed because of a holiday.

Once two credits of similar size land on one date and neither narration identifies its source, you are guessing. And a guess that is wrong does not announce itself — it produces two payouts allocated to the wrong providers, both of which then fail to reconcile against their reports for reasons that look like data problems.

Separate the streams before you match them

The whole discipline is here, and it is upstream of any software.

Give each gateway a distinct bank account if you can. This is the clean answer and it removes the problem entirely rather than managing it. Two accounts, two statements, no ambiguity, and the reconciliation becomes two simple exercises instead of one hard one. The cost of a second account is trivially less than the cost of the alternative.

If you cannot, separate at the ledger. One clearing account per gateway. Every credit is allocated to a gateway's clearing account first, and only then decomposed against that gateway's report. The clearing balance for each provider is then a live measure of how much of its money has arrived and not yet been explained.

Never allocate from the bank alone. The gateway's report tells you a payout of a given amount was sent on a given date. That is your evidence, and the bank credit is confirmation of it — not the other way round. Reconciling from the bank is how revenue ends up recorded net of fees, which is the most common accounting error in ecommerce.

Reconcile each stream on its own cycle. Two providers on different rhythms do not have a common close. Forcing them into one weekly routine means one is always mid-cycle — see settlement timing and your cash forecast.

The month-end view that actually works

Three numbers per gateway, and they should each be small and stable.

Settled but not yet paid out — transactions the gateway has confirmed with a payout still to come.

Paid out but not yet allocated — credits in the bank whose report has not been processed, which should clear within days.

Held or reserved — withheld amounts, which are your money on a delay rather than a cost — see payment gateway holds and reserves.

Sum the three across providers and you have total money earned and not yet available, which is the figure that explains a profitable month with an uncomfortable bank balance. Kept per gateway, it also tells you immediately which provider a discrepancy belongs to, which is most of the diagnostic work.

What breaks when you skip this

The failure mode is consistent and worth naming, because it is recognisable.

Reconciliation is done at the account level. Total credits are compared against total sales. The difference is broadly explained as fees and written off, and per-transaction matching never happens.

That process closes the books and destroys the useful information. Fee rates per method are unknown, so margin is unknown. A gateway overcharging or a payout that never arrived is invisible, because both sit inside a difference that was expected to be there. Chargebacks and holds are absorbed into the same lump — see how to read a payment gateway settlement report.

The books balance. Nothing in them can be trusted at the level where decisions get made.

Common questions

Should each payment gateway have its own bank account?

Where it is practical, yes. Separate accounts remove the ambiguity completely rather than managing it, because each statement contains one provider's payouts and the reconciliation splits into two straightforward exercises. The administrative cost of a second account is far smaller than the cost of untangling similar-sized credits from two providers landing on the same day.

How do you tell two gateways' payouts apart in one bank account?

Not reliably from narration, which is short, often abbreviated and frequently identical between providers using the same settlement bank. The workable approach is to allocate every credit to a per-gateway clearing account using that gateway's own settlement report as the evidence, treating the bank credit as confirmation rather than as the source of the allocation.

Why is reconciling from the bank statement wrong?

Because bank deposits are net of fees, refunds, chargebacks and any withheld amounts. Recording revenue from them understates sales and leaves the fees unrecorded entirely, so per-method margin becomes unknowable. The settlement report is the evidence for what a payout contained, and the bank credit only confirms that it arrived.

What should you track per gateway at month end?

Three balances: settled but not yet paid out, paid out but not yet allocated, and held or reserved. Each should be small and stable, growth in any of them signals a specific problem, and keeping them per provider means a discrepancy immediately identifies which gateway it belongs to.

Related: running more than one payment gateway · when the payout arrives before the report · automating bank reconciliation with AI