Reconcile a Saudi store's mada and card settlements by matching in threes: orders to gateway transactions, transactions to settlements, and settlements to bank credits — with one clearing account per gateway in between. That structure turns month-end from a spreadsheet hunt into a routine. The bank deposit will never equal the day's sales, and it is not supposed to: a settlement is a batch total, net of fees, refunds and chargebacks, arriving on the gateway's clock rather than yours.
The short answer: reconcile in three matches — orders to settlements, settlements to bank, bank to ledger
Set up one clearing account per gateway. When an order is paid, its gross value enters clearing. When a settlement report lands, rebuild it from gross to net inside clearing: fees, refunds and chargebacks each as their own line. When the bank credit arrives, it should equal the settlement's net exactly — clear the two against each other. Whatever remains in clearing is either in transit or a variance with a name, an age and an owner. Run the matches in that order, at least monthly.
Why the bank deposit never equals the day's sales (batching, netting and three clocks)
Three different events get treated as one. The order is paid: the customer's mada or card payment is authorised and captured. The gateway settles: transactions are grouped into a batch, fees are deducted, refunds and chargebacks are netted off, and the remainder is paid out. The bank credits your account: the net batch appears as a single deposit. PayTabs' own documentation, for example, describes merchant-configured payout options — weekly, monthly or merchant-initiated: the payout cycle is a term of your agreement, never a universal mada rule.
Set up the bridge: one clearing account per gateway
Create a separate clearing account for each gateway, even if two run through the same platform, and post in a fixed order: gross in on payment, deductions out on settlement, net across to bank on payout. Blending gateways into one account hides which provider a variance belongs to; blending settlements straight into the bank account hides the fees entirely. It is a bookkeeping method, not a statutory format. Our guide to web development in Saudi Arabia covers the surrounding local context.
Match 1 — Orders to gateway transactions: the identifiers that must survive
Every paid order must be findable in the gateway's transaction report, and the field that survives the whole journey is the gateway's transaction reference — not your order number alone. Record it against the order at payment time. Match 1 then checks three things: every paid order has a gateway transaction, every gateway transaction belongs to an order, and the gross amounts agree. Exceptions are small: an authorised payment never captured, a duplicate transaction, an amount changed after a discount. Authorisation is not settlement — an authorised-but-unsettled payment is not received revenue, and declined checkouts never enter this match.
Match 2 — Transactions to settlements: rebuilding gross to net (fees, refunds, chargebacks)
Take each settlement report and rebuild it: every batch must satisfy this arithmetic:
| Settlement line | Treatment in the clearing account |
|---|---|
| Gross value of transactions in the batch | Already in clearing from Match 1 — agree it to the report |
| Gateway fees | Post out of clearing to a fees expense account, at your agreed rate |
| Refunds settled in this batch | Post out of clearing against the original sale (see below) |
| Chargebacks and adjustments | Post out of clearing to a chargebacks line, linked to the original |
| Net settlement | The remainder — the amount the bank should receive |
Post fees as their own expense line, always. A store that books only net deposits understates revenue and costs, and cannot spot a wrong fee rate. If the rebuilt net differs from the report's net, the difference is a variance — park it in the queue below with the batch reference, never force it into fees.
Match 3 — Settlements to bank credits, and the ZATCA invoice tension
Each net settlement should appear as one bank credit of the same amount. Tie every gateway credit on the bank statement to a settlement reference; a settlement past its expected payout date without a credit becomes a late variance. Now the Saudi complication. Your ZATCA e-invoice records the sale at its gross amount, because the invoice documents the sale, not the cash movement. The bank only ever sees the net. Neither is wrong; the clearing account is the bridge: gross in from the sale, deductions out at settlement, net across to the bank. Never adjust an invoice to match a deposit. For your store's e-invoicing requirements, follow ZATCA's official guidance, not a gateway's summary.
The variance queue: unmatched, late, short and duplicate — ageing and clearing each type
Every difference goes into one queue with four labels, an amount, a reference, and the date first seen. Unmatched: a transaction or credit with no partner — check identity first (wrong reference, wrong gateway account) before suspecting money. Late: a settlement past the payout timing in your agreement — escalate with the settlement reference. Short: a credit smaller than its settlement — usually an unposted deduction, such as a separately advised chargeback. Duplicate: the same batch counted twice — reverse one entry, never net it off silently. Age the queue weekly: items should clear within one settlement cycle; anything older gets a named owner and a written next step. A shrinking clearing balance is normal; a growing one is the escalation signal.
Refunds and chargebacks that land in a later batch than the sale
Refunds and chargebacks hurt most here, because the deduction almost always lands in a later batch than the original sale. Handle them by link, not by month. When a refund settles, post it out of the same gateway's clearing account against the original sale, keeping the refund record with the entry and following ZATCA's rules for the original transaction's documentation. A chargeback goes further: the gateway reverses money for a sale already recognised, so record it on its own line, linked to the original transaction, and track the dispute separately; if you win, the money returns in a future batch and clears the chargeback line. Never net a later deduction against a new, unrelated sale.
The monthly closing pack: what to hand your accountant or auditor
Close the month with a pack that lets someone else re-perform your work: the match report with exceptions; each settlement report with its gross-to-net rebuild; the bank statement with every gateway credit tied to a settlement reference; the clearing-account rollforward per gateway (opening balance, gross in, deductions out, payouts, closing balance explained); the variance queue with ages and owners; and the journal log. If your auditor can reach your ledger from the pack unaided, it is complete. File it monthly, not at year-end.
When the spreadsheet stops working: what to automate, and what to fix in the integration first
Spreadsheets carry this method until volume or a second gateway makes the exception queue the bottleneck. Automate in the order the matches run: consistent report imports, auto-matching on the gateway reference, an automatic rollforward. But fix the integration before automating around its defects. If settlements arrive with no usable reference, or one never appears because a notification between store and gateway failed, that is an integration fault, not a bookkeeping task — our companion guide to mada integration pitfalls covers the build-side causes. Stores that outgrow the manual method move to a consolidated view — our guide to one dashboard for ZATCA invoices, mada settlements and inventory — with the same clearing logic underneath.
Common mistakes
Booking deposits as sales. One clearing account for every gateway, so variances cannot be attributed. Forcing clearing to zero with a plug entry. Treating authorisation as settlement. Adjusting a ZATCA invoice to match a net deposit. Netting a chargeback against a new sale. Reconciling only at year-end, when the evidence no longer exists. Stating a settlement cycle as a mada rule when it is only your agreement.
FAQ
How long does mada settlement take to reach my bank account?
There is no single mada settlement clock. Timing is set by your gateway and merchant agreement — PayTabs' own documentation, for instance, describes merchant-configured payout options such as weekly, monthly or merchant-initiated payouts. Record your cycle beside the gateway's clearing account, and judge lateness against it.
Should I record sales gross or net of gateway fees?
Gross. Record the full order value as the sale, and post the gateway's fee as its own expense line at settlement. Booking only the net deposit understates revenue, hides what the gateway charges you, and makes fee errors invisible. The clearing account holds the gross until deductions are known.
How do I reconcile payouts from Salla or Zid with my accounting software?
The same three matches. Treat the platform's payout report as the settlement document: agree its transactions to your orders, rebuild it from gross to net with fees, refunds and chargebacks as separate lines, then tie the net to the bank credit. Keep one clearing account per settling party, and the gateway reference on every order.
What do I do when a settlement never arrives?
Work the variance queue. Confirm the batch exists in the gateway dashboard, check it against the payout timing in your agreement, and escalate with the settlement reference. If the money moved but the report feed failed, that is an integration defect to fix at the build layer — never plug the gap with a journal entry.
Why does my ZATCA invoice total not match the bank deposit?
They record different events. The invoice documents the sale at its gross amount; the deposit is a later batch net of fees, refunds and chargebacks. The difference should be fully explained inside the clearing account by the gross-to-net rebuild. If it is not, the remainder is a variance to investigate — not a reason to change the invoice.
Get the settlement feed built into your store properly (CTA)
If your variances keep tracing back to missing references or broken settlement feeds, the fix is in the integration, not a bigger spreadsheet. WebStackRank builds and repairs store integrations through our ecommerce web development service, including the custom connections in our custom web application development work for stores across Saudi Arabia — see also our ecommerce website development in Dubai page. Tell us your gateways, platform and where the trail breaks, and we will scope the build fix.
