Lo standard XBRL

Concetti base dell'XBRL

Lo standard XBRL si occupa della rappresentazione di dati finanziari, ed in particolare di report finanziari. Lo scopo dell'XBRL è quello di definire un formato per scambiare queste informazioni fra entità diverse, ad esempio un'Azienda ed una Borsa Valori, oppure un Cliente ed una Banca, oppure un'Azienda ed un Analista o Revisore.

Vediamo subito, in pratica, come questo si realizza, senza entrare da subito

L'istanza

Un'istanza XBRL è un documento che contiene un report o comunque dati finanziari. I dati che compongono il report possono essere di vario tipo: numerici, monetari, testuali, ecc. Il concetto alla base dell'XBRL è che un report – espresso in questo formato – deve consentire l'interpretazione dei dati in esso contenuti in modo chiaro, univoco e completo.

Prendiamo un piccolo frammento di un'istanza XBRL, riferita ad un bilancio rappresentato secondo i principi IAS:

Element Label	Weight	Value	Calc Value
Other Liabilities, Total			600.000,00
Other Liabilities, Current	1	500.000,00	500.000,00
Other Liabilities, Non Current	1	100.000,00	100.000,00
Other Financial Assets, Total			200.000,00
Other Financial Assets, Current	1	100.000,00	100.000,00

I numeri evidenziati in rosso sono quelli “immessi” dal redattore del report. L'esempio è tratto dalla tipica schermata che può offrire un tool per la gestione di dati XBRL. Fin qui, apparentemente nulla di emozionante, gli stessi dati li potrei immettere in un foglio di calcolo. Approfondiamo però alcuni altri elementi della schermata.

Esiste una colonna 'Calc Value': su questa colonna sono riportati dei dati calcolati dal tool che stiamo usando. Le formule usate per il calcolo sono state prese dal DTS, che non è altro che lo “schema” secondo cui è stata compilata questa istanza. Allo stesso modo, il fatto che compaiano determinate descrizioni, e che queste siano incolonnate sotto altre, in un particolare ordine, dipende dall'interpretazione che il nostro tool ha fatto delle informazioni presenti nel DTS.

Lasciamo però da parte lo schema, e concentriamoci sull'istanza. I numeri che abbiamo immesso, vengono definiti fatti. I fatti espressi nella nostra istanza sono “Other Liabilities, Current hanno un valore di 500.000”, ecc., ecc. Preso a sé stante, questo fatto è poco significativo: cinquecentomila cosa? Patate? Dollari? E queste passività a che data sono, a che azienda appartengono, sono un dato di bilancio, un forecast, un budget? Tutte queste informazioni sono presenti nell'istanza, in particolare:

nell'istanza sono definite le unità di misura utilizzate, ed ogni fatto di tipo numerico è contrassegnato con l'unità di misura in cui è espresso.
Nell'istanza vengono definiti dei contesti, che identificano l'azienda o unità a cui si riferiscono i dati, l'eventuale sottounità o segmento di business, e la data a cui i fatti sono riferiti. Ogni contesto ha un id, che lo identifica in modo univoco (all'interno del documento che contiene l'istanza), ed ogni fatto è riferito ad un singolo contesto.

Analizzando il singolo fatto, potremo quindi capire che il valore è espresso in Euro, si riferisce alla Società AAA S.p.A. Ed è il bilancio al 31 dicembre 2003.

All'interno di una singola istanza, possono quindi esserci diverse tipologie di dati:

dati di bilancio relativi alla stessa Società in due contesti: anno corrente ed anno precedente;
raffronto fra budget e consuntivo relativo ad una stessa Società, nello stesso anno;
dati di vendite di varie Società di un Gruppo, relative ad un quarter, avendo per ognuna di esse due contesti: uno espresso in divisa domestica, ed uno in divisa di consolidamento, con indicazione del rapporto di cambio utilizzato.

Questi esempi ci fanno iniziare a comprendere la flessibilità di questo standard.

Il DTS

L'acronimo sta per Discoverable Taxonomy Set, e sta a ricordarci che un'istanza deve sempre fare riferimento ad una o più tassonomie. Le tassonomie sono dei documenti che definiscono tutti i possibili fatti che possono essere espressi in un'istanza (ovvero in un report): in pratica la tassonomia è l'elenco delle possibili voci che possono comparire nel report. Ad ogni voce viene attribuito un nome ed un identificativo, nonché alcune caratteristiche, fra cui le più importanti sono il tipo dei dati, il segno atteso (dare o avere), ed il tipo di riferimento temporale significativo per tale voce (se cioè il valore è misurato ad una data, oppure si riferisce ad un periodo).

Da queste prime informazioni, scopriamo che una tassonomia non è altro che un elenco unidimensionale di voci, e che quindi le istanze che riporteranno i fatti secondo lo schema espresso dalla tassonomia, non saranno altro che delgi elenchi di fatti. Sono quindi esclusi dati in forma matriciale: non ne conosco esattamente il motivo, ma è immaginabile che tale scelta sia dettata da un desiderio di flessibilità e semplicità: d'altronde, se il nostro report contiene dei dati espressi in forma matriciale, basterà definire una voce per ogni cella della matrice.

Costruire una sistema di reporting

Costruire la tassonomia

Prima di partire occorre definire due elementi:

il target namespace
il namespace prefix

Il primo è una stringa che deve identificare in modo univoco la vostra tassonomia – a livello universale – in quanto costituisce lo spazio dei nomi all'interno del quale i nomi assegnati agli elementi della tassonomia sono univoci.

L'obbligatorietà di questo attributo (dell'elemento <schema>) è stabilita in [FRTA 4.2.12]. Tale attributo va specificato anche se lo schema non dovesse contenere elementi; è un caso possibile se si vuole definire uno schema solo per aggregare insieme degli schemi diversi.

Definizione del target namespace

Questo punto, anche se apparentemente banale, è molto importante, in quanto questo attributo identificherà in modo univoco la vostra tassonomia all'interno della community XBRL.

Le regole vengono stabilite in [FRTA 4.3]. Il formato può essere sia quello di una generic URI (definito in [RFC2396 Sect.3]), che quello di una URN [RFC2141]. All'interno del namespace devono comunque essere presenti gli stessi elementi; faremo quindi l'esempio – forse più familiare – della URI.

Gli elementi sono dunque:

uno schema (che non ha nulla a che fare con lo schema XBRL), in pratica può essere 'http:';
un'autorità, che pubblica lo schema. In genere è un sottodominio di un dominio internet registrato effettivamente dall'ente che pubblica la tassonomia. Se un'azienda si chiama “Industrie Anonime S.p.A.”, il namespace potrà iniziare con “http://www.industrie-anonime.it”. Il fatto di usare un dominio realmente registrato è importante, perché mi consente di pubblicare poi effettivamente lo schema sotto di esso, e mi da' una garanzia di univocità.

Prima del dominio, è possibile anche specificare un id utente, ad esempio “http://rossi@www.industrie-anonime.it”.
Una jurisdiction. Questo codice dovrebbe essere il codice [IANA] della nazione, ma soprattutto identifica l'autorità nazionale per il consorzio XBRL. Se la tassonomia viene sviluppata indipendentemente dall'organizzazione XBRL, si può usare anche una sigla come “nn” (non normative), oppure “priv”. Questi suggerimenti non sono però previsti dalla FRTA.
Un tipo di reporting, con i valori br per business reporting, oppure fr per financial reporting.
Lo standard contabile adottato, che può essere ias, gaap, o tax (per Tax Based Reporting).
Il settore di attività economica per cui è disegnata la tassonomia, con i valori ci (per industria e commercio), basi (per banche ed istituti di deposito), gp (per impiego generale) e nfp (per aziende no-profit).
Il qualificatore opzionale, per fornire un dettaglio maggiore rispetto alla jurisdiction; potrebbe essere il codice di un form, oppure una sigla come cvs, o puma.
La data della versione, nel formato aaa-mm-gg.

Riepilogando, uno schema per la comunicazione valutaria statistica di una banca potrebbe avere come namespace: “http://www.bancaditalia.it/it/br/gaap/basi/cvs/2005-02-14”. Qui sono stato in difficoltà nell'individuare lo standard contabile ed il tipo di reporting, scegliendo di usare br (in quanto la CVS non è un bilancio o un report), e gaap, in quanto viene espressa secondo principi generali che non si rifanno però agli IAS.

Va tenuto presente che la data è l'unico elemento in grado di distinguere differenti versioni della stessa tassonomia [FRTA 4.3.3].

Il namespace prefix

Anche se meno importante del namespace, anche questo elemento è regolato da [FRTA 4.3.2]. La lunghezza di questo prefisso va da uno a 12 caratteri. Tipicamente si usa la parte centrale del namespace (gli elementi più significativi), riferendosi all'esempio: it-cvs, oppure it-basi-cvs.

Questo prefisso verrà utilizzato sia negli id dei concetti definiti nello schema, sia per costituire la parte iniziale dei nomi di file.

Individuazione degli elementi

Relazioni di calcolo

Relazioni di riferimento

Si tratta di una componente importante del DTS, normata nella FRTA, che ha lo scopo di documentare quali sono i riferimenti normativi da seguire nell'attribuzione di dati ad un singolo concetto della tassonomia. E' importante ricordare che tali link non devono contenere spiegazioni, ma semplicemente dei puntatori ad un documento esterno (ad esempio IAS 1 68 c).

Queste relazioni sono generalmente raccolte in un file di linkbase dedicato, secondo quanto prevede la FRTA.

L'arco che lega il concetto alle “resource” che ne individuano i riferimenti ha sempre come “role” (ovvero come tipo”) “http://www.xbrl.org/2003/arcrole/concept-reference”. Tuttavia lo standard prevede diversi tipi di definizioni, che vengono distinte dall'attributo xlink:role dell'elemento <reference> all'interno di un <referenceLink>.

Tali valori permettono di distinguere diversi tipi di riferimenti, ad esempio su come l'elemento documentato deve essere presentato, oppure su come deve essere misurato. Un elenco completo, con le spiegazioni si ha in [XBRL 5.2.3.2.1].

L'elemento <reference> deve poi contenere altri elementi che identificano la legge, pubblicazione, o altro materiale a cui si fa riferimento, così come il capitolo, paragrafo, oltre ad altre possibili informazioni, come il nome dell'autore, o la data di pubblicazione.

Chiaramente, la natura di questi dettagli non dipende dallo standard XBRL, per cui lo schema da adottare viene lasciato libero. In pratica, chi sviluppa la tassonomia, deciderà che tipo di informazioni di riferimento fornire a corredo.

Il consorzio XBRL ha sviluppato un suo schema generico, identificato dal namespace “http://www.xbrl.org/2004/ref” in cui definisce alcuni elementi:

Name: il titolo della pubblicazione;
Publisher: l'organizzazione che pubblica il documento;
Number: il numero della pubblicazione (ad esempio il numero dello IAS);
IssueDate: la data di pubblicazione;
Chapter: se la pubblicazione prevede capitoli;
Article: il numero dell'articolo di una legge o altro materiale normativo;
Note: se è presente una nota o appendice come unità documentale autonoma, non confonderla con la nota a pié di pagina;
Section/Subsection: cattura l'informazione della sezione di una legge o altro materiale normativo;
Paragraph/Subparagraph: identifica un paragrafo o comma;
Clause/Subclause: identifica un punto all'interno di un paragrafo o comma;
Appendix: per individuare un'appendice;
Example: nel caso in cui un esempio sia illustrativo ed identificabile;
Page: per fare riferimento al numero di pagina;
Exhibit: per identificare un particolare prospetto che non sia un esempio;
Footnote: per note a pié di pagina;
Sentence: quando addirittura le frasi sono numerate;
URI: se il materiale è individuabile da una locazione internet;
URIDate: la data a partire dalla quale l'URI è valido.

Lo schema descritto come si vede è molto articolato (la precedente versione del 2003, descritta in [XBRL Example 46] è molto più semplice. Si tratta comunque di una definizione generica, che potrebbe non adeguarsi a tutte le situazioni. Ad esempio, dovendo definire dei riferimenti per una tassonomia per le Segnalazioni di Vigilanza da inoltrare alla Banca d'Italia, gli elementi potrebbero essere la voce, sottovoce, ecc.

Lo standard lascia comunque la massima libertà in proposito: l'autore della tassonomia può disegnare il suo schema XML (un file .xsd), attribuendogli un namespace. L'unica accortezza è che tutti gli elementi definiti devono essere un'estensione di http://www.xbrl.org/2003/linkbase#part , che è l'elemento astratto previsto dallo standard XBRL per le singole parti che compongono un riferimento.

Nel file del DTS che contiene il linkbase, si dovrà quindi importare il proprio schema; vediamo ad esempio la tassonomia degli IFRS:

<linkbase xmlns="http://www.xbrl.org/2003/linkbase" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ref="http://www.xbrl.org/2004/ref" xsi:schemaLocation="http://www.xbrl.org/2003/linkbase http://www.xbrl.org/2003/xbrl-linkbase-2003-12-31.xsd http://www.xbrl.org/2004/ref ref-2004-08-10.xsd">

Si vede come nella linkbase venga importato il namespace per i riferimenti, a cui viene attribuito il prefisso (standard) ref.

Nei singoli link troviamo poi:

<reference xlink:type="resource" xlink:role="http://www.xbrl.org/2003/role/presentationRef" xlink:label="ifrs-gp_ImpairmentLossRecognisedInEquityDevelopmentCosts_ref">

<ref:Name>IAS</ref:Name>

<ref:Number>38</ref:Number>

<ref:Paragraph>118</ref:Paragraph>

<ref:Subparagraph>e</ref:Subparagraph>

<ref:Clause>iii</ref:Clause>

</reference>

dove vengono usati alcuni delgi elementi previsti dallo schema ref.

Identificativi collegati ad un elemento

Un elemento ha due identificativi all'interno dello schema:

l'attributo name,
l'attributo id.

Esempio:

<element id="ifrs-gp_AccruedExpensesAndDeferredIncomeTotal" name="AccruedExpensesAndDeferredIncomeTotal" type="xbrli:monetaryItemType" substitutionGroup="xbrli:item" nillable="true" xbrli:periodType="instant" xbrli:balance="credit" />

A fronte dell'elemento, sono presenti delle label (testo descrittivo) nei vari file xml per ognuna delle lingue in cui sono espresse.

L'elemento viene individuato da un elemento <loc> , sotto <labelLink>nella linkbase, con tipo “locator”, di cui vediamo un esempio:

<loc xlink:type="locator" xlink:href="ifrs-gp-2004-09-15.xsd#ifrs-gp_AccruedExpensesAndDeferredIncomeTotal" xlink:label="ifrs-gp_AccruedExpensesAndDeferredIncomeTotal" />

Il locator punta a:

il file con lo schema in cui viene definito l'elemento;
un identificativo per la label, che nell'esempio coincide con l'identificativo dell'elemento.

Questo secondo identificativo viene referenziato nell'attributo from di un elemento <labelArc>, con ruolo concept-label, che lo lega all'elemento-etichetta:

<labelArc xlink:type="arc" xlink:arcrole="http://www.xbrl.org/2003/arcrole/concept-label" xlink:from="ifrs-gp_AccruedExpensesAndDeferredIncomeTotal" xlink:to="ifrs-gp_AccruedExpensesAndDeferredIncomeTotal_lbl" />

L'elemento etichetta contiene il testo descrittivo vero e proprio:

<label xlink:type="resource" xlink:role="http://www.xbrl.org/2003/role/label" xlink:label="ifrs-gp_AccruedExpenses_lbl" xml:lang="en">Accrued Expenses</label>

L'elemento label viene identificato dall'attributo 'to' del labelArc.

Nella parte di calculation, la struttura è simile, in quanto è presente l'elemento <loc>, ma sotto un <calculationLink>.

L'identificativo definito nel <loc> viene poi usato come attributo from o to nel <calculationArc>.

Nel linkbase di calcolo, possono essere presenti più elementi <calculationLink>, relativi a diverse sezioni di calcolo.