Bank reconciliation automation, including the payouts that never match
Bank reconciliation stopped being about the bank a while ago. For a Saudi company taking card and instalment payments, most of the unmatched value is not in the bank statement at all, it is in the gap between a payout and the orders it covers. Automating the easy half and leaving that gap is why so many reconciliations are technically complete and practically useless.
Three kinds of match, in order of confidence
The first is an exact reference match: an invoice number in the narration, a payout identifier in the settlement report. It is right or it is not, and there is no judgement involved. The second is amount and date within a tolerance, which is reliable for a single payment against a single invoice and unreliable the moment two invoices share a value.
The third is fee arithmetic, and it is the one that matters here. A payout of SAR 41,318.40 covering eight orders with SAR 2,175.60 of processor fees is a solvable equation, and solving it produces eight matched orders and one fee entry rather than one unexplained deposit.
- Exact reference: highest confidence, no judgement
- Amount and date: reliable until two amounts collide
- Fee arithmetic: how a lump payout is broken into its orders
- Batch sum: for payroll and bulk transfers
What Saudi payment providers actually give you
Moyasar publishes a settlements API with settlement lines, which is the good case: the breakdown arrives as data. Tap offers a payout webhook and a download endpoint. Tabby and Tamara are dashboard exports only, with no settlement API at all, which means a CSV upload has to be a first-class input rather than a workaround bolted on later.
Being honest about that difference matters when choosing a service. Any tool that promises the same automation across all four is either doing manual work behind the scenes or is not doing it at all.
The lines that do not match
A residual of zero is the bar for an approved match. Anything else is either explained or it is an exception, and exceptions become one short question to the owner rather than a guess. A transfer with no invoice, a receipt with no reference, a refund that arrived before the sale it reverses.
Until an answer comes back the amount sits in suspense, visible, with the date it was first asked. That is what stops a reconciliation quietly absorbing the things it could not explain.
Bank data, and the licence question
Open banking in Saudi Arabia has been a full licence regime under the regulator since March 2026, with no sandbox route. ProCul is not licensed for account information services and does not present itself as connected to your bank. Statement data reaches the ledger because you provide it, as a file, or from your accounting system where it is already collecting the same lines.
This is a real constraint rather than a soft one, and it is better stated on a page like this than discovered during onboarding.
Common questions
- Can you pull my bank transactions automatically?
- No. That requires a regulated account information licence which ProCul does not hold. Statements are provided by you, or read from your accounting system where it is already collecting them.
- How are Tabby and Tamara handled?
- Through their dashboard exports. Neither offers a settlement API, so the export is uploaded and the payout is broken into orders and fees from that.
- What counts as a completed reconciliation?
- Every account tied out with a residual of zero, and every difference either explained in writing or held as an open question. Both states appear on the reconciliation report.
- How long does a backlog take to clear?
- It depends on volume and on how much source documentation exists. The health check gives a count and a price before any commitment.
Start with a free books health check
One read of your ledger, findings counted and priced, yours to keep. About ten minutes of your time.
Last reviewed: