Cosa imparerete
> - Come funziona la SBR olandese rispetto al deposito XBRL-Italia presso le CCIAA e all'iXBRL ESEF richiesto da CONSOB per le EIP > - Quali procedure di validità si applicano alla mappatura tassonomica quando il fascicolo è "leggero" su questo punto > - Dove vive il giudizio professionale nella scelta degli elementi tassonomici per voci OIC che non hanno corrispondenza diretta IFRS > - Cosa documentare ai sensi dell'ISA Italia 230 quando la pipeline di reporting è automatizzata da terzi
La falla nella pratica: il fascicolo che non guarda la tassonomia
Apriamo il fascicolo di una società di capitali italiana che deposita il bilancio XBRL alla CCIAA. Nove volte su dieci, la sezione dedicata al reporting digitale contiene una stampa del file .xbrl validato, una conferma di avvenuto deposito, e nulla più. Le carte sono leggere. Nessuno ha verificato che il valore "Crediti verso clienti" finisca sotto l'elemento tassonomico corretto, nessuno si è chiesto se la voce "Lavori in corso su ordinazione" (OIC 23) sia stata mappata in modo coerente con l'esercizio precedente, nessuno ha confrontato il file depositato con quello prodotto dal gestionale.
Nei Paesi Bassi il problema esiste pure, però la maturità del sistema SBR (Standard Business Reporting) ha standardizzato la disciplina. La tassonomia RGS è pubblica, il chain Logius/KvK/Belastingdienst è ben rodato, e l'AFM nei Paesi Bassi ha emesso più di un richiamo agli auditor che si fidavano ciecamente dell'output automatico. Il regolatore italiano, su questo specifico fronte, è meno rumoroso. Ma il D.Lgs. 39/2010 non distingue: se il fascicolo non sostiene il giudizio sul bilancio depositato, e quel bilancio è quello in formato strutturato, la falla c'è comunque.
Cosa significa nella pratica: stiamo firmando una relazione su un set di dati che, una volta depositato, è leggibile da macchina dalla CONSOB, dall'Agenzia delle Entrate, dalla CCIAA. Se la mappatura tassonomica trasforma una "perdita" in un "componente straordinario di reddito" perché il modello CCIAA non ha l'elemento giusto, il numero che gira nei sistemi pubblici non corrisponde a quello che abbiamo revisionato.
Cosa richiede effettivamente la norma
L'ISA Italia 315 (Revised) richiede al revisore di comprendere il sistema informativo dell'entità rilevante per la reportistica finanziaria, comprese le procedure mediante le quali i dati vengono aggregati e comunicati. Quando il bilancio finale non è il PDF firmato dal CdA ma il file iXBRL trasmesso a Bruxelles via ESMA (o il file XBRL trasmesso via InfoCamere), la pipeline di trasformazione fa parte del sistema informativo da comprendere.
Per le EIP italiane vale poi il Regolamento Delegato UE 2018/815 (ESEF) e gli RTS ESMA, che impongono il formato iXBRL con tagging della relazione finanziaria annuale e, dal 2022, dei prospetti consolidati IFRS secondo la tassonomia ESMA. La CONSOB ha competenza di vigilanza ai sensi dell'art. 154-bis TUF e del Regolamento Emittenti.
Per le società non EIP, il deposito XBRL alla CCIAA segue la tassonomia italiana XBRL-Italia mantenuta da OIC e XBRL Italia, con tracciato fissato annualmente. Non c'è una norma di revisione dedicata che dica "verifica la mappatura concettuale," ma: 1. l'ISA Italia 315 chiede di capire il sistema informativo; 2. l'ISA Italia 330 chiede risposte coerenti ai rischi identificati; 3. l'ISA Italia 720 chiede attenzione alle "altre informazioni" del fascicolo di bilancio depositato; 4. l'ISA Italia 700 chiede che il giudizio si riferisca al bilancio nella forma in cui è stato approvato e depositato.
Cosa significa nella pratica: se il CdA approva il bilancio come PDF, e poi il deposito alla CCIAA o l'invio ESEF avviene in formato strutturato con una mappatura che nessuno in studio ha rivisto, il giudizio del revisore è formalmente sul PDF ma sostanzialmente esposto alle differenze del file machine-readable. Nei Paesi Bassi, dove il deposito KvK è esso stesso il bilancio (non una rappresentazione successiva), il problema è più evidente; in Italia è coperto dalla finzione del PDF "originale," ma il rischio sostanziale resta.
La zona grigia: quando l'OIC non ha un elemento IFRS pulito
Qui vive il giudizio. Prendiamo un cliente edile bolognese, ricavi €35M, che applica gli OIC e deposita XBRL-Italia. Tra le voci di stato patrimoniale c'è una rimanenza di "Lavori in corso su ordinazione" (OIC 23) per €4,2M, valutata con il criterio del costo di commessa. Nella tassonomia XBRL-Italia esiste un elemento dedicato e corrisponde direttamente. Tutto a posto.
Stesso cliente, però, ha ottenuto un finanziamento agevolato pubblico con vincolo di destinazione, contabilizzato come "altro debito" in attesa di una qualificazione tecnica più precisa. La direzione non sa se trattarlo come contributo, debito, o "patrimonio di terzi." Il software della società di servizi ha mappato la voce sotto "Altri debiti tributari e previdenziali" perché era l'elemento più vicino disponibile. Il contributo non è tributario né previdenziale.
Cosa facciamo? Le opzioni sono:
- accettare la mappatura del fornitore software perché "il PDF di bilancio mostra correttamente la voce nei prospetti, la tassonomia è uno strumento di comunicazione tecnica, non un sostituto del bilancio"; - contestare la mappatura e chiedere una rielaborazione perché l'elemento tassonomico è sostanzialmente errato e qualunque utente esterno (CCIAA, Agenzia delle Entrate, banca dati Cerved) leggerà un debito tributario inesistente; - accettare la mappatura ma documentare in carta di lavoro la limitazione, segnalandola eventualmente al collegio sindacale ai sensi dell'art. 2403-bis C.C. nel caso di sistema dualistico.
A noi sembra che, qualora l'elemento tassonomico produca un'informazione contrastante con la sostanza della voce, il revisore non possa limitarsi a tickare. Però "qualunque elemento contestato" è un'asticella troppo alta per lo studio di provincia con compensi irrisori che fa cinquanta bilanci a maggio.
Il disaccordo legittimo: due partner, due risposte
Il Partner A direbbe: la tassonomia è un fatto tecnico, gestita dal cliente e dal suo fornitore software; il revisore si occupa del bilancio nei suoi prospetti formali, non della rappresentazione machine-readable; chiedere riconciliazione di mappatura è uscire dal mandato e moltiplicare ore non recuperabili.
Il Partner B direbbe: il bilancio depositato è quello che esiste nei registri pubblici; se la mappatura altera il significato di voci materiali, il revisore sta firmando su un documento e ne sta diventando responsabile di un altro; per le voci materiali servirebbe una verifica indipendente di coerenza, non l'accettazione passiva del file generato dal software house.
Entrambe le posizioni hanno fondamento. Il Partner A si appoggia al perimetro letterale del mandato e all'economia dell'incarico; il Partner B si appoggia all'ISA Italia 315 e a un'interpretazione sostanziale del giudizio. A noi convince di più la posizione del Partner B per le voci che superano la significatività operativa, ma riconosciamo che applicarla a tappeto su tutti i clienti del portafoglio non è praticabile.
L'incentivo perverso: perché in Italia la qualità dei dati XBRL è quella che è
Il deposito XBRL alla CCIAA è in larghissima parte automatizzato dalle case software (TeamSystem, Zucchetti, Sistemi, e simili). Il revisore riceve il file già generato, spesso con la mappatura già impostata su template ereditati. Aprire il file, ricostruire la mappatura, contestare un elemento richiede tempo che non è coperto dai compensi.
Il risultato è strutturale: il revisore ticka senza guardare la mappatura concettuale, perché ogni minuto che spende lì è un minuto sottratto a procedure più visibili al partner, alla review interna, all'eventuale ispezione del MEF. La pressione non viene dal revisore pigro. Viene dal fatto che il sistema premia la firma rapida e non differenzia la qualità del fascicolo sul reporting digitale. La busy season fa il resto.
Nei Paesi Bassi questa pressione esiste pure, però la SBR è il bilancio (non una rappresentazione collaterale), e il KvK come ricevente è più visibile dell'omologa italiana. La conseguenza è che i revisori olandesi, in media, dedicano qualche ora in più al controllo della mappatura, perché un errore lì è un errore sul deposito ufficiale e non un errore "tecnico secondario."
Esempio pratico, con la complicazione vera
Cliente: Bianchi Costruzioni S.p.A., Bologna, ricavi €35M, OIC, deposito XBRL alla CCIAA tramite TeamSystem; ha anche una controllata operativa olandese (BV) che deposita SBR via Logius. Il bilancio consolidato non è obbligatorio per soglie ma viene preparato ai fini gestionali.
Fase 1, comprensione del sistema. Si chiede al controller la lista di mappatura conti-tassonomia XBRL-Italia. Risposta: "ce la dà il fornitore software, non l'abbiamo mai aperta." Si chiede l'evidenza dell'ultima review interna. Non c'è. Annotazione in carta di lavoro SBR-01: assenza di controllo di mappatura interno; rischio che la mappatura sia ereditata da template del fornitore senza valutazione specifica delle voci dell'esercizio.
Fase 2, test della mappatura. Si selezionano le 12 voci più significative (totale coperto €28,3M, 81% dell'attivo) e si verificano contro il bilancio di verifica. Undici tornano. La dodicesima (il finanziamento agevolato di cui sopra) risulta mappata sotto un elemento tassonomico che la qualifica come debito tributario. Annotazione SBR-02: eccezione identificata; potenziale informazione fuorviante per utenti esterni.
Fase 3, complicazione. Il controller risponde che il fornitore software non offre l'elemento "altro debito non qualificato" nel template standard CCIAA, e che cambiare l'elemento richiederebbe l'attivazione di un modulo a pagamento. Il CFO vorrebbe lasciare la mappatura com'è. Il collegio sindacale, interpellato, chiede se il revisore ritenga la voce "materiale" ai fini del giudizio.
Fase 4, decisione. Il finanziamento è €1,8M, sotto la significatività di pianificazione (€2,1M) ma sopra la significatività specifica per le voci di indebitamento (€900k). Si ritiene che la mappatura, pur non alterando il bilancio nei prospetti, comunichi all'esterno un'informazione errata su una voce significativa per l'analisi del merito creditizio. Si propone alla direzione la correzione tramite mappatura a "Altri debiti, verso altri" (elemento esistente). La direzione accetta. Annotazione SBR-03: correzione applicata pre-deposito.
Cosa abbiamo imparato: la differenza tra firmare e firmare con consapevolezza, su questo specifico punto, sta in quattro ore di lavoro che il fornitore software non aveva fatto e che nessuno avrebbe scoperto se non avessimo aperto il file.
Insight di secondo ordine
La qualità dei dati strutturati italiani non migliorerà finché il deposito XBRL resterà percepito come adempimento tecnico secondario rispetto al PDF di bilancio. Nei Paesi Bassi il salto di qualità è arrivato quando la SBR è diventata l'unico canale di deposito, eliminando il PDF come "vero bilancio." In Italia siamo nella fase intermedia: due rappresentazioni coesistono, una è quella su cui si firma e l'altra è quella che alimenta i sistemi pubblici. Finché coesistono, l'incentivo a guardare la seconda è basso.
Il MEF avvierà i propri controlli di qualità sulla revisione legale. Quando arriveranno alle voci materiali del fascicolo sul reporting digitale, alcuni studi scopriranno che le carte erano leggere e che la mappatura tassonomica non era mai stata oggetto di evidenza autonoma.
Checklist pratica per il revisore italiano
1. Ottenere la lista di mappatura conti-tassonomia XBRL-Italia (per le non-EIP) o ESEF (per le EIP) dal cliente, con indicazione di chi l'ha predisposta e quando è stata rivista. 2. Verificare che le voci materiali del bilancio siano mappate su elementi tassonomici sostanzialmente coerenti, non solo formalmente accettati dal validatore. 3. Per le EIP, verificare la conformità alla tassonomia ESMA per i prospetti consolidati IFRS, comprese le note "block tagged" secondo il Regolamento UE 2018/815. 4. Documentare le eccezioni identificate e la loro risoluzione, indipendentemente dalla loro materialità contabile, perché alimentano basi dati pubbliche. 5. Confrontare il file effettivamente depositato (CCIAA, ESMA, Logius per controllate olandesi) con il bilancio approvato dall'organo amministrativo, per accertare assenza di alterazioni post-approvazione. 6. Valutare se la pipeline di generazione del file (gestionale → tassonomia → validatore → deposito) presenti rischi specifici di IT general controls ai sensi dell'ISA Italia 315.
Contenuti correlati
- Glossario ISA 315 - Comprensione dell'entità: definizioni e requisiti per la comprensione dell'ambiente di controllo interno - Calcolatore di significatività: strumento per determinare le soglie applicabili ai test sui sistemi informativi - Guida ISA 330 - Procedure di validità: procedure responsive ai rischi identificati nei sistemi automatizzati