Board pack bilingui: gli stessi numeri, non una copia tradotta

Un board pack costruito per un consiglio GCC bilingue di solito nasce in una lingua e riceve una seconda versione aggiunta successivamente. Qualcuno esporta la versione inglese, poi qualcun altro, o lo stesso analista sovraccarico alle 23, ridigita le etichette in arabo, riformatta i numeri, e spera che nulla sia andato perso nella traduzione. Se un membro del board nota una discrepanza tra il “12,4” inglese e il “12,3” arabo sulla stessa riga, il pack ha già perso la fiducia della sala, e non importa quale versione fosse corretta.

Il vero requisito per un board pack bilingue non è una traduzione. Sono le stesse cifre riconciliate, rese due volte.

Perché “basta aggiungere l’arabo” non regge

La maggior parte dei software finanziari tratta l’arabo come un’impostazione di visualizzazione: cambia il font, inverte la direzione, traduce le etichette, pubblica. Funziona per una brochure di marketing. Non funziona per un documento che un board userà per decidere se approvare un aumento di capitale, perché le versioni araba e inglese devono coincidere fino al decimale, su ogni riga, in ogni colonna di scenario, ogni trimestre.

Il rendering dei bilanci arabic-first di Rexfin affronta già la parte più difficile di questo problema a monte del board pack: le convenzioni valutarie GCC integrate anziché adattate, le valute a tre decimali (dinaro kuwaitiano, rial omanita, dinaro bahreinita) che mandano in tilt la formattazione ingenua, e una struttura di bilancio IFRS-18 con la ripartizione fiscale e zakat della regione calcolata anziché approssimata. Un board pack bilingue che attinge a quello stesso livello lo eredita: le cifre arabe non sono un secondo calcolo, sono gli stessi numeri riconciliati con etichette e direzione di scrittura diverse.

Un payload unico, non due documenti

Il meccanismo che rende tutto questo affidabile è lo stesso dietro ogni export del board pack Rexfin: un unico payload con gate, assemblato una volta dal modello riconciliato, poi reso nel formato di output richiesto. Non esiste una “pipeline araba” separata mantenuta a mano da un traduttore che possa silenziosamente disallinearsi da quella inglese. Entrambe le rese linguistiche leggono dagli stessi numeri, dalla stessa versione, dallo stesso hash del contenuto, quindi se il pack inglese cambia perché un driver è stato aggiornato, il pack arabo cambia con esso, non secondo un proprio calendario.

Quella architettura a payload unico è anche il motivo per cui i template di stampa sono stati costruiti fin dall’inizio con CSS logico anziché con un layout fisso da sinistra a destra: una resa da destra a sinistra è uno scambio di layout sullo stesso template, non un tipo di documento separato mantenuto in parallelo. È il tipo di decisione che conta solo quando ne avete effettivamente bisogno, ed è già nelle fondamenta anziché qualcosa da aggiungere retroattivamente sotto la pressione di una scadenza.

Cosa non significa ancora

Non ogni elemento di analisi specifica per la regione è arrivato in ogni formato di export. La ripartizione fiscale e zakat e la vista per categoria IFRS-18 sono attive oggi nelle schermate dei bilanci; integrarle nel workbook XLSX come foglio proprio è segnalato come un passo successivo deliberato, non qualcosa saltato silenziosamente. Il modo onesto di descrivere lo stato attuale: le fondamenta, cifre riconciliate, payload unico, formattazione nativa per regione, template pronto per RTL, sono costruite in modo che aggiungere copertura bilingue a una nuova superficie di export sia lavoro additivo su una struttura esistente, non una riscrittura della pipeline ogni volta.

A chi è rivolto

Questo conta soprattutto per i team finance che riportano a board, LP o autorità di regolamentazione che leggono prima in arabo, o che siedono accanto a co-investitori anglofoni e hanno bisogno che entrambe le versioni siano difendibili nella stessa riunione. Un CFO a Riad o Abu Dhabi che presenta a un board misto non dovrebbe dover scegliere tra un documento che il proprio board può leggere comodamente e uno che quadra con il libro mastro, e non dovrebbe dover riconciliare due file prodotti separatamente prima che inizi la riunione.

Il diff di versione e la traccia di audit che timbra ogni export si applica allo stesso modo indipendentemente dalla lingua in cui viene reso il pack, quindi un pack bilingue porta la stessa prova di non manomissione di uno solo in inglese. Stessi numeri, stesso hash, due scritture, non due prodotti che silenziosamente divergono.

Per il quadro completo di come le cifre si muovono dal documento sorgente fino a un export con gate, consultate il tour del prodotto Rexfin.