An Arabic and English ERP lets each user work in their own language and produces documents in either or both. Doing it properly means right-to-left screens that are mirrored rather than translated, master data stored in both languages, Arabic text shaped correctly on invoices and reports, Hijri dates where they are needed, and search that understands Arabic spelling variation.
Many systems claim Arabic support. The difference between a usable bilingual ERP and a frustrating one shows up in the details: a customer name that breaks the invoice layout, a phone number that reverses, a search that cannot find a supplier because of one letter form. This guide sets out those details so you can specify them, test them and decide whether a package or a custom build fits your needs.
What does a bilingual Arabic and English ERP need?
It needs five capabilities, and each can be done well or badly. Use the table as your specification.
| Capability | Done well | Done badly |
|---|---|---|
| Right-to-left interface | Whole layout mirrors: navigation, tables, forms, icons with direction | Labels translated but layout stays left-to-right |
| Bilingual master data | Separate Arabic and English fields for names, addresses and descriptions | One name field, typed in whichever language the user chose |
| Documents | Bilingual templates with correct Arabic shaping and mixed-direction lines | Disconnected letters, reversed numbers, overlapping text |
| Dates and numbers | Gregorian stored, Hijri displayed where required, digit style chosen per output | Hijri typed into text fields, inconsistent digit styles |
| Search and reporting | Arabic-aware search, sorting and exports in both languages | Search fails on spelling variants; exports garble Arabic |
If you need an ERP where Arabic is a first-class language rather than an add-on, our custom ERP software page explains how we build bilingual systems module by module.
How should right-to-left screens be built?
Set direction in the page structure, mirror the layout using start and end rather than left and right, and let the browser handle mixed-direction text. The W3C Internationalization guidance on structural markup says that if the overall document direction is right-to-left, you add dir="rtl" to the html element, that CSS should not be used to set base direction, and that dir="auto" should be used on forms and inserted text whose direction is only known at run time. It also recommends logical properties (start and end) instead of left and right.
What that means in practice:
- The whole layout mirrors. The menu moves to the right, tables read right to left, the first column of a form is on the right, and progress steps run right to left.
- Some things do not mirror. Numbers, codes, email addresses, URLs and product SKUs stay left to right inside Arabic text. Media controls and charts with a time axis usually keep their direction.
- Icons with meaning flip. Back and forward arrows, indent icons and "next" chevrons must be mirrored; a checkmark or a search icon does not.
- Mixed content is isolated. An English product name inside an Arabic sentence, or an invoice number next to an Arabic label, should be isolated so punctuation and numbers do not jump to the wrong end.
- User input detects its own direction. A notes field may receive Arabic from one user and English from another.
Build the interface on a component library that supports right-to-left from the start. Retrofitting direction into hundreds of hand-built screens is slow and leaves edge cases everywhere. Our UI and UX design services cover designing both directions together rather than mirroring at the end.
How should bilingual master data be stored?
Store separate Arabic and English values for every field a customer, supplier, regulator or employee will read, and decide per field which language is mandatory. Never rely on one free-text field and machine translation at print time.
| Record | Fields to hold in both languages | Usually single-language |
|---|---|---|
| Customer and supplier | Legal name, trading name, address, contact name | Tax registration number, email, phone, bank account |
| Item or service | Short name, description on documents | SKU, barcode, unit codes |
| Employee | Full name as on official documents, job title | Employee number, ID numbers |
| Chart of accounts | Account name, if Arabic reports are needed | Account code |
| Locations | Warehouse and branch names, addresses | Location codes |
Decisions to make up front:
- Which language is mandatory for each record type? For a business that issues Arabic documents to government, the Arabic legal name may be mandatory and the English one optional.
- Who enters the second language? Data entry teams, a translation step in the approval workflow, or a suggestion from a translation service that a person confirms.
- What happens when one language is missing? The document either falls back to the other language with a warning, or refuses to print. Choose deliberately.
- How are names transliterated? The same Arabic name can be written in English several ways. Store the official spelling once and reuse it.
How do Arabic invoices and documents work?
Arabic documents need a font with full Arabic coverage, a rendering engine that shapes letters correctly, and templates designed for both directions. Bilingual invoices usually place Arabic and English side by side or stacked, with numbers and codes left to right in both.
Common problems to test for:
- Disconnected letters. Arabic letters join differently at the start, middle and end of a word. Some PDF libraries print isolated forms unless shaping is enabled.
- Reversed numbers. A phone number or amount that reads backwards inside Arabic text.
- Long names. Arabic legal names can be long. Test the longest real name in your data, not a sample one.
- Totals in words. If your documents print amounts in words, Arabic number grammar is complex. Use a tested library and check the output with a native speaker.
- Digits. Decide whether Arabic outputs use Western digits (0 to 9) or Arabic-Indic digits, and apply it consistently.
Whether your tax invoices must contain Arabic, and which fields, is a legal question that depends on the country and your situation; confirm it with your adviser. For the UAE tax context, including e-invoicing, see ERP software in the UAE and UAE e-invoicing ERP readiness. Where e-invoicing applies, take any field-level language rules from the official specification rather than from your printed layout.
How should an ERP handle Hijri dates?
Store dates in the Gregorian calendar and display Hijri dates where users or documents need them. Never store a Hijri date as text typed by a user, because it cannot be calculated with or reliably converted back.
Points to settle:
- Which Hijri calendar? There are several calculation methods, and they can differ by a day. Modern platforms support more than one: for example, the JavaScript internationalisation API (Intl) lists calendars including islamic-umalqura, islamic-civil and islamic-tbla. Choose the one your users and regulators expect and use it everywhere.
- Where are Hijri dates shown? Often on HR documents, some government correspondence and contract dates, but not in accounting periods, which normally follow the Gregorian financial year.
- Date pickers. If users must enter Hijri dates, the picker should convert to Gregorian on save and show both.
- Working weeks and holidays. Calendars for shift planning, payroll and service levels need public holidays, some of which follow the Islamic calendar and are confirmed close to the date. Make holiday tables editable by an administrator rather than hard-coded.
How do search, sorting and reports work in Arabic?
Search should normalise common spelling variation so users find records whichever form they type. Typical rules include treating different forms of alef as equivalent, ignoring diacritics (tashkeel), and handling ta marbuta and ha, and alef maqsura and ya, as interchangeable for search purposes. Sorting should follow Arabic alphabetical order, not raw character codes.
For reports and exports:
- Reports should be available in either language, with column order mirrored in Arabic.
- Spreadsheet exports must use an encoding that preserves Arabic (UTF-8), and test files open correctly in the tools your finance team uses.
- Dashboards with mixed-language labels need the same isolation rules as screens. Our guide to business dashboard KPI design covers the layout side.
Packaged ERP or custom build for Arabic?
Many packaged ERPs offer Arabic language support, and for a business that mainly needs bilingual documents, a well-supported package with a capable local partner is often enough. Check the vendor's own documentation for what is covered and test it with your own documents and data.
A custom build, or custom modules alongside a package, makes sense when Arabic users are a large part of the workforce, when customer or citizen portals must work equally well in both languages, or when the package's right-to-left screens are a translated layer over a left-to-right design. Public-sector systems often fall into this group. Our Qatar government digital platform case study describes a bilingual Arabic and English platform with full right-to-left support, an applicant portal, case management, role-based access and audit, tested in both language directions.
Bilingual ERP testing checklist
Run these tests on any system, packaged or custom, before you sign off.
- Switch language and confirm the whole layout mirrors, including tables, forms and navigation
- Enter an Arabic customer name with an English product name and an invoice number in one line, and check nothing jumps position
- Print an invoice for the longest real Arabic name in your data
- Check every Arabic document for correctly joined letters in PDF and on paper
- Confirm phone numbers, amounts and codes read left to right inside Arabic text
- Search for a supplier using a different alef form or without diacritics
- Sort a customer list in Arabic and check the order with a native speaker
- Enter a Hijri date and confirm the stored Gregorian date and the displayed Hijri date agree
- Export a report with Arabic text to a spreadsheet and open it
- Send an email or notification in Arabic and check the subject line and body
- Have Arabic-speaking staff run real tasks during user acceptance testing
When is a fully bilingual ERP not the right approach?
If only a handful of users read Arabic and the need is limited to customer documents, a full right-to-left interface and bilingual master data on every record is cost without return. Bilingual document templates and Arabic fields on customer and item records will do. Equally, translating every report doubles maintenance; translate the reports Arabic readers actually use.
How to start
List who will use the system in each language, which documents go out in Arabic, which records need two names, and where Hijri dates appear. Add samples of your current Arabic documents. Our software requirements brief template gives you a structure for the rest.
Then discuss the project with us. Timeline Digital builds 2 to 3 key modules as a free pilot before the full project starts, so your Arabic and English users can test real screens and documents in both directions before you commit.