Why Odoo's Standard Bank Matching Fails on Saudi mada Settlements (And How to Fix It)

Saudi shoppers ran 267.75 million point-of-sale transactions in the week ending 5 September 2026, according to Saudi Central Bank data. Not one of them reaches your Odoo ledger in the shape Odoo is built to read.

Odoo's bank reconciliation is designed to match one incoming payment against one invoice. A mada settlement arrives as the opposite shape. It is a single deposit covering hundreds of card sales, already reduced by the acquirer's merchant service charge and by the VAT charged on that fee. The numbers cannot line up, so the matcher stays silent.

Most finance teams read that silence as an Odoo configuration problem. It is a shape problem, and the fix has to start there.

What actually lands in your bank account when a mada settlement clears

One deposit, covering a batch of sales, reduced before it arrives. Your acquiring bank collects the day's approved transactions, deducts its merchant service charge as a percentage of the batch value, and transfers what remains. The deposit that hits your statement is a net figure that matches no invoice, no sales order, and no POS session total.

This is not a quirk of any particular bank. ZATCA describes the same sequence in its own tax circular on financial services: the retailer stores approved sales in one batch and sends that batch to the acquirer at the end of the day to receive payment, and at that point a percentage of the transaction value is deducted by the acquirer as compensation for its services.

What that percentage is depends on who you are contracted with, and the distinction matters more than most teams realise.

If your money runs through an acquiring bank on a mada-POS agreement, mada's own published fee rules cap the merchant service charge at 0.80% of purchase value per transaction, with a ceiling of SAR 40 on any single transaction. If your money runs through a payment gateway, you are on that gateway's commercial rate card instead, and published gateway pricing for mada sits higher than the acquirer cap.

Two merchants on the same street, same sales, same Odoo version, will see two different deduction patterns. Any reconciliation logic that assumes a fixed percentage is already wrong for one of them.

Why Odoo's matcher goes quiet on a settlement line

Odoo pre-selects a counterpart when it can find one, working through the partner on the transaction, then the payment reference, then the amount. A mada settlement line usually carries none of the three in a usable form. No partner name the bank recognises, no invoice reference in the label, and an amount that equals nothing in your books.

Walk the three in order and you can see exactly where each one dies.

Partner. Odoo looks for a customer it recognises, from the transaction details, the counterparty bank account, or a partner name it has matched before. Your settlement comes from your own acquiring bank, not from the 412 people who tapped their cards. Point-of-sale receivable entries carry no partner at all. There is nothing for Odoo to latch onto.

Reference. Odoo looks for a payment reference or invoice number inside the statement line label. The bank writes its own settlement reference there, generated by the acquirer and meaningless to your ledger. It is stable enough that you will see the same format every day, and useless for identifying which sales it covers.

Amount. Odoo matches when the statement line equals the total amount due on an open invoice. A net settlement equals the sum of many invoices minus a fee minus VAT on that fee. It equals nothing.

This is not a complaint unique to Saudi Arabia. Search the Odoo community forum and you will find the same question asked repeatedly across markets: how do you auto-match point-of-sale receivable journals against a bank statement when the amounts do not match, because the bank has deducted service charges and taxes, and the POS journals carry no partner. On a thread about batch card settlements, the community answer is blunt. There is no easy way to automate it, because the bank's reference is not predictable in advance and the amounts will not match.

Thousands of finance teams have hit this wall and worked around it by hand.

The tolerance band that makes it worse, not better

Odoo can absorb a small gap between a payment and an invoice, which is how card fees are normally handled elsewhere. That tolerance is built for one payment landing slightly short of one invoice. It does nothing for an aggregated batch, and where it does fire, it can quietly attach the wrong invoice.

Consider what the tolerance is being asked to absorb.

A merchant service charge capped in absolute terms does not behave like a percentage. On a SAR 300 sale at 0.80%, the fee is SAR 2.40. On a SAR 12,000 sale, the 0.80% calculation gives SAR 96, but the SAR 40 ceiling caps it, so the effective rate drops to 0.33%. The deduction rate moves with your basket size, which means it moves with your Thursday evening trade, your Ramadan trade, and your end-of-month salary-week trade.

A fixed tolerance band cannot track that. Set it tight and it never fires. Set it loose and it starts matching a statement line to whichever open invoice happens to sit within range.

A silent wrong match is the expensive outcome here. An unmatched line is visible, sits in your reconciliation queue, and annoys someone into fixing it. A wrongly matched line closes an invoice that was never paid, leaves a real payment unallocated somewhere else, and surfaces months later during an audit as an aged receivable nobody can explain.

The VAT mistake hiding inside "write it off to bank charges"

The gap between your gross sales and your net deposit is two separate amounts, not one. It is the merchant service charge, and it is 15% VAT charged on that fee. Posting the whole difference to a single bank charges account buries recoverable input tax inside an expense line and understates the input VAT on your return.

This is the part that costs real money, and it is close to invisible.

Financial services in Saudi Arabia are treated one of two ways. Where the bank earns through an implicit margin or spread, the service is exempt. Where the bank charges an explicit fee, commission, or commercial discount, the service is standard-rated at 15%. A merchant service charge is an explicit fee.

ZATCA addresses this directly. In its circular on the financial services industry, it states that an acquirer bank charges fees known as a merchant fee to merchants for use of the electronic point of sale facilities, and that where the merchant is in the same country as the acquirer bank, these services are subject to VAT at the standard rate.

So the shortfall on your settlement decomposes into three things, and only one of them is an expense.

Here is the arithmetic on a worked example. This is a calculation from published rates, not a figure from any merchant's books.

Take a store running SAR 200,000 of mada sales in a month, across roughly 1,400 transactions averaging SAR 143, on a bank acquirer agreement at the 0.80% cap. No single ticket comes near the SAR 40 ceiling, so the full rate applies.

That SAR 240 is deductible input tax, provided you hold a valid tax invoice from your acquirer. Post it to bank charges and you have handed it back. Scale the same store to SAR 2 million a month and the same mistake is SAR 2,400 a month sitting in the wrong account, every month, unnoticed, because the bank statement never showed you the split in the first place.

Ask your acquirer for the monthly tax invoice on merchant fees. Most will issue one. Most merchants never request it.

Seeing this pattern in your own ledger? Greenloom decomposes every settlement deduction into its named parts before anything posts to your books, so the fee and the VAT on the fee land in separate accounts. Book a demo and bring one month of settlement data.

Why your ZATCA e-invoice number does not rescue the match

Every compliant e-invoice in Saudi Arabia carries a unique identifier. That identifier is never typed into a bank transfer or written into a settlement line. The strongest reference in the Saudi finance stack is absent from precisely the place where reconciliation needs it.

Teams new to the Kingdom's e-invoicing regime often assume this solves matching. The invoice is structured, signed, and uniquely identified, so surely the trail is unbroken.

The trail breaks at the bank. Your invoice identifier lives in the e-invoicing stream. Your settlement reference lives in the banking stream. Nothing connects them, because the two systems were built for different regulators and different purposes.

]Which means matching has to happen on shared attributes instead: the batch date, the terminal or gateway, the value before deductions, and the expected fee given the rate card you actually signed. That is a reconstruction problem, not a lookup.

How to fix it inside standard Odoo

Stop asking Odoo to match a settlement to invoices directly. Route card receipts through an intermediary account at gross, group them into a batch that mirrors the settlement, then reconcile the bank line against that batch plus two explicit fee lines. It works, and it is entirely manual to maintain.

Six steps, in order.

1. Create an intermediary account per acquirer or gateway. Something like "mada settlement clearing". Card receipts land here first, not in the bank account. If you accept through more than one provider, create one per provider, because their rate cards differ.
2. Post card receipts at gross. The full amount the customer paid, matching the e-invoice, with nothing netted off. This keeps your revenue and output VAT correct regardless of what the bank does later.
3. Group each settlement period into a batch payment. Odoo's batch payments feature lets you group the transactions that will arrive as one deposit, so there is a single object for the bank line to match against.
4. Build a reconciliation model with two counterpart lines, not one. One line to the merchant fee expense account. A second line to recoverable input VAT. This is the step almost every setup skips, and it is the one that protects your VAT return.
5. Request the monthly tax invoice from your acquirer or gateway. Without it, the input VAT line in step 4 is not supportable if ZATCA asks.
6. Reconcile the bank line against the batch plus the two fee lines. The three now sum to the deposit.

Done properly, this handles a clean day cleanly.

Where that fix still breaks

The clearing account approach assumes every settlement is a tidy batch of successful sales. Refunds, chargebacks, split payouts, and settlements that straddle month end all break the arithmetic, and each one drops back into somebody's inbox as a manual exception.

The failures cluster in five places.

Refunds netted into the settlement. A refund processed today reduces today's deposit. Your batch total no longer equals your sales total, and the difference is not a fee.

Chargebacks arriving without warning. A disputed transaction is clawed back weeks after the original sale, inside an unrelated settlement, with no reference to the sale it reverses.

A payout split across two deposits. One day's trade arrives as two bank lines. Your batch matches neither.

Settlements crossing the period boundary. Sales recognised on 30 September settle in October. Your revenue sits in one period and the cash in the next, which is correct, and which also means your clearing account carries a balance at month end that somebody has to explain and prove.

Rate card drift. The deposit tells you what you received. It does not tell you whether the deduction matched the rate you negotiated. Unless someone recalculates the expected fee against the contract, an overcharge of a few basis points is undetectable and runs indefinitely.

Every one of these is solvable by a person with a spreadsheet and enough time. The question is whether that person exists on your team every day, or only in the week before the close.

What reconciliation built for Saudi settlement does differently

Greenloom works on the settlement batch rather than the statement line, and treats the deduction as something to be explained rather than absorbed. Each proposed match is recalculated arithmetically before it can post, and anything that does not resolve is held in an exception queue for a human decision rather than written off.

Four behaviours, described at the level of what the software actually does.

It reconstructs the batch. Instead of hunting for an invoice that equals the deposit, it works from the expected composition of the settlement: the transactions in the period, the provider, the contracted rate, and the resulting net.

It names every deduction separately. A settlement that lands short gets decomposed into its components, so the merchant fee, the VAT on that fee, and anything else are each identified rather than collapsed into one write-off line.

It verifies its own arithmetic before anything posts. A match proposed by the agent is recomputed independently and has to agree before it can move forward. A model that is confident and wrong is worse than a model that stops, so the numeric check sits between the proposal and the ledger.

It holds what it cannot resolve. A settlement two days late, a duplicate reference, a payout split across two batches, or a fee that sits outside the agreed rate card goes to a queue with the reason attached. Nothing posts on a guess, and there is a timestamped trail of what matched, what waited, and why.

None of this removes the finance team from the process. It changes what they spend the morning on, from finding the mismatches to deciding about them.

Frequently asked questions

Why does my Odoo bank statement never match my POS totals in Saudi Arabia? Because the two figures measure different things. Your POS total is gross sales at the till. Your bank deposit is a net settlement after the acquirer deducts its merchant service charge and the VAT on that charge, aggregated across a whole batch of transactions. The two will never be equal, and Odoo's standard matching has no rule that reconstructs the difference automatically.

What is the maximum mada fee an acquiring bank can charge me? Under mada's published merchant fee rules, acquiring banks may levy up to 0.80% of the purchase value per transaction, subject to a merchant service charge ceiling of SAR 40 on a single transaction. That cap applies to bank acquirer agreements. If you accept payments through a payment gateway rather than a bank acquirer, you are on that provider's commercial rate card, which is typically higher.

Is VAT charged on merchant service fees in Saudi Arabia? Yes. Saudi VAT treats financial services earned through an explicit fee, commission, or commercial discount as standard-rated at 15%, while services earned through an implicit margin are exempt. A merchant service charge is an explicit fee. ZATCA's circular on the financial services industry confirms that an acquirer bank's merchant fee to a merchant in the same country is subject to VAT at the standard rate.

Can I claim back the VAT on my card processing fees? If you are VAT registered and the fee relates to your taxable business activity, the VAT on merchant service charges is recoverable input tax, provided you hold a valid tax invoice from the acquirer or gateway. Most merchants never request that invoice, because the deduction appears only as a shortfall on a bank statement rather than as a bill.

Should I use a suspense account for card settlements in Odoo? An intermediary clearing account per payment provider works better than a suspense account. Card receipts post there at gross, the settlement clears it, and the running balance tells you what has been sold but not yet paid out. A suspense account collects unexplained items from every source and tends to grow quietly until year end.

Does the same problem affect Visa and Mastercard settlements in Saudi Arabia? Yes, and the deduction is usually larger. International card schemes carry higher interchange and processing costs than mada, so the gap between gross sales and net deposit widens. The structural issue is identical: one aggregated deposit, net of fees, against many individual sales.

How long do mada settlements take to reach my account? Settlement timing is set by your agreement with your acquirer or gateway, and providers publish different terms. Some offer next business day for local card transactions, others settle over two or three business days, and longer settlement windows are sometimes traded against lower processing rates. Check your own merchant agreement rather than assuming a market standard.

What happens to my books if a settlement lands after month end? The sale belongs in the month it occurred and the cash belongs in the month it arrived, which is correct accounting and leaves a balance sitting in your clearing account at the period boundary. That balance needs to be supported by a list of settlements in transit. Auditors ask about it, and a clearing account nobody reconciles is one of the more common findings

Sources

1. Saudi Central Bank, weekly point-of-sale transaction statistics: SAMA POS statistics
2. mada, published merchant fee rules and merchant service charge cap: mada merchant fee FAQs
3. Zakat, Tax and Customs Authority, Tax Circular on the VAT treatment of certain supplies in the financial services industry: ZATCA circular (PDF)
4. Odoo, bank reconciliation documentation: Odoo 19 bank reconciliation
5. Odoo, batch payments documentation: Odoo 19 batch payments

Ready to see this on your own data? Bring one month of settlement files and one month of Odoo exports. We will show you, line by line, where the fee sits, where the VAT sits, and which transactions your current setup has been quietly writing off. Book a demo.