Come abbiamo visto nel precedente articolo, l’i-XBRL è un tentativo di creare uno standard di comunicazione elettronico dei dati finanziari delle aziende con le amministrazioni pubbliche, che sia comprensibile contemporaneamente alla macchina per acquisire il bilancio dell’impresa che lo invia che all’uomo attraverso l’apertura del file che contiene questo formato con un comunissimo browser per la navigazione Internet.
L’i-XBRL è un formato che è stato realizzato dall’ESMA (European Security Markets Authority), che ha realizzato quella che viene denominata tassonomia ESEF (European Single Electonic Format).
Questo formato si sovrappone al formato XBRL, che ogni Paese ha adottato internamente e che predispone una tassonomia nazionale specifica per il trasferimento del bilancio e della nota integrativa secondo i principi contabili nazionali.
In Italia l’XBRL è pensato per trasferire il solo bilancio d’esercizio corredato di nota integrativa nel solo formato di IV direttiva CEE, così come sancito nel Codice Civile italiano.
L’i-XBRL però oltre ad avere una tassonomia più generale aggiunge la leggibilità immediata tramite browser che permette senza alcun software specifico per la lettura dell’XBRL di leggere in formato tabellare il bilancio e la nota integrativa.
Diversi sono i vendor che mettono a disposizione piattaforme per l’adempimento i-XBRL. Tra questi, va distinto chi ha deciso di internalizzare la produzione dell’i-XBRL, come SAP che ha prodotto all’interno della soluzione SDM di SAP Disclosure Management un generatore di i-XBRL, da chi (come ORACLE, BOARD o TAGETIK) ha deciso di utilizzare un partner specialista nella generazione dell’i-XBRL.
È importante notare che lavorare con un partner specialista consente al vendor di soluzioni di reporting, alla società di consulenza e al cliente finale di dimenticarsi delle variazioni normative perché lo specialista si preoccupa di farlo per chi lo richiede. È anche vero che sebbene questi strumenti siano in grado di partire di fatto dall’equivalente della stampa di un report, un file pdf o altro formato similare, per produrre un tracciato i-XBRL, bisogna ricordarsi che è buona norma che il reporting utilizzato esca da un sistema di disclosure.
Infatti, spesso il reporting non è espresso all’unità di valuta ma alle migliaia o al milione dell’unità di valuta e soggetto ad arrotondamenti, ma gli arrotondamenti dei saldi di bilancio sono esplosi dentro a tabelle di dettaglio presenti della nota integrativa. Arrotondare questi dettagli può portare ad errate ed imbarazzanti differenze esposte sia nelle stampe della reportistica annuale sia nella relazione sulla gestione, ma anche a conseguenze peggiori, come l’errore nella validazione dell’i-XBRL quando due informazioni di diverse sezioni devono essere in stretta correlazione numerica.
i-XBRL: le tecnologie
Su questo aspetto SAP (fornisce una soluzione completa basata su sorgenti dati che possono risultare statici o dinamici Quando sono collegati ad una soluzione CPM come BPC viene affiancato un potente tool che si aggiunge con un plug in per l’excel dell’utente e permette una gestione automatica delle logiche di arrotondamento e di validazione tra sezioni diverse. TAGETIK invece promuove il CDM (Collaborative Disclosure Management), che gestisce nella logica workflow tipica di TAGETIK la costruzione del volumetto di reportistica annuale o di relazione sulla gestione dalla soluzione di produzione dell’i-XBRL, che si avvalla di un’altra soluzione che parte direttamente dalle stampe PDF del CDM. Questa soluzione è Corefiling della Seahorse.
La stessa soluzione (Corefiling) è stata scelta da BOARD, che però nella sua logica a toolkit, non propone una soluzione di disclosure fatta e finita ma ne fornisce un acceleratore all’interno della sua soluzione per il bilancio consolidato BFC, che consente di avere puntamenti a voci precise del bilancio annegate nel testo e aggiornabili dinamicamente.
Tutto questo come per TAGETIK che permette di arrivare a costruire prospetti di reporting annuale sulla cui stampa poi agganciare Corefiling per la generazione dell’i-XBRL.
ORACLE ha fatto la stessa scelta di TAGETIK e BOARD nel separare i due ambiti, ma la soluzione per l’i-XBRL è quella Ez-XBRL. Anche in questo caso conviene adoperarsi in un progetto di disclosure che utilizzi la sua soluzione cloud di narrative reporting, anche se la soluzione di Ez risulta più completa di quella Corefilling, per la presenza di un controllo di validità e la possibilità di gestire formule e calcoli all’interno della mappatura.
In tutti i casi, un progetto di i-XBRL passa da un buon progetto di disclosure per garantire che nella base di partenza, in genere un file PDF, un word, una pagina HTML, siano contenenti tutte le informazioni finanziarie di bilancio necessarie.
Il progetto prosegue con la mappatura della tassonomia (o taggatura) alle voci di bilancio o ai dettagli di nota. I tool offrono una selezione dell’area della voce e una selezione da un menù a tendina con un sistema di auto associazione.
Sono funzionalità offerte da quasi tutti i tool con l’esclusione del SDM:
- L’auto identificazione della valuta e della scala della valuta;
- L’auto identificazione della voce di conto;
Inoltre, è tipico dell’i-XBRL ed è gestita da tutti i tool la possibilità di estendere la tassonomia per gestire quei dettagli di bilancio che non sono identificabili con lo standard.
i-XBRL: conclusioni
In sintesi, si può dire che una soluzione di i-XBRL può vivere anche senza una soluzione di reporting o di CPM, ma che per giungere ad un i-XBRL in modo veloce e integrato queste soluzioni richiedono a cappello una soluzione CPM per la produzione del dato, di una soluzione di reporting finalizzata alla disclosure controllata e di un buon tool di i-XBRL che minimizzi il lavoro di taggatura e consenta di acquisire autonomamente le variazioni della tassonomia derivanti dai cambiamenti normativi.
