A company reporting to a board and to a government counterparty needs the same thing for both: statements produced natively in Arabic, not translated from a finished English pack.

Saudi companies report under IFRS as endorsed in Saudi Arabia (or IFRS for SMEs where eligible), as set by SOCPA. Statutory filings, bank submissions and many board packs require Arabic. Producing statements in English and translating them leaves a gap, because a translation is a point-in-time snapshot and any later adjustment updates one version and not the other. Generating both from the same ledger removes that risk.

Configuring bilingual account structures

Each account, cost center and reporting node needs an Arabic description alongside its English one, written properly and not transliterated. Most implementations defer this data exercise and then discover it at first close, when the Arabic trial balance emerges with half its account names in English. We populate and review the Arabic chart of accounts as part of the design phase.

Statement layout and terminology

Arabic financial statements follow right-to-left layout with numbers remaining left-to-right. The terminology should match what Saudi auditors and regulators expect and avoid literal translation. Accrued expenses, retained earnings and non-controlling interests each have an accepted Arabic equivalent. An unconventional rendering makes the statements harder for their intended readers to use.

Notes and disclosures

The notes are usually the larger part of the work. Accounting policy notes, related party disclosures, segment reporting and financial instrument disclosures all need accurate Arabic versions, since auditors and regulators read these sections closely. Where the system generates the primary statements and the notes are prepared separately, the reconciliation between them must be explicit.

A hypothetical example

Consider a Riyadh group that prepares its statements in English and translates them for filing. A late audit adjustment is then posted to the English version, and the open question is whether the signed-off Arabic version gets updated too. Generating both from the ledger removes that question.

Beyond statutory reporting

The same bilingual configuration serves management reporting, board packs and lender submissions, so the work done for statutory compliance is useful throughout the year. This connects to financial reporting design and to how Arabic invoicing is configured, since both depend on master data being complete in both languages.

Consistency between statutory and management reporting

The Arabic statutory statements, the English group pack and the monthly management reports should all reconcile to the same ledger without manual bridging. Where they do not, the cause is usually an adjustment made in one reporting layer and never pushed back to the source. We treat the ledger as the single source of truth and build each output from it. This is the core of sound reporting design and what makes consolidation reliable for groups.

Working with the external auditor on the Arabic version

The auditor issues an opinion on specific statements, so it must be clear which version is the audited one and how the other relates to it. Agree early with the auditor which language the opinion will be issued in and how adjustments are handled in both versions. Leaving this to the final sign-off week risks delaying the filing.