How Shopify reconciliation actually works in Malaysia

Reconciling a marketplace is a two-way problem. The platform publishes a settlement report showing orders and the fees taken from them, you match the resulting payout to your bank, and the work is tedious rather than hard.

A Malaysian Shopify store has no settlement report, because no single party is in a position to produce one. What you have instead is three systems that each hold part of the answer and none of which knows about the others.

The three sources, and what each one knows

Shopify knows the commercial transaction. Order number, line items, quantities, discounts, taxes, shipping charged to the customer, gross order value, refunds, cancellations. It does not know what the payment cost or when you were paid.

The gateway knows the money movement. Its own transaction reference, the amount captured, the processing fee, the net, which payout batch it fell into, holds, reversals, chargebacks. It knows almost nothing useful about what was sold.

The bank knows one thing. A lump sum arrived on a date, from a named originator, with a narration string.

The task is joining them. Nothing in the design of these three systems is trying to help you.

Why the joins are hard

Shopify to gateway. There is usually a reference passed at checkout, but what survives into the gateway's records varies by gateway and configuration. Sometimes it is the order name, sometimes an internal identifier, sometimes a truncated string. This is the join to establish first and to verify on real data before trusting it.

Gateway to bank. A payout covers many transactions across a window, arrives net of fees, and lands with a narration that may be the gateway's name and a batch code. One deposit corresponds to no single order. It corresponds to a set of orders minus a set of fees minus anything withheld.

Shopify to bank. There is no direct join at all, and any attempt to build one is a mistake. The bank is downstream of the gateway, and the gateway is where the arithmetic happens.

The order the work has to happen in

Reversing these steps is the single most common way a reconciliation stalls.

1. Establish the order-to-transaction join

Take a day of orders and a day of gateway transactions and match them by hand. Confirm which field actually corresponds, confirm it survives partial payments and retries, and confirm what a failed-then-successful attempt looks like on both sides.

Until this join is proven on real data, nothing downstream can be trusted.

2. Decompose the payout

Take one payout and account for every ringgit of it. Gross of the transactions inside it, minus fees, minus refunds settled in the same batch, minus any hold or reserve, equals the deposit.

Every line must be identified. Anything unrecognised is either a fee you did not know about or an error. Absorbing it into a balancing figure destroys the point of the exercise — see when your gateway settlement does not match your orders.

3. Match the payout to the bank

The easy step, once the payout is decomposed. Amount and date, with a tolerance of zero.

4. Post the accounting entries

Revenue at gross from the order. Fees as an expense. The net as the bank movement. Not the other way round.

5. Add the platform fee

The Shopify third-party transaction fee is not in any of the three sources above — it arrives on the Shopify invoice. It has to be brought in separately and allocated across the orders of the period, or margin is overstated. See the Shopify third-party gateway fee explained.

The cases that break naive matching

Partial captures and retries. A customer whose first attempt fails and second succeeds may produce two gateway records against one order.

Refunds settled in a later batch. The refund belongs to the original order but appears in a payout weeks later, possibly a payout that is otherwise unrelated.

Chargebacks. These arrive as a deduction with a fee, referencing a transaction from a month ago, and they reverse revenue that has already been recognised and reported.

Currency. If you sell in more than one currency, the order, the capture and the settlement can each sit at a different rate. The difference is not a margin problem and should not be buried in cost of sales — see multi-currency accounting with AI.

Two gateways, one bank account. Two payout streams landing in the same place, distinguishable only by narration. Very common, and the reason many merchants stop reconciling entirely.

Manual and offline orders. Draft orders, bank transfers taken over WhatsApp, cash on collection. These have Shopify orders and no gateway record at all, and they must be excluded from gateway matching rather than sitting forever as exceptions.

What has to be automated, and what does not

The matching. It is mechanical, high volume, and exactly the shape of problem where a person handling it alongside other work will fall behind and then stop.

What should not be automated is the judgement about the exceptions. A payout that does not decompose, a fee that does not match the expected rate, a chargeback pattern on one product — those want a person, and the point of automating the other 98% is to give somebody the time to look at them properly. See the exception queue as a control.

What a finished reconciliation looks like

• Every Shopify order matched to a gateway transaction, or explicitly marked as not having one
• Every gateway transaction matched to a payout
• Every payout decomposed to the ringgit and matched to a bank deposit
• Fees posted as expenses against the orders that incurred them
• The Shopify platform fee allocated across the period
• Refunds and chargebacks recorded with their fees, separately from sales
• An exception list short enough that somebody actually reads it

That is the standard. It is achievable, and doing it by hand at any real volume is not.

Common questions

What makes Shopify reconciliation harder in Malaysia?

The absence of Shopify Payments. Elsewhere Shopify processes the payment and can report orders, fees and payouts together; in Malaysia a third-party gateway holds the money data while Shopify holds the order data, so reconciliation requires joining three systems — Shopify, the gateway and the bank — using references that were never designed to correspond.

What order should the reconciliation steps happen in?

Establish the join between Shopify orders and gateway transactions first and verify it on real data, then decompose one payout completely, then match that payout to the bank, then post revenue at gross with fees as expenses, and finally bring in the Shopify platform fee from its invoice. Attempting to match Shopify orders directly to bank deposits skips the step where the arithmetic actually happens.

Why should revenue be recorded from orders rather than bank deposits?

Because the deposit is net of processing fees, refunds and any amounts withheld. Recording revenue from it understates sales, hides the fees entirely rather than recording them as an expense, and makes every product look more profitable than it is.

What breaks automatic matching most often?

Payment retries producing two gateway records for one order, refunds settling in a much later batch than the original sale, chargebacks arriving weeks afterwards with a fee attached, multiple gateways paying into a single bank account, and manual or offline orders that have a Shopify record but no gateway transaction at all.

Related: Shopify in Malaysia · when your gateway settlement does not match your orders · how to read a payment gateway settlement report