Shopee, TikTok Shop & Stripe Net Settlement Bank Reconciliation: Handling MDR Fees & Delays

Start with gross-to-net, not a one-to-one bank match

A Shopee, TikTok Shop, or Stripe settlement is normally a batch reconciliation, not a search for one order equal to one bank credit. The accountant must prove this control equation from the platform or gateway report:

Gross sales in the batch
− customer refunds and reversals
− MDR, gateway, commission, and other report-backed fees
± report-backed adjustments
= net payout credited to the bank

MDR means merchant discount rate. It is a commercial processing charge, not a Malaysian statutory rate. Never assume a percentage from a previous payout: use the actual fee line in the relevant settlement report. Shopee, TikTok Shop, and Stripe can present different report layouts and transaction labels, so build one internal reconciliation format without pretending their native columns are identical.

For example, suppose a report contains RM10,000 of gross sales, no refunds, and RM300 of fees. The bank receives RM9,700:

Batch component	Amount (RM)	Evidence
Gross sales	10,000.00	Order-detail total tied to the batch
Less: MDR or gateway fees	(300.00)	Fee lines in the settlement report
Net payout	9,700.00	Payout report and bank credit

The RM300 difference is not a missing customer payment. It is an expense withheld before cash reaches the bank. A bank-feed article that searches only for RM10,000 will leave the deposit unmatched; one that treats RM9,700 as sales understates both revenue and fees.

What is the correct double-entry for a net settlement?

The journal depends on whether gross sales were already recognised.

When invoices or sales were recorded before settlement, GetPay's seeded chart provides these relevant conventions:

• 1200 Accounts Receivable;
• 4200 Sales Revenue;
• 6100 Bank Charges, reached by the BANK_FEE category; and
• a mapped bank account such as 1110 Public Bank, 1120 UOB, 1130 Maybank, 1140 BSN, or 1150 CIMB.

The sale entry is:

GL account	Debit (RM)	Credit (RM)
1200 Accounts Receivable	10,000.00	—
4200 Sales Revenue	—	10,000.00

When the RM9,700 payout lands and the report proves RM300 of fees, clear the gross receivable:

GL account	Debit (RM)	Credit (RM)
Mapped bank account	9,700.00	—
6100 Bank Charges	300.00	—
1200 Accounts Receivable	—	10,000.00
Total	10,000.00	10,000.00

This is the cleanest entry when every underlying sale has already credited revenue. It preserves gross revenue, exposes the fee on the profit and loss statement, and clears the same gross asset created by the sale.

A compressed entry is sometimes used when revenue has not been posted elsewhere:

Dr Bank (net cash)
Dr fee expense (withheld fee)
    Cr Sales Revenue (gross sales)

Use that version only when it matches the entity's revenue-recognition process and cannot duplicate an order-level sale. If orders were already posted to 4200, crediting revenue again at payout doubles sales. If the business needs a dedicated marketplace clearing account, configure and document one in its own chart of accounts; GetPay's named grounding files do not define a separate Shopee, TikTok Shop, Stripe, or generic gateway-clearing code.

Why do several orders become one bank credit?

A platform or gateway collects customer transactions throughout a settlement window and transfers the payable balance as one payout. The batch may include orders from different dates, and the cash may arrive after the settlement report closes. That creates a 1:N relationship:

one bank credit
        ↓
one payout or settlement batch
        ↓
many orders, refunds, fees, and adjustments

The bank statement is therefore the final cash proof, not the complete sales subledger. It usually tells you the value date, amount, reference, and description. It does not, by itself, prove which orders, refunds, or charges make up the credit.

Build a normalized batch schedule with at least:

• batch_id: the platform or gateway's durable payout identifier;
• order_id: each order or transaction linked to that batch;
• transaction_type: sale, refund, fee, chargeback, reserve, or adjustment, but only where the report actually uses or supports that classification;
• order_date, settlement_date, payout_date, and bank_value_date;
• gross_sales, refunds, fees, adjustments, and net_payout;
• currency; and
• the source filename or report period.

These are reconciliation fields you control, not a claim that all three providers export those exact headers. Preserve the native report alongside the normalized schedule so another accountant can reproduce every transformation.

How should the settlement file be reconciled step by step?

1. Freeze the reporting population

Download the detailed order or balance activity and the settlement or payout report for the same scope. Record the export time, account, currency, period, and filenames. Do not keep refreshing one report while reconciling it against an older copy of another.

2. Identify the batch before touching the bank line

Use the provider's payout, settlement, or transfer identifier where available. Group every reported component by that identifier. If the report does not assign a final payout yet, keep the transactions in an unsettled roll-forward rather than inventing a batch.

3. Normalize signs once

Store gross sales as positive, deductions such as refunds and fees as positive deduction columns, and signed adjustments in one documented convention. The equation should be readable without mentally reversing negative numbers several times:

gross_sales - refunds - fees + signed_adjustments = net_payout

If a provider already exports fees as negative amounts, either retain its signed presentation everywhere or convert them once and document the conversion. Mixing the two conventions is a common reason a batch appears to be off by exactly twice the fee.

4. Prove order detail to gross batch value

Sum the order-level rows assigned to the batch and compare them with the report's gross figure. Investigate duplicates, cancelled orders, partial refunds, currency differences, and transactions outside the selected period. Do not use the bank amount as a plug.

5. Prove every deduction

Tie the fee, refund, chargeback, reserve, shipping, tax-on-fee, or other adjustment columns to explicit report lines. Not every provider or batch uses every component. A blank line is not evidence of zero if the export was filtered or truncated.

6. Match net payout to the bank

Only after the gross-to-net equation balances should the net payout be matched to a bank credit. Compare amount, currency, bank value date, description, reference, and payout timing. A date difference can be legitimate; an amount difference needs a report-backed explanation.

7. Post and retain the audit trail

Post the journal once, attach or link the batch schedule, and mark the relevant source rows as reconciled. The evidence pack should let a reviewer travel in both directions: bank credit to batch to orders, and order to batch to bank credit.

What does GetPay actually propose and confirm?

GetPay's current settlement matcher reads a bank statement line using the real fields date, amount, ref, description, bank, and txn_type. It compares credit lines with open invoices carrying invoice_id, invoice_number, customer_name, total, outstanding, and status.

Only a positively identified credit is considered. A debit, blank txn_type, or unrecognised direction is skipped rather than assumed to be customer cash. The matcher produces proposals in descending evidence tiers:

Match tier	What the code checks	Score
exact_ref	Invoice number appears in ref or description, with digit-boundary protection	1.0
amount_party	Credit equals one or more invoice outstanding balances and a customer-name token overlaps	0.7
amount_only	Credit equals one or more invoice outstanding balances without party corroboration	0.4

Every result remains a proposal. The pure matcher does not post a ledger entry or settle an invoice.

Confirmation requires a candidate_id, positive expected_version, and non-empty adjudicated_by; an optional bank_account_id identifies the landing account. The confirmation path refuses an unresolved landing bank account and an account flagged as inter-entity. It also checks that the payment date is in an open accounting period.

For one proposed invoice, the recorded payment is capped at that invoice's outstanding balance. For several proposed invoices, their outstanding balances must add to the bank credit within half-a-cent tolerance. Otherwise the confirmation is refused as ambiguous. Payments go through GetPay's canonical invoice-payment route and use deterministic idempotency keys so a retry does not intentionally create a second settlement.

This distinction matters for net marketplace payouts. If gross invoices total RM10,000 but the bank line is RM9,700 because RM300 was withheld, the current multi-invoice confirmation cannot infer that the RM300 is a fee. The accountant must first perform the gross-to-net decomposition and book the supported fee treatment. Do not alter invoice balances merely to make the candidate pass.

How should settlement delays be handled at month-end?

Keep four dates separate:

Date	What it answers
Order or sale date	When did the underlying transaction occur under the entity's accounting policy?
Settlement date	When did the provider group the activity into a payable batch?
Payout date	When did the provider initiate or report the transfer?
Bank value date	When did cash appear in the business bank account?

Suppose RM10,000 of qualifying August sales is recognised by 31 August, the platform finalises the batch on 1 September, and RM9,700 reaches the bank on 3 September. August should not omit the gross sale merely because the cash arrived in September. The receivable or platform-clearing balance carries the unsettled amount across month-end.

At close, prepare a roll-forward:

Opening unsettled platform receivable
+ gross sales recognised
− refunds and fee deductions recognised
− payouts received in the bank
± supported adjustments
= closing unsettled platform receivable

Then list batches in transit by identifier, currency, amount, settlement status, and expected bank destination. Reverse or clear only the entries that the next period's bank credit and settlement report actually support. A late payout is a timing difference; an unexplained amount is a reconciliation exception.

Which exceptions should never be forced?

The bank credit is lower than the payout report

Check currency conversion, split payouts, bank charges, reserves, and whether the report is final. Record only items shown by reliable evidence. Do not create an arbitrary “MDR” line to make the batch balance.

Two batches share the same amount

Amount is not a durable identity. Use batch identifiers, bank references, dates, and provider account or currency. GetPay's amount-only tier deliberately has lower confidence and still requires confirmation.

A refund is in a later batch

Keep the original sale and later refund traceable to their respective batches. Do not reopen a previously balanced payout simply because a later report contains the reversal.

One bank credit covers several invoices but includes a fee

The outstandings will exceed the net bank amount, so the current GetPay multi-invoice allocation should refuse it. Post the report-backed fee and clear the gross receivable through the appropriate controlled journal instead of editing the bank amount or suppressing part of a sale.

The landing account cannot be resolved

GetPay fails closed because it cannot determine whether the credit crossed a legal-entity boundary. Select a registered landing bank account or correct the bank-account setup before confirming. Never settle one entity's invoice with another entity's bank receipt as if it were an ordinary customer payment.

Month-end net-settlement checklist

• Reconcile order detail to gross batch sales.
• Reconcile refunds, fees, and every other deduction to explicit report lines.
• Prove the gross-to-net equation before matching the bank.
• Match the payout's net amount, currency, identifier, and timing to one bank credit.
• Confirm revenue was not posted both at order level and again at payout.
• Use 6100 only where the entity's chart and evidence support the BANK_FEE treatment.
• Keep unreceived payouts in a receivable or documented clearing balance at month-end.
• Roll opening unsettled items to closing unsettled items; investigate values, not only row counts.
• Preserve the native report, normalized schedule, bank line, journal, and reviewer decision.
• In GetPay, treat settlement candidates as proposals and confirm only after the gross-vs-net accounting has been resolved.