Payment gateway fees & reconciliation for Malaysian businesses, in plain words

A customer pays you RM1,000 online. A day or two later, RM975-ish lands in your bank. Where did the rest go, and how should your books show it? This guide explains payment gateway fees for Malaysian businesses in plain words: why the payout is never quite the sale, why booking only the net amount quietly misstates your accounts, the simple two-entry way to record it correctly, and how to reconcile a lump-sum payout back to the individual invoices it paid.

Why the payout never equals what the customer paid

When you collect through a payment gateway — Stripe, Curlec, HitPay, Billplz, senangPay and the like — the customer pays the full amount, but the gateway keeps a processing fee and pays you the rest. The money that reaches your bank (the "payout" or "settlement") is the sale minus that fee, and often minus nothing you can see on the bank line itself.

The fee is usually a small percentage of the transaction plus, on some rails, a fixed sum per transaction; the exact rate depends on your gateway, the payment method (card, FPX online banking, e-wallet) and your pricing plan. This guide deliberately does not quote specific rates — they change and they differ by provider and method — so check your own gateway's current published pricing and your merchant statement for the figures that apply to you.

Two more things distort the bank line. Gateways often pay out in batches — several sales settled together as one lump sum a day or two later — so the amount in your bank rarely matches any single invoice. And some deduct their fees from the batch total rather than per sale, so the payout is "sales collected, less all the fees, less any refunds", arriving as one net number. That is why you cannot just tick a payout against an invoice and move on.

Why booking only the net receipt misstates your books

The tempting shortcut is to record only what hit the bank: RM975 in, call it RM975 of sales, done. It reconciles to the bank in seconds — and it is wrong in two directions at once.

It understates your revenue. The customer paid RM1,000; that is your sale. Booking RM975 hides RM25 of income and, if you are SST-registered or e-invoicing, understates the figure your tax and e-Invoice position is built on. Your top line should reflect what the customer was charged, not what survived the gateway.

And it understates your expenses. The RM25 the gateway kept is a real cost of doing business — a bank/merchant charge — that should appear as an expense you can see, track and (where applicable) claim. Net it silently against sales and that cost vanishes from your P&L; you can no longer answer "how much am I paying in payment fees this year?", which for a high-volume online seller is a number worth watching.

Booking net makes both your revenue and your expenses smaller than they really are. The totals net out to the same profit, but you have blinded yourself to two figures that matter — and quietly mis-stated the base for tax and e-invoicing.

The correct booking: gross sale, fee as an expense

The fix is to record the transaction at its full value and show the fee separately. Book the sale at the gross amount the customer paid; when the payout arrives, split it into the cash you actually received and the fee the gateway kept, posting the fee to a "payment processing fees" (bank charges) expense account.

A clean way to handle the timing is a clearing account. When the sale is collected, the gross amount sits in a "gateway clearing" account (money the gateway is holding for you). When the payout lands, you move the net cash into your bank and the fee into the expense account, which empties the clearing account back to zero. If clearing does not return to zero, something is unaccounted for — a fee you missed, a refund, a payout still in transit — and that is exactly the signal you want.

The principle: components are accounts (a sale is revenue, a fee is an expense), and the payout is just the two of them settling. Never let the fee disappear into a smaller sales figure.

A worked example: RM1,000 collected

Say a customer pays a RM1,000 invoice online, and the gateway keeps RM25 in fees, paying out RM975. The correct books show all three numbers, not just the RM975.

At collection, RM1,000 comes out of the sale and into gateway clearing — your revenue is the full RM1,000 (plus SST handling per your registration, which sits on the gross, not the net). At payout, the RM975 that reaches your bank is recorded as cash received, and the RM25 the gateway kept is recorded as a payment-processing-fees expense. The clearing account, having taken in RM1,000 and released RM975 + RM25, is back to zero.

The result: your P&L shows RM1,000 of revenue and RM25 of payment-fee expense — both visible, both trackable — and your bank shows the real RM975. Book it net and you would have shown RM975 of revenue and no fee at all: same profit, two hidden numbers, and a wrong base for tax and e-invoicing. The RM25 is illustrative — your actual fee comes from your gateway's pricing and your merchant statement.

Reconciling a lump-sum payout back to invoices

Because gateways settle in batches, the hard part is tying one payout in your bank back to the several invoices (and fees, and refunds) that make it up. Reconciliation is proving that "this RM4,812 payout = these twelve sales, less their fees, less that one refund", so nothing is lost or double-counted.

The reliable method is to work from the gateway's payout report or settlement statement, which lists exactly what went into each payout. You match each line to the invoice it paid, book the fee on each, account for any refund, and confirm the report total equals the cash that reached your bank. Do it per payout and your clearing account stays clean; skip it and small fee and refund discrepancies accumulate into a balance nobody can explain at year-end.

This is tedious by hand at volume, which is exactly where software earns its place: matching a payout's lines to open invoices, posting each fee automatically, and keeping the clearing account tied out — so a batch payout becomes a few clicks rather than an afternoon of spreadsheet archaeology.

How Taokeh handles gateway fees and payouts

Taokeh, the Malaysian SME accounting software by Enya Venture, books your sales at gross and treats the gateway fee as its own expense line, so your revenue reflects what the customer paid and your payment-processing cost is a figure you can actually see and track over the year.

When a batch payout arrives, Taokeh helps you reconcile it back to the invoices it settled — matching the payout's lines, posting each fee, and handling refunds — with a clearing account that ties out to zero when everything is accounted for. Because it all sits on one ledger, your sales, your fees and the cash in your bank stay consistent rather than being stitched together from a gateway dashboard and a spreadsheet.

This lives in the same "don't pay for what you don't use" model as the rest of Taokeh: the accounting is in the base plan, and channel- and revenue-specific tooling is added only if you need it. One place to see the gross sale, the fee and the real payout — which is exactly what you want when a return or a lender asks what you actually earned.

Frequently asked questions

Why is my payout less than what the customer paid?

The payment gateway keeps a processing fee — usually a small percentage of the transaction, sometimes plus a fixed amount, depending on the provider, the payment method and your plan — and pays you the rest. Gateways also settle in batches, so the amount in your bank is several sales less their fees (and any refunds), rarely matching any single invoice. Check your gateway's published pricing and merchant statement for your actual rates.

Can I just record the amount that reached my bank?

No — it misstates your books in two directions. It understates revenue (the customer paid the gross, and your tax/e-Invoice base sits on that), and it hides the gateway fee, which is a real expense you should be able to see and track. Book the sale at gross and the fee as a separate expense; the profit is the same but both figures stay visible.

How should I record a gateway sale and its fee?

Book the sale at the full amount the customer paid, hold that gross in a gateway clearing account, and when the payout lands, split it into the net cash (into your bank) and the fee (to a payment-processing-fees expense account). The clearing account should return to zero; a leftover balance flags a missed fee, a refund or a payout still in transit.

How do I reconcile a batch payout to my invoices?

Work from the gateway's payout or settlement report, which lists what went into each payout. Match each line to the invoice it paid, book the fee on each, account for any refund, and confirm the report total equals the cash that reached your bank. Doing it per payout keeps your clearing account clean and stops small discrepancies accumulating.

Updated July 2026

This guide is general information for Malaysian SMEs, not tax, legal or accounting advice. Always confirm current rules and figures with the relevant authority or your own adviser.

Recurring-revenue accounting in Taokeh — invoicing, recognition and payout reconciliation

Run the books for your Malaysian SME on one ledger — accounting, payroll and selling channels.

See how Taokeh handles it → Start your free trial