Bank Statement Converter for Saudi Arabia: Al Rajhi, SNB, Riyad Bank and More

If you keep the books for a Saudi business, you already know the routine. The client sends a month of statements as PDFs, and someone in the office spends the next hour retyping rows into a spreadsheet — or worse, pasting them and then untangling the mess that arrives.

The task itself is trivial. The friction is entirely in the format. A bank statement is a table that has been flattened into a document designed for printing, and getting it back into a usable grid is where the afternoon goes.

This guide covers what actually matters when you convert Saudi bank statements: which banks work, how Arabic-Indic numerals are handled, what to keep for ZATCA purposes, and how to check that the numbers you got out are the numbers that were in.

The Saudi banks people convert most

Saudi statements are not uniform. Column order, date formats, the placement of the running balance, and the treatment of Islamic-finance terminology all vary between institutions — and sometimes between account types at the same institution.

Here is how the main banks tend to differ in practice:

Bank	What to watch in the PDF
Al Rajhi Bank	Bilingual layout; Murabaha and other Islamic-finance descriptions often run to two lines
Saudi National Bank (SNB)	Wide layout with value date and posting date as separate columns
Riyad Bank	Running balance column placement varies between personal and corporate formats
Banque Saudi Fransi (BSF)	Mixed Arabic/English descriptions in the same narration field
Alinma Bank	Compact spacing; long reference numbers can wrap and split a row
Saudi Awwal Bank (SAB)	Corporate exports differ noticeably from retail statements
Bank Albilad	Bilingual headers, with Arabic-Indic digits appearing in some exports

Be clear about what is tuned and what is auto-detected. BayanSheet ships hand-tuned templates for four UAE banks only: Emirates NBD, FAB, ADCB and Dubai Islamic Bank.

For every Saudi bank in the table above, the engine auto-detects the statement layout. It reads the structure from the document itself instead of applying a fixed template — and the balance check runs either way, so you always see whether the extraction reconciles.

That distinction matters. A converter that quietly claims support for a hundred banks is usually applying the same generic logic to all of them. What you actually want to know is whether the output adds up, which brings us to the check.

The balance check: the part that makes it usable

Extraction is the easy half. Verification is what turns a pile of rows into something you can put in front of a client.

After parsing a statement, BayanSheet takes the opening balance, adds every credit, subtracts every debit, and confirms the result equals the closing balance printed on the PDF. If it does not match, the rows that break the chain are flagged.

Why this matters more than extraction accuracy claims: the dangerous failure in statement conversion is never the obvious one. A missing row, a decimal read one place off, or a debit posted as a credit does not announce itself. It surfaces three weeks later as a reconciliation that will not close, and you lose an afternoon finding it.

A converter that verifies the arithmetic tells you before the data reaches your ledger. One that just hands you rows has moved the checking work to you.

Arabic-Indic numerals — the failure most tools never mention

Saudi statements frequently use Arabic-Indic digits (٠١٢٣٤٥٦٧٨٩) for amounts, dates, or account references, sometimes mixed with Western digits in the same document.

Generic converters built and tested on US and UK statements do one of two things with these characters:

• Return them as text strings, so ١٢٣٤.٥٠ lands in Excel as a left-aligned label that will not sum.
• Drop or garble them entirely, leaving blank cells where amounts should be.

Either outcome forces a manual pass over the whole sheet, which defeats the purpose of converting.

BayanSheet maps Arabic-Indic digits to their numeric values during parsing, so amounts arrive as real numbers. A quick way to test any converter: convert one page and check whether the amount column right-aligns by default. Numbers right-align. Text does not.

The same applies to date formats. Saudi statements may show Gregorian dates, Hijri dates, or both. Check that the date column parsed into a date type rather than a string before you build anything on top of it.

ZATCA, VAT and what you actually need to keep

Saudi Arabia has a VAT regime administered by ZATCA, alongside the phased e-invoicing (Fatoora) requirements. Both rest on the same practical foundation: businesses must be able to produce records that support the figures they filed.

Bank statements are supporting evidence in that chain. They are how you prove that a recorded receipt actually landed and a recorded payment actually left.

Keep the original PDF. The statement issued by your bank is the authoritative record, and it is the one you retain for the statutory period.

The Excel file is your working copy. It is what you reconcile, categorise, tag with VAT treatment, and import into your accounting system. Converting does not replace the bank's document — it saves you from retyping it.

This distinction resolves a question we get often: why convert at all if the PDF is the record? Because the PDF is a record, not a workspace. You cannot filter it, sort it, run a formula across it, or push it into your accounting software. The conversion produces the working layer; the PDF stays exactly where it was.

If you want the VAT-specific detail, we wrote it up separately in bank statement to Excel for Saudi VAT and ZATCA.

The workflow, start to finish

Four steps, and none of them involve uploading anything.

1. Download the original PDF from online banking. Not a screenshot, not a scan, not a forwarded photo. Every Saudi bank's portal and app lets you export a statement PDF directly, and that file carries a text layer that produces dramatically better extraction than an image.

2. Open the converter and drop the file in. Processing happens inside your browser. The PDF is not transmitted anywhere. If the statement is password-protected — common with statements emailed by the bank — you will need the password, usually a combination of ID and date of birth. There is a guide to password-protected statements if you get stuck.

3. Read the balance-check result before anything else. If it reconciles, the arithmetic is sound. If it flags rows, look at those rows in the PDF first — often it is a multi-line description or an unusual fee entry, and it takes seconds to resolve once you know where to look.

4. Export to Excel or CSV and import it. From there it goes into your accounting software the same way any transaction file does. We cover the mapping step in importing bank statements into accounting software.

Prove it rather than trusting it

You should not take a privacy claim on faith, including ours.

The offline test: turn off your Wi-Fi and convert a statement.

A tool that processes in your browser keeps working, because nothing needs to be sent. A tool that uploads to a server fails or hangs, because it cannot reach its backend. There is no way to fake the result.

That single test answers the question that matters most when the file in front of you is a client's complete financial history. We published the full set of checks in how to verify a bank statement converter — they are the same tests we built BayanSheet to pass.

Getting started

Ten pages are free, with no card required. Drop a real Al Rajhi, SNB or Riyad Bank statement in and check the output against the PDF yourself — the balance check will tell you within seconds whether the extraction held.

Convert a Saudi bank statement now, or browse the rest of the BayanSheet blog for the accounting-workflow guides.