The three-way match a Malaysian store needs

Reconciliation is usually described as matching your sales to your bank. For a Malaysian online store that description is missing the hardest step.

There are three separate records of the same money, held by three parties, in three formats, on three different clocks. The reconciliation is the join across all of them, and no two of the three are sufficient on their own.

The three records

Your store knows what was sold. Orders, line items, discounts, taxes, shipping charged, the payment method used and which gateway handled it. Rich and complete on the sales side — see what the Shopify Admin API actually returns.

Your gateway knows what the payment cost and when it paid you. Transactions, fees, refunds, chargebacks, reserve movements, and the grouping of transactions into payouts. This is the only source for the money side.

Your bank knows what arrived. Amounts and dates, with narration that identifies the source poorly if at all.

Each is authoritative about its own domain and silent about the others. The store does not know what the payment cost. The gateway does not know what was sold. The bank knows neither.

Why two is not enough

Every shortcut here is a version of matching two of the three, and each fails in a characteristic way.

Store to bank, skipping the gateway. The most common shortcut and the most damaging. Bank deposits are net of fees, refunds, chargebacks and withheld amounts, so revenue recorded from them is understated and the fees are never recorded at all. The books balance and per-order margin is unavailable — see reconciling two gateways into one bank account.

Gateway to bank, skipping the store. This confirms the money moved as the provider said and tells you nothing about what was sold. No product-level revenue, no margin, no stock movement.

Store to gateway, skipping the bank. Confirms the payment was taken and never confirms you were paid. A payout that was never sent, or was sent to a closed account, is invisible.

The three-way match exists because each pair leaves a specific and material gap.

Where the platform difference bites

Merchants on a platform using that platform's own payment product often get two of the three joined for them. The platform took the payment, so it knows the fee and the payout, and the reconciliation collapses toward store-to-bank with the middle already filled in.

That is not available in Malaysia. Shopify Payments is not offered here, so a Malaysian Shopify store necessarily uses a third-party gateway, and the fee and settlement data lives with that gateway rather than in Shopify — see the Shopify third-party gateway fee explained.

The consequence is structural rather than a matter of effort. A connector that reads Shopify beautifully has solved one third of the problem. The join between Shopify's orders and the gateway's settlements is the part that decides whether the books close, and it is the part no single-platform integration provides.

The join that makes it possible

Everything depends on one thing: a reference that survives from the store's order into the gateway's settlement report.

Where it exists, the match is deterministic. Order reference in the gateway record, gateway reference in the order, and each transaction attaches to exactly one order with no ambiguity.

Where it does not, you are matching on amount, date and payment method, which works until two customers buy the same thing on the same day — at which point the match is a guess with a plausible answer. That is worse than no match, because it looks resolved. See the gateway reference that joins everything.

So the single highest-value question to ask before building or buying anything: does my gateway's settlement data carry my store's order reference? If yes, the rest is engineering. If no, that is a checkout configuration change worth making before anything else, and it is usually possible.

What the process looks like when it runs

Three passes, each with a defined output, in this order.

Store to gateway. Every order matched to its transaction, every transaction matched to its order. The output is two exception lists: orders with no payment, and payments with no order. Both should normally be empty — see matching orders to transactions to payouts.

Gateway to bank. Every payout decomposed and tied to its bank credit, with all eight components identified — see decomposing a payout line by line.

Completeness sweep. A periodic full pull comparing what the store holds against what your system holds, catching anything a missed notification dropped — see Shopify webhooks and why they are not enough.

Run in that order, each pass has clean inputs. Run out of order and every difference has several possible causes.

The number that tells you it is working

One figure, and it should be boring: money earned but not yet explained.

Bank credits received with no allocated settlement report, plus settled transactions with no matching order, plus orders with no matching transaction. Small, and clearing on a predictable rhythm.

If it grows, one of the three joins has broken, and the composition tells you which. That is the entire health check, and it is more informative than any dashboard — see keeping automated books healthy.

Common questions

What is a three-way match in ecommerce reconciliation?

Joining three separate records of the same money: the store's record of what was sold, the gateway's record of what the payment cost and when it paid out, and the bank's record of what arrived. Each source is authoritative about its own domain and silent about the others, so any two of the three leave a specific and material gap.

Why do Malaysian Shopify stores need a three-way match?

Because Shopify Payments is not available in Malaysia, so the store necessarily uses a third-party gateway and the fee and settlement data sits with that gateway rather than inside Shopify. Merchants in markets where the platform's own payment product is available often get two of the three records joined for them, which is not an option here.

What is the most damaging reconciliation shortcut?

Matching the store directly to the bank and skipping the gateway. Bank deposits are net of fees, refunds, chargebacks and withheld amounts, so revenue recorded from them is understated while the fees are never recorded at all. The books still balance, which is exactly why the error persists undetected.

What single thing makes a three-way match possible?

A reference that survives from the store's order into the gateway's settlement report. With it, every transaction attaches to exactly one order deterministically. Without it, matching falls back to amount, date and method, which produces plausible but wrong matches as soon as two customers buy the same item on the same day.

Related: how Shopify reconciliation actually works · decomposing a payout line by line · the gateway reference that joins everything