Decomposing a payout line by line

If you can take one deposit from your bank statement and account for every component that made it up, your reconciliation works. If you cannot, no amount of software will fix it, because the data required is either absent or unread.

This is the exercise. It is worth doing by hand once, on paper, before automating anything.

The eight components

A gateway payout is almost never a simple sum of sales. Between the transactions and the money there are up to eight movements, and each has to be identified separately.

Gross transactions. The full value of the payments included in this payout, at the amounts the customers were charged. This is the only number that ties back to your sales.

Processing fees. Deducted per transaction, at rates that vary by method. Itemised per transaction in a good settlement report and lumped as a batch total in a poor one.

Refunds. Payments returned to customers within this settlement period, reducing the payout. Note that they reduce it at their own amounts, which may not equal the original sale if the refund was partial.

Refund and reversal fees. Charged per event by some providers, and separate from the processing fee on the original transaction — which may or may not have been returned to you. See what happens to the fee when you refund.

Chargebacks and their fees. A disputed transaction deducted, usually with an administration charge alongside it, and potentially returned later if you win — see chargebacks on your own store.

Reserve withheld. A percentage of this period's transactions held back rather than paid. Not a cost; your money on a delay.

Reserve released. An earlier period's withholding now being paid to you. This increases the payout and belongs to transactions from weeks or months ago, which is why a payout can exceed the period's sales.

Adjustments and corrections. Anything the provider has fixed since the last settlement. The catch-all, and the component most likely to be undocumented.

Add the increases, subtract the decreases, and the result must equal the credit in your bank. Exactly.

Why the exercise is worth doing manually first

Because doing it once tells you whether your provider's data supports it at all, and that is the question everything else depends on.

Pick a payout from a normal week. Get the settlement report covering it. Then work through the components above and see how far you get.

If every component is identifiable and the total ties to the cent, your reconciliation is automatable and the rest is engineering.

If fees arrive as a batch total, per-order margin is not available from this provider. You can still reconcile the payout; you cannot attribute cost to a product.

If the reserve movements are not shown, you will have an unexplained difference every cycle, and it will be roughly the size of your reserve rate.

If there is a residual you cannot name, stop and ask the provider what it is before building anything. An unexplained residual becomes a permanent plug in your books, and plugs grow.

This is the same test worth running during provider evaluation, before signing rather than after — see gateway API or settlement file.

The order that makes it tractable

Work from the payout backwards, not from your sales forwards. This matters more than it sounds.

Start with the bank credit. A known, unarguable amount and date.

Find the settlement report that explains it. Matched by amount and date, and by payout reference where the provider gives one. If the report has not arrived yet, the credit is held unallocated until it does — see when the payout arrives before the report.

List the transactions the report says are inside it. This is the payout's contents, and it is the provider's assertion rather than yours.

Match each transaction to an order. By the reference where one exists; by amount, date and last-four otherwise — see the gateway reference that joins everything.

Total the fees and the other movements.

Confirm the arithmetic closes, then post.

Working forwards from sales instead is the common approach and it produces a difference you then have to explain, rather than an explanation you then confirm. The distinction sounds academic and it decides whether your process finds errors or absorbs them.

Where it fails on a Malaysian Shopify store

The chain has one more link than a merchant on a platform with its own payment product, and the missing piece is specific.

Shopify tells you the order was paid and which gateway did it. It does not tell you what the payment cost or when you were paid, because Shopify Payments is unavailable in Malaysia and Shopify therefore never received the settlement data — see what the Shopify Admin API actually returns.

So the decomposition needs three sources rather than two: Shopify for what was sold, the gateway for what it cost and what was paid out, and the bank for confirmation that it arrived. Joining the first two is the work, and it depends entirely on whether a shared reference survives from checkout into the settlement report — see how Shopify reconciliation actually works.

The four differences you will actually meet

Once the process runs, differences fall into a small number of shapes.

A transaction in the payout with no order. Usually an interrupted payment that succeeded at the gateway and never confirmed to your store. The customer paid and you never recorded a sale — see failed payments and the orders they leave behind.

An order marked paid with no transaction in any payout. Either the payment failed after your store recorded it, or it is in a later settlement. Age it before investigating; most resolve on the next cycle.

A fee that is not the rate you expected. A different card type, a cross-border transaction, or a rate that changed. Worth checking rather than assuming, because provider rate changes are not always announced prominently.

A round number nobody can place. Almost always a reserve movement or a manual adjustment. Ask.

None of these are unusual. What matters is that each is a named category with a defined handling, so the exception queue is a short list of decisions rather than an investigation from first principles — see the exception queue and how to size it.

Common questions

What makes up a payment gateway payout?

Up to eight components: gross transaction value, processing fees, refunds, refund and reversal fees, chargebacks and their fees, reserve withheld this period, reserve released from earlier periods, and any adjustments the provider has made. Adding the increases and subtracting the decreases must equal the bank credit exactly, and each component has to be identified separately rather than netted.

Why can a payout be larger than the period's sales?

Because reserve released from earlier periods increases it. A rolling reserve withholds a percentage of each period's transactions and pays it out later, so any given payout can contain money belonging to transactions from weeks or months earlier, which is why the arithmetic has to treat withholding and release as separate movements.

Should you reconcile forwards from sales or backwards from the payout?

Backwards from the payout. Starting with the bank credit and finding the settlement report that explains it produces an explanation you then confirm. Starting from your sales produces a difference you then have to explain, which is how differences end up absorbed as an expected gap rather than investigated.

What if there is an amount in the payout you cannot identify?

Stop and ask the provider before building any process around it. An unexplained residual becomes a permanent plug in the books, and plugs grow rather than resolve. A round unidentifiable number is most often a reserve movement or a manual adjustment, both of which the provider can confirm.

Related: how to read a payment gateway settlement report · when the payout arrives before the report · payment gateway holds and reserves