Why Gateway Settlements Never Match

A payment gateway credits you a net figure and tells you the gross one. Everything between those two numbers — commission, tax on commission, refunds from an unrelated period, chargebacks, and money withheld against future risk — is deducted before the credit lands. If your ledger records the gross and your bank records the net, the difference is not an error. It is a set of transactions nobody wrote down.

The gross-to-net gap

The dashboard reports what customers paid. The bank reports what arrived. These are different numbers by design, and the gap is composed of specific, itemised things — not a mystery.

The mistake is treating the difference as a single monthly adjustment. Someone posts a journal entry called “gateway charges” for the residual and the books balance. They balance in the same way a plug balances anything: by absorbing whatever was not understood. A year later nobody can say whether the effective rate has changed, whether a refund was deducted twice, or whether a reserve was ever released.

What sits in the gap

Commission, at the contracted rate, which varies by instrument — cards, netbanking and wallets are typically priced differently, and UPI sits apart because merchant discount on UPI is effectively nil in India. That last point matters more than it looks: a business whose mix shifts towards UPI will see its effective blended rate fall, and if the ledger only holds a monthly total it will read that as a discrepancy rather than as the business changing shape.

Tax on the commission, which is a separate line and is recoverable — so it belongs in its own account, not merged into cost.

Refunds, deducted when processed rather than when the original sale happened.

Chargebacks, along with the handling fee that usually accompanies them, arriving weeks after the transaction they relate to.

Rolling reserve, a slice of each settlement held for a defined period against future disputes.

Five categories. Each needs its own ledger account. A single “charges” bucket makes all five unauditable at once.

Refunds land in the wrong period, always

This is the one that most reliably breaks naive reconciliation, and it is not fixable by trying harder.

A payment collected in one month and refunded in the next is deducted from the later settlement. If you reconcile each period as a closed box, the earlier period shows revenue that never fully arrived and the later one shows a deduction with no matching sale. Both look like errors. Neither is.

The fix is to match a refund to its original payment rather than to the day it was deducted. That means the refund entry carries the original transaction reference, and reconciliation follows the reference rather than the date. It sounds obvious written down; it is absent from most implementations I open up, because the settlement file presents refunds as deductions and it is easier to treat them that way.

Rolling reserve is a receivable, not a cost

When a gateway withholds a percentage against future chargeback risk, that money is still yours. It is being held by someone else for a defined period and will be released.

Recording it as a deduction from revenue is wrong twice: it understates revenue in the month it is withheld, and it produces an unexplained credit in the month it releases, which someone will eventually book as other income. On the balance sheet it is a receivable from the gateway, with an expected release date, and it should be aged like any other.

I have watched a founder discover that roughly a month of working capital had been sitting in reserve, invisible, because it had been expensed on the way in and never tracked. Nothing was stolen. It was just unrecorded, and therefore unusable in any cash forecast.

The effective rate is a number, not a contract

The rate you negotiated and the rate you pay are different things, and only one of them is observable.

Once fees are recorded per transaction, the effective rate becomes a daily figure: total deductions divided by total collections, sliced by instrument. Watch it as a series rather than checking it annually. It moves for legitimate reasons — a shift in payment mix towards UPI pulls it down, more card volume pushes it up, a promotional rate expiring changes it overnight — and it moves for illegitimate ones too.

The illegitimate movements are the reason to bother. A rate applied at the wrong tier, a surcharge that was supposed to be temporary, a category reclassified so that transactions price differently: none of these announce themselves. They appear as a slightly larger monthly charges figure, which is exactly the number that gets approved without examination because it is roughly what it was last month.

A business doing meaningful volume should be able to answer “what did payments cost us last Tuesday, by instrument” in a query. Most cannot answer it for last quarter.

The three-way match

Same structure as any settlement reconciliation, and the third leg is the one people skip.

Ledger against settlement report: does the gateway agree with what you think you sold, transaction by transaction? Settlement report against bank credit: did the money the gateway says it sent actually arrive, in that amount, on that date?

Two-way matching — ledger against dashboard — is the common stopping point and it is precisely enough to be confident and wrong. The gateway’s report is the gateway’s position. It agreeing with you says nothing about whether the bank received anything.

Every unmatched item gets a reason code. Over a month those codes become the only honest picture of what your payment stack actually costs.

Building it

Ingest the settlement file — not the dashboard, the file — as its own table with its own dates and its own identifiers. Post each deduction category to its own account. Match refunds by original reference. Age the reserve. Run the bank leg daily.

None of this is difficult engineering. It is unglamorous and it is nearly always missing, which is why it is usually the highest-return week of work available in a payments stack — the same reasoning behind every reconciliation engine I build, and closely related to why ledgers drift in the first place.

If your settlement figures have never been matched line by line against the bank, the honest first step is finding out the size of the gap. That takes days, not a quarter — and it is worth asking about before the next audit does it for you.