Bilingual Board Packs: The Same Numbers, Not a Translated Copy
A GCC board pack in Arabic and English has to carry identical figures, not a document assembled twice. Here is how Rexfin's export pipeline is built for that.
By The Rexfin team
A board pack built for a bilingual GCC board usually starts life in one language and gets a second version bolted on afterward. Someone exports the English deck, then someone else (or the same overworked analyst at 11pm) retypes the labels into Arabic, reformats the numbers, and hopes nothing drifted in translation. If a board member catches a mismatch between the English “12.4” and the Arabic “12.3” on the same line, the pack has already lost the room, and it doesn’t matter which version was right.
The real requirement for a bilingual board pack isn’t a translation. It’s the same reconciled figures, rendered twice.
Why “just add Arabic” doesn’t hold up
Most finance software treats Arabic as a display setting: swap the font, flip the direction, translate the labels, ship it. That works for a marketing brochure. It does not work for a document a board is going to use to decide whether to approve a capital raise, because the Arabic and English versions have to agree to the decimal, on every line, in every scenario column, every quarter.
Rexfin’s Arabic-first statement rendering already handles the harder part of this problem upstream of the board pack: GCC currency conventions built in rather than adapted, the three-decimal currencies (Kuwaiti dinar, Omani rial, Bahraini dinar) that break naive formatting, and an IFRS-18 statement shape with the region’s tax and zakat split computed rather than approximated. A bilingual board pack that draws from that same layer inherits it: the Arabic figures are not a second calculation, they’re the same reconciled numbers with different labels and script direction.
One payload, not two documents
The mechanism that makes this trustworthy is the same one behind every Rexfin board pack export: a single gated payload assembled once from the reconciled model, then rendered into whichever output format is requested. There is no separate “Arabic pipeline” that a translator maintains by hand and that can quietly fall out of sync with the English one. Both language renders read from the same numbers, the same version, the same content hash, so if the English pack changes because a driver was updated, the Arabic pack changes with it, not on its own schedule.
That single-payload architecture is also why the print templates were built with logical CSS from the start rather than fixed left-to-right layout: a right-to-left rendering is a layout swap on the same template, not a separate document type maintained in parallel. It’s the kind of decision that only matters once you actually need it, and it’s already in the foundation rather than something to retrofit under deadline pressure.
What this doesn’t mean yet
Not every piece of region-specific analysis has made it into every export format. The tax and zakat split and the IFRS-18 category view are live on the statement screens today; folding them into the XLSX workbook as their own sheet is flagged as a deliberate next step, not something quietly skipped. The honest way to describe where things stand: the foundation (reconciled figures, one payload, region-native formatting, an RTL-ready template) is built so that adding bilingual coverage to a new export surface is additive work on top of an existing structure, not a rewrite of the pipeline each time.
Who this is for
This matters most for finance teams reporting to boards, LPs, or regulators who read Arabic first, or who sit alongside English-speaking co-investors and need both versions to be defensible in the same meeting. A CFO in Riyadh or Abu Dhabi presenting to a mixed board shouldn’t have to choose between a document their board can read comfortably and one that ties out to the ledger, and shouldn’t have to reconcile two separately produced files against each other before the meeting starts.
The version-diff and audit trail that stamps every export applies the same way regardless of which language the pack renders in, so a bilingual pack carries the same tamper-evidence as an English-only one. Same numbers, same hash, two scripts, not two products quietly drifting apart.
For the fuller picture of how figures move from source document to a gated export, see the Rexfin product tour.
Part of Rexfin Product Tour: Every Number Traceable