FPX Payment Gateway MDR Reconciliation: Handling Settlement Delays & Bank Deposits

Start with the settlement batch, not the individual bank credit

FPX payment gateway reconciliation accounting starts with a gross-to-net proof. One bank credit may represent many customer payments, while the gateway or acquirer may deduct MDR or other supported adjustments before depositing the balance. The control equation is:

Gross successful collections assigned to the batch
− refunds or reversals included in that batch
− MDR and other report-backed fees
± other report-backed settlement adjustments
= net amount credited to the merchant bank account

MDR means merchant discount rate. It is a commercial transaction charge governed by the merchant's arrangement with its acquiring bank, gateway, or exchange; it is not a statutory Malaysian rate. PayNet's published FAQ says transaction fees depend on that agreement. Use the fee amount shown in the applicable merchant settlement evidence, never a percentage remembered from another provider or month.

Suppose an FPX-enabled gateway reports RM5,000 of successful collections, withholds RM50 of transaction fees, and deposits RM4,950:

Batch component	Amount (RM)	Evidence
Gross successful collections	5,000.00	Transaction detail tied to the batch
Less: MDR or gateway fees	(50.00)	Settlement report or fee invoice
Net payout	4,950.00	Payout record and bank credit

The RM50 is not an unpaid customer balance if the settlement evidence proves it was withheld as a fee. Equally, the RM4,950 is not the correct gross revenue merely because that is what the bank received. The accounting must retain both the RM5,000 receivable clearance and the RM50 expense.

What is the correct FPX MDR transaction fee journal?

When the underlying invoices were already recognised, the initial sale entry created a gross receivable. Using GetPay's seeded chart conventions, a product sale could be:

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

For service or tuition invoices, GetPay's invoice-type mapping may use 4100 Tuition Revenue instead. The settlement principle is unchanged: clear the same gross receivable that the invoice created.

When RM4,950 reaches the bank and the settlement evidence supports RM50 of MDR, the gross-to-net settlement entry is:

GL account	Debit (RM)	Credit (RM)
Mapped bank account	4,950.00	—
6100 Bank Charges	50.00	—
1200 Accounts Receivable	—	5,000.00
Total	5,000.00	5,000.00

GetPay's category convention maps BANK_FEE to 6100 Bank Charges. That is a repository-defined default, not a universal instruction to use the same code in every accounting system. If the entity's approved chart separates payment-processing charges from bank fees, use the supported account in that chart and retain the mapping decision.

Do not credit revenue again at settlement when the invoices already credited revenue. Doing so doubles sales. Conversely, if the business records sales only from a gateway report, a compressed entry of Dr Bank, Dr fee expense, Cr Sales Revenue may be appropriate only when it cannot duplicate invoice-level revenue. Document which event recognises revenue before posting either version.

Why does one FPX gateway deposit cover many invoices?

FPX is the payment rail, while an acquiring bank, exchange, or third-party gateway may control merchant reporting. Individual customer transactions may therefore appear as an aggregated merchant payout.

That produces a one-to-many reconciliation chain:

one bank credit
        ↓
one gateway settlement or payout batch
        ↓
many FPX transactions
        ↓
many orders or invoices

The bank statement proves cash arrived but usually cannot identify every invoice, refund, and fee. A working schedule should therefore retain a batch or payout reference, gateway and merchant order references, invoice number, reported status, relevant dates, gross amount, deductions, net amount, currency, bank destination, and source filename. These are internal reconciliation fields, not claimed FPX export headers. Preserve the native report so a reviewer can reproduce the schedule.

How should an FPX batch be reconciled step by step?

1. Freeze the source evidence

Export the transaction detail and settlement report for a defined account, currency, and period. Record filenames, filters, and export time so both files describe the same population.

2. Separate transaction success from payout completion

Keep transaction status, batch status, and bank evidence separate. A customer success notification alone does not prove that the expected amount reached the correct merchant account.

3. Group by a durable settlement identifier

Use the provider's payout or settlement identifier. If none is assigned, keep the transactions unsettled; amount and date alone are weak identifiers.

4. Prove gross collections

Sum the successful transaction rows assigned to the batch. Tie each merchant order reference to an invoice or explain why no invoice exists. Exclude failed, cancelled, or pending transactions according to the actual report status; do not invent status meanings that the provider has not documented.

5. Prove every deduction

Tie MDR, refunds, reversals, and adjustments to explicit evidence. Normalize signs once: either store fees as positive deductions or retain provider-signed negatives throughout. Mixing conventions can turn a RM50 fee into a RM100 variance.

6. Match the net payout to the bank

Compare the calculated net amount with the bank credit using currency, reference, bank destination, and timing. A timing difference can remain in transit. An amount difference must stay open until supported; never plug it to MDR merely because the variance looks small.

7. Post the gross-to-net accounting

Clear the gross receivable, recognize the supported fee, and debit the bank for actual cash. Link the journal or controlled posting step back to the batch schedule and bank line. Confirm that the receivable cleared equals the invoices in the batch, not merely the deposit.

8. Roll unresolved items forward

List transactions not yet assigned to a payout, payouts not yet in the bank, bank credits lacking a report, rejected or reversed transactions, and unexplained differences. Give each exception an owner and next evidence source rather than forcing it into a completed batch.

What does GetPay actually match?

GetPay's settlement matcher works on parsed bank statement lines with date, amount, ref, description, bank, and txn_type. It compares positively identified credit lines with open ISSUED or OVERDUE invoices. Each invoice projection includes invoice_id, invoice_number, customer_name, total, and outstanding.

The code uses the outstanding balance, not the invoice face value. A RM1,000 invoice with RM600 already recorded is therefore an amount match for a RM400 credit, not another RM1,000 credit. Fully paid invoices are removed as targets.

Proposals are produced in three descending evidence tiers:

Match tier	Code-grounded test	Score
exact_ref	Invoice number appears inside the bank ref or description, with digit-boundary protection	1.0
amount_party	Credit equals the invoice outstanding within half a cent and a distinctive customer-name token overlaps	0.7
amount_only	Credit equals the invoice outstanding within half a cent without party corroboration	0.4

Common banking words including FPX, TRANSFER, PAYMENT, and BANK are treated as noise for customer-name matching. Their presence cannot manufacture party evidence. Blank or unrecognised transaction directions are skipped rather than assumed to be incoming cash.

Most importantly, every match is propose-only. The matcher does not settle an invoice or post a ledger entry. That posture is especially important for gateway deposits, where a convenient amount match may hide fees, refunds, or several underlying invoices.

How does settlement confirmation protect the invoice balance?

GetPay's confirmation flow requires a candidate_id, positive expected_version, and non-empty adjudicated_by; an optional bank_account_id identifies the landing account. It refuses an unresolved or inter-entity landing account and checks the payment date against the accounting period lock.

Allocation then follows two rules:

• For one proposed invoice, the booked payment is capped at that invoice's outstanding balance. An oversized credit cannot create an overpayment through this path.
• For several proposed invoices, the sum of their outstanding balances must equal the credit within half a cent. If it does not, confirmation is refused as ambiguous.

Payments use GetPay's canonical invoice-payment route. Deterministic idempotency keys and candidate-state controls prevent an intentional second payment on retry.

These controls do not perform MDR accounting. If invoices total RM5,000 and the bank receives RM4,950, the amount tiers do not match the gross outstanding. An exact invoice reference could still produce a proposal for one invoice, but confirming RM4,950 would leave RM50 outstanding; it would not infer or post the fee. For a multi-invoice proposal, the unequal totals cause the allocation to be refused. Resolve the gross-to-net fee accounting before treating the batch as fully settled.

How should settlement delays be handled at month-end?

Track four dates independently:

Date	Accounting question
Customer payment date	When did the buyer complete the reported transaction?
Gateway settlement date	When was the transaction assigned to a merchant batch?
Payout date	When did the gateway or acquirer initiate or report the payout?
Bank value date	When did the merchant bank record the cash?

PayNet describes FPX as real-time payment processing, but a third-party arrangement can still introduce batch cut-offs, exceptions, refunds, non-business-day timing, or a separate payout schedule.

At period end, reconcile the unsettled balance:

Opening unsettled gateway receivable
+ gross successful collections recognized
− refunds and reversals recognized
− fees recognized
− gross value cleared by bank settlements
± supported adjustments
= closing unsettled gateway receivable

If a RM5,000 batch is finalized before month-end but RM4,950 arrives later, keep the supported settlement in transit and clear it when bank evidence arrives. A delayed deposit is a timing item; an unsupported difference is an exception.

Which FPX reconciliation exceptions should never be forced?

The deposit is lower than expected

Check the fee report, refunds, split payouts, reserves, currency, and whether the batch is final. Do not label the difference MDR without evidence.

Two deposits have the same amount

Use the batch reference, gateway account, bank reference, destination, and transaction population. Amount-only matching is lower-confidence evidence, not proof.

The bank description only says FPX

FPX identifies a rail or channel, not the payer or invoice. GetPay deliberately removes it from party-token evidence. Find the merchant order, settlement, or bank reference.

One net deposit covers several gross invoices

Do not reduce invoice balances to make them add to cash. Build the batch schedule, record the supported fee, and clear the gross receivables through a controlled accounting path.

The report shows success but no cash arrived

Keep the item in the unsettled queue. Check the payout destination, batch status, exception notices, and acquiring arrangement. Do not mark the invoice paid solely from a success screen if the accounting process requires bank settlement proof.

FPX payment gateway reconciliation checklist

• Freeze the gateway transaction and settlement reports for one defined population.
• Tie every successful merchant order reference to the relevant invoice or documented exception.
• Group transactions by a durable payout or settlement identifier.
• Prove gross collections before looking at the net bank amount.
• Prove MDR, refunds, reversals, and adjustments from actual report lines.
• Use the merchant's real fee agreement or report; never assume an MDR percentage.
• Match the calculated net payout to the correct bank credit and destination.
• Post Dr Bank + Dr supported fee expense / Cr gross Accounts Receivable when invoices were already recognized.
• Keep payment, settlement, payout, and bank value dates separate.
• Roll unsettled gateway balances across month-end with value-level evidence.
• Treat GetPay settlement matches as proposals until a named adjudicator confirms them.
• Do not claim GetPay infers MDR or imports a provider-specific FPX settlement report; the current grounded flow matches bank credits and confirms invoice payments.