Almadar A company reporting to a board that meets in KAFD and a government counterparty near Al Wizarat both need the same thing: statements produced natively in Arabic, not translated from a finished English pack.
Riyadh companies report under IFRS as adopted by SOCPA, and statutory filings, bank submissions and many board packs require Arabic. The common practice of producing statements in English and having them translated introduces a gap: the translation is a point-in-time snapshot, and any subsequent adjustment updates one version and not the other. Generating both from the same ledger removes that risk entirely.
Configuring bilingual account structures
Every account, cost center and reporting node needs an Arabic description alongside its English one, populated correctly rather than transliterated. This is a data exercise that most implementations defer and then discover 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, and the terminology should match what Saudi auditors and regulators expect rather than a literal translation. Terms for accrued expenses, retained earnings, non-controlling interests and comprehensive income each have accepted Arabic equivalents, and using an unconventional rendering makes the statements harder for their intended readers, which defeats the purpose.
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 Arabic versions that are accurate rather than approximate, since these are precisely the sections auditors and regulators read closely. Where the system generates the primary statements and the notes are prepared separately, the reconciliation between them must be explicit.
A common Saudi scenario
A Riyadh group prepares its statements in English, translates them for filing, then posts a late audit adjustment. The English version is updated and refiled; the Arabic version, already translated and signed off, is not. The two differ by a material amount, discovered only when a bank compares the Arabic filed copy against the English pack in its credit file. Generating both from the ledger would have made this impossible.
Beyond statutory reporting
The same bilingual configuration serves management reporting, board packs and lender submissions, so the investment made for statutory compliance pays back throughout the year. This connects directly to financial reporting design and to how Arabic invoicing is configured, since both depend on the same underlying 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 differences are usually adjustments made in one reporting layer and never pushed back to the source. We establish the ledger as the single point of truth and build each output from it, which is the core principle behind sound reporting design and what makes consolidation reliable for groups.
Groups with government contracts or Saudi bank facilities face the strictest Arabic statement requirements, while companies with foreign parent reporting need particular attention to keeping the Arabic statutory version and the English group reporting reconciled rather than separately maintained.