Bilingual factory accounting — running an Arabic finance team on IFRS books

A typical Saudi or Egyptian F&B factory has three audiences for its accounting:

1. Arabic-native finance staff — the AR clerk, AP clerk, payroll specialist, junior accountants. They work in Arabic by default. The CFO often is Arabic-native too.
2. English-speaking expat managers — the plant manager, logistics director, possibly the CEO. They work in English by default.
3. External readers — auditors (mix), tax authority (Arabic by regulation), banks (often English for international banks, Arabic for local), investors (depends).

Most ERPs handle two of these well and the third poorly. AION’s design philosophy is that all three should work natively in the same system — not via translation layers bolted on top.

This article walks through what bilingual factory accounting actually requires.

Three layers that need to be bilingual

Layer 1: The UI. Every screen, every form, every navigation element renders in either language. Buttons, labels, menu items, error messages, validation text. Switch the language and the whole UI flips — RTL for Arabic, LTR for English.

Layer 2: The data. Master data records (items, customers, suppliers, GL accounts, employees) carry both English and Arabic names. Transaction data inherits the appropriate language based on the entity’s primary locale and the report’s audience.

Layer 3: The output. Invoices print in either language (or both, side-by-side, for ZATCA Phase 2 / ETA compliance). Financial statements generate in either language. Management reports default to the user’s preference.

A real bilingual ERP gets all three. A “translated” ERP usually gets Layer 1 right and lets Layer 2 and Layer 3 drift — you end up with reports that have Arabic labels around English data, which is unusable.

What MSA accounting terminology means

Saudi and Egyptian accountants trained in the local universities use Modern Standard Arabic (MSA) accounting terminology. Not Egyptian colloquial. Not Saudi colloquial. Not auto-translated English. The specific terms:

• مدين (medin) = debit
• دائن (da’in) = credit
• مخزون (makhzun) = inventory
• مصاريف مستحقة (masareef mustahaqqa) = accrued expenses
• ضريبة القيمة المضافة (dareebat al-qeema al-mudafa) = VAT
• الذمم المدينة (al-zhimam al-madeena) = accounts receivable
• الذمم الدائنة (al-zhimam al-da’ina) = accounts payable
• إقفال الفترة (iqfal al-fatra) = period close
• تكلفة البضاعة المباعة (taklufat al-bida’a al-mubaa’a) = COGS
• ميزان المراجعة (mizan al-muraja’a) = trial balance

These are the words on the screen. An accountant using AION in Arabic mode sees these terms. They don’t have to learn an English mental model and translate in their head. Cognitive load drops; speed and accuracy rise.

A factory that runs accounting in English only forces Arabic-native staff to translate constantly. Errors compound. Training takes longer. Hiring is harder because you’re filtering for English-language accounting fluency instead of accounting fluency.

RTL layout — more than just flipping text

Right-to-left layouts aren’t just mirroring. Real RTL design considers:

• Table column order. “Date | Description | Debit | Credit | Balance” in English becomes “الرصيد | دائن | مدين | البيان | التاريخ” in Arabic — same columns, opposite reading order.
• Form field flow. Tab order goes right-to-left. Required indicators are on the left of the label, not the right.
• Navigation patterns. Back-buttons point right (the direction of reading flow). Forward indicators point left.
• Number formatting. Arabic-Indic numerals (٠١٢٣٤٥٦٧٨٩) vs Arabic numerals (0123456789). Some contexts prefer one; some the other. AION supports both, configurable per user or per report.
• Date formatting. dd-mm-yyyy vs dd/mm/yyyy vs other separators. Hijri calendar option for relevant reports (some Saudi tax filings, some payroll calculations).

AION handles all of these. A user toggling to Arabic doesn’t get a half-broken UI — they get a properly mirrored, locally formatted interface.

How bilingual data works in practice

Take an item record in AION: Oasis Mango Juice 1L.

The record carries:

• itemCode: FG-SA-MNG-1L
• name (en): Oasis Mango Juice 1L
• name (ar): عصير مانجو واحة 1 لتر
• description (en): Premium mango juice, 1L PET bottle, 6-month shelf life
• description (ar): عصير مانجو فاخر، زجاجة PET 1 لتر، صلاحية 6 أشهر
• standard cost: SAR 10.5
• sell price: SAR 18

When a Saudi accountant pulls up the item in Arabic mode, they see the Arabic name and description. When the export sales manager pulls it up in English mode, they see the English. Same record, same data, different presentation.

This extends to customers (Panda Retail Co. / بنده ريتيل), suppliers (Cairo Citrus Co. / شركة الحمضيات بالقاهرة), GL accounts (Cost of Goods Sold / تكلفة البضاعة المباعة), and employees.

The data isn’t replicated; it’s a single record with bilingual fields.

Bilingual reports — the hard part

Reports are where most bilingual ERPs break down.

A trial balance in English shows account codes and English names. In Arabic, it should show the same codes with Arabic names — and the column headers, the totals, the page-level chrome should all be in Arabic too.

AION’s report engine treats every report as a template with translatable strings:

• Column headers in both languages
• Numeric formatting per locale
• Date formatting per locale
• Page chrome (titles, pagination, signatures area) in both languages

A CFO sending the trial balance to the auditor in Arabic exports it in Arabic. The same CFO sending the same trial balance to a UK-based investor exports it in English. Same data, two outputs.

What about IFRS compliance specifically

IFRS doesn’t care what language your books are in — it cares about the accounting treatment. Recognition criteria, measurement principles, disclosure requirements — all language-agnostic.

But IFRS-compliant statements in MENA are typically required in Arabic by tax authority and corporate registry. So you need to be able to produce IFRS-compliant balance sheet, income statement, cash flow statement, and statement of changes in equity — in Arabic — from your accounting system.

AION’s financial statements are IFRS-aligned by default and bilingual by default. The Oasis Fresh demo BG has a full IFRS chart of accounts with both English and Arabic labels; pulling a balance sheet in either language produces the same underlying numbers with locally-appropriate labels.

What this means day-to-day

A factory using AION with mixed-language teams gets:

• Arabic-native accountants working in their native terminology. Hiring pool expands beyond “English-language accounting fluency.”
• English-speaking managers seeing reports in their language. No translation negotiation between teams.
• Auditors and regulators receiving statements in the language they require. ZATCA gets Arabic VAT return; an international auditor gets English management reports.
• Investors and partners receiving statements in whichever language is appropriate per relationship.

The team doesn’t argue about language. The system makes it a non-issue.

Common pitfalls

Pitfall 1: Treating bilingual as a translation project. Some ERPs let you “translate” the UI by uploading a translation file. The translation is brittle (UI changes break translations), often inaccurate (auto-translated UI strings), and incomplete (data layer never translates). Bilingual has to be a design principle, not an afterthought.

Pitfall 2: Defaulting Arabic-native users to English. Some factories install ERPs that default to English and expect Arabic users to switch. The Arabic experience often is less polished, so users stay in English even when it slows them down. Default Arabic-native users to Arabic from day one.

Pitfall 3: Skipping bilingual data entry. When creating new items, customers, suppliers, only entering the English name and leaving Arabic blank. Six months later, Arabic reports show “FG-SA-MNG-1L (English)” instead of the Arabic name. Train data entry workflows to require both at creation.

Pitfall 4: Number format inconsistency. Some screens show Arabic-Indic numerals (٠١٢٣), some show Arabic numerals (0123). Pick a default and stick with it; allow user-level override.

Where to go from here

For the Arabic-first product philosophy in detail, see the feature page on Arabic-first design (coming in the next batch of feature deep-dives). For specific compliance scenarios where bilingual matters most, see ZATCA Phase 2 (Arabic + English mandatory on invoices) and ETA e-invoicing (Arabic required, English optional).

For the broader context of why Saudi and Egyptian factories specifically need this combination, see 5 signs your juice factory outgrew Excel.