Most ERP vendors selling into Saudi Arabia will tell you they "support Arabic". In practice that ranges from a fully mirrored right-to-left interface with Arabic tax invoices and Hijri dates, all the way down to a machine-translated menu bar bolted onto a left-to-right product. The difference shows up on day one of go-live, when your accountant cannot read a printed invoice and your sales team quietly switches everything back to English. This guide gives you the specific things to check, and a demo test script you can run with your own data before you sign anything.

A translated menu is not an Arabic ERP

Translation is the cheapest layer of localisation and the easiest to demo. A vendor can ship an Arabic language pack in a sprint: the menus, buttons and field labels get Arabic strings, the salesperson toggles the language in the demo, and it looks convincing for the ten minutes you are watching.

What that layer does not touch is everything underneath it. Layout direction, the way numbers and Arabic text sit together on a printed document, date systems, name and address handling, search behaviour, PDF font rendering, email and SMS templates, and the language your support team actually replies in. Those are architectural and process decisions, not string files.

A useful mental test: ask which parts of the product were designed with Arabic in mind versus which parts had Arabic added later. Then ask to see the parts that were added later — reports, printed documents, dashboards and any recently shipped module are where the seams usually show.

Full RTL layout versus RTL bolted on

In a genuinely right-to-left interface the whole layout mirrors. Navigation moves to the right, table columns read right to left, icons that imply direction (back, next, indent, trend arrows) flip, form labels and their inputs stay aligned, and modal buttons sit in the mirrored order. Nothing overlaps and nothing gets clipped.

In a bolted-on implementation the text becomes Arabic but the skeleton stays left-to-right. You will see Arabic labels in left-aligned columns, sidebars stuck on the left, numeric columns that drift, tooltips that run off the edge of the screen, and charts whose axis labels collide. Individually these are cosmetic. Collectively they are the reason staff abandon the Arabic interface.

Check the layout mirrors, not just the words
Check data tables, not just the dashboard — grids are where RTL breaks
Check drill-downs, filters, date pickers and multi-select controls
Check the mobile or responsive view separately; it is often a different codebase path
Check mixed content: an Arabic sentence containing an English product code, a SAR amount and a VAT number
Check charts and reports, where labels are frequently rendered as images or by a separate engine

Arabic tax invoices, ZATCA and printed documents

The printed and PDF output is where Arabic localisation matters most, because it leaves your building. Under Saudi VAT rules the tax invoice must be issued in Arabic; you can also present another language alongside it, which is why most Saudi businesses print bilingual documents. Under ZATCA Phase 2 the invoice also carries structured XML, a cryptographic stamp and a QR code, and moves through either clearance for standard B2B invoices or reporting for simplified B2C invoices.

So there are two separate questions to ask, and vendors often answer only one. First, is the system integrated with ZATCA Phase 2 correctly, with the right flow for standard versus simplified invoices? Second, is the human-readable document itself properly Arabic — correct Arabic legal terms, correct field names, a layout that does not break when the customer name is long, and an embedded Arabic font so it renders on any machine.

Ask to see a real generated PDF, not a slide. Then open it on a different computer. Arabic PDFs that were built without embedded fonts, or that were assembled by a left-to-right templating engine, tend to show reversed letters, disconnected characters, or empty boxes only once they leave the demo laptop.

Arabic tax invoice with correct VAT wording and both VAT registration numbers
Bilingual Arabic and English on the same document, cleanly laid out
QR code and ZATCA compliance for both standard and simplified invoices
Credit notes and debit notes in Arabic, not just invoices
Purchase orders, quotations, delivery notes, statements of account in Arabic
Payslips in Arabic, since these go to every employee
Arabic column headers in exported Excel and PDF reports
Correct handling of long Arabic company names without truncation

Hijri dates, numbers and currency

Saudi operations run on both calendars. Contracts, iqama and licence expiries, and many government interactions reference Hijri dates, while your financial year and most commercial reporting run on Gregorian. An ERP that only stores Gregorian forces staff into manual conversion, which is exactly where expiry-date mistakes happen.

What good looks like: dates can be entered and displayed in either calendar, the conversion is done by the system rather than a spreadsheet, and reports can be run on either basis where that makes sense. Employee document expiry, contract terms and leave policies are the usual places this bites.

Numbers deserve a check too. Decide whether you want Arabic-Indic digits or Western digits in Arabic documents, and confirm the system does it consistently. Confirm SAR formatting, the symbol used, decimal handling, and that amounts in words can be generated in Arabic for cheques and formal documents.

Hijri and Gregorian entry and display, with system-side conversion
Hijri-aware alerts for iqama, contract and licence expiry
Consistent digit style across screen, PDF and export
SAR formatting and amount-in-words in Arabic
Correct alignment of numbers inside RTL tables and totals blocks

Arabic names, addresses and search

Arabic data entry has properties that trip up systems designed elsewhere. Names are commonly stored in both scripts, and the two must stay linked — one customer, one record, two renderings. Employees typically need an Arabic legal name matching their iqama or national ID for payroll, WPS files and GOSI, plus an English name for correspondence and banking.

Search is the quiet killer. Arabic has variants that users type interchangeably: alef forms, taa marbuta versus haa, final yaa versus alef maqsura, and optional diacritics. If the search index treats these as different characters, staff searching for a customer will get no results and will create a duplicate record instead. Within a year your customer master is full of near-duplicates and your reporting is unreliable.

Addresses matter for compliance too, since ZATCA-compliant invoices reference the Saudi national address structure. Confirm the system stores building number, street, district, city, postal code and additional number as discrete fields rather than a free-text blob, and that it can print them in Arabic.

Arabic and English name fields on customers, suppliers and employees
Search that normalises alef, taa marbuta, yaa and diacritics
Partial-word and middle-of-name search in Arabic
Sorting Arabic lists in a sensible order
Saudi national address as structured fields
Arabic text in notes, descriptions, item names and email subject lines without encoding damage

Arabic customer communications, support and training

Everything the system sends on your behalf is part of localisation: invoice emails, payment reminders, quotation covering notes, SMS notifications, portal screens and WhatsApp-style messages if you use them. If those templates are English-only, you have an English system that happens to have an Arabic screen. Check that templates are editable in Arabic by your own team, without a support ticket to the vendor.

Then check the human layer, which no feature list will tell you. Can you raise a support ticket in Arabic and get a competent Arabic reply, or does Arabic support mean a translation round-trip and a slower response? Is end-user training delivered in Arabic for warehouse, HR and finance staff who may not work in English? Is the user documentation Arabic, or an English PDF with an Arabic cover page?

Ask about implementation staffing specifically. The consultant who configures your chart of accounts, VAT treatment and payroll needs to understand both the system and the Saudi regulatory context: WPS file formats, GOSI contributions, Qiwa and Mudad processes, end-of-service calculation and Saudization reporting. Arabic fluency without that domain knowledge, or the reverse, both cost you time.

Also ask where the support sits in time. A vendor supporting you from a very different timezone with a Sunday-to-Thursday mismatch will feel slow regardless of language.

A demo test script you can run with your own data

Do not accept a scripted demo. Send the vendor a small pack of your own data in advance — five customers with real Arabic names, five inventory items with Arabic descriptions, one long Arabic company name, and one employee record — and ask them to run this sequence live in the Arabic interface while you watch. Time-box it to about 30 minutes.

Watch for hesitation as much as failure. If the consultant switches to English to complete a step, that step is not really localised.

Switch the whole system to Arabic and keep it there for the entire demo
Create a customer with an Arabic name, Arabic national address and a long trading name
Search for that customer using a different alef form and a partial word
Create a sales quotation with Arabic item descriptions and convert it to an invoice
Generate the ZATCA-compliant tax invoice, view the PDF, and email it to your own address
Open that PDF on your phone and on a second computer, and check the Arabic renders
Issue a credit note against the invoice and print it in Arabic
Run an aged receivables report and a VAT return report in Arabic, then export both to Excel
Enter an employee with an Arabic legal name and a Hijri iqama expiry date, and show the expiry alert
Produce an Arabic payslip and show the WPS payroll file output
Open the system on a phone in Arabic and complete an approval
Ask them to change an Arabic email template in front of you
Ask them to raise a support ticket in Arabic during the call and show you the reply channel

Where this fits in the wider ERP decision

Arabic and RTL quality is one criterion among several, and it should not be scored in isolation. A system with beautiful Arabic and weak inventory costing is still the wrong system for a distributor. The practical approach is to weight localisation against functional fit, total cost over three to five years, implementation risk and time to go live, ZATCA and payroll compliance depth, data residency, and how easily the platform will still fit you in three years.

How the major options tend to sit: SAP and Oracle have mature Arabic and RTL capability and deep functionality, and are a strong fit for large or complex enterprises with the budget and internal capacity to run a substantial implementation. Microsoft Dynamics 365 sits in a similar bracket with strong localisation typically delivered through regional partners, so partner quality matters as much as the product. Odoo and ERPNext are flexible and cost-effective, with Arabic and ZATCA support that is often partner-built or community-built — verify the specific localisation modules and who maintains them rather than assuming the core product covers it. Local Saudi accounting SaaS products are usually excellent on Arabic and ZATCA basics and very quick to start, but can run out of room once you need multi-warehouse operations, projects, manufacturing or complex approvals.

IntellaQ Flow is built Arabic-first rather than Arabic-translated: RTL layouts, bilingual documents, Hijri and Gregorian, ZATCA Phase 2, WPS payroll and GOSI handling, and in-Kingdom hosting, with sales, finance, inventory, procurement, HR and projects on one core plus the FlowAI agent. That combination fits Saudi SMBs and mid-market companies who want the localisation done properly without a multi-year enterprise programme. It is deliberately not the answer for a global group with heavy manufacturing and dozens of legal entities.

For the full side-by-side comparison — where each of these fits, what drives cost, and how to shortlist — read our buyer's guide, Best ERP and CRM Systems for Saudi Businesses (2026). This article is the deep dive on one of its scoring criteria.

The short version

Ask which parts were designed for Arabic and which were translated later, then inspect the later parts
Judge RTL on data tables, reports and mobile, never on the marketing dashboard
Insist on seeing a real Arabic tax invoice PDF opened outside the demo machine
Confirm Hijri support where expiry dates and contracts live, not just as a display toggle
Test Arabic search with spelling variants before you trust the customer master
Treat Arabic support, training and documentation as product features, and get them in writing
Score localisation alongside functional fit, cost and implementation risk rather than on its own

Arabic ERP and RTL: What to Check Before You Buy