La falla ricorrente: usare gli output del CM del cliente come evidenze del revisore
Il revisore legale non deve limitarsi a raccogliere i report del sistema di monitoraggio del cliente e allegarli al fascicolo di revisione. Deve testarne il disegno, l'efficacia operativa e la tenuta del perimetro IT a cui si appoggiano. Quando le carte sono leggere su questo punto, la reazione della CONSOB in sede ispettiva è prevedibile: richiamo all'ISA Italia 500 (inidoneità dell'evidenza) e all'ISA Italia 315.A77-A94 (mancata valutazione dei controlli IT-dependent). Si tratta della stessa famiglia di rilievi che compare nelle delibere sanzionatorie più recenti in materia di stime e di riciclaggio, anche se applicata a un oggetto diverso.
La definizione serve, ma viene dopo. Il continuous auditing (CA) è una metodologia di revisione: il revisore progetta test che operano su dati del cliente in modo automatizzato e continuativo, producendo evidenze probatorie utilizzabili ai sensi dell'ISA Italia 500. Il continuous monitoring (CM), invece, è un controllo interno automatizzato che la direzione utilizza per sorvegliare transazioni e processi. Il CM produce dashboard e eccezioni per il management, non evidenze per il revisore. La distinzione non è accademica: determina chi possiede l'evidenza, chi la governa, e chi ne risponde.
Cosa significa nella pratica: il revisore che inserisce nel fascicolo un exception report del sistema CM del cliente senza testare i controlli generali IT che producono quel report sta commettendo lo stesso errore descritto dal paragrafo 4 dell'ISA Italia 500. L'evidenza ha un'origine, e quell'origine non è stata validata.
Il sistema duale e la mappatura delle responsabilità
Qui interviene la specificità italiana che i manuali internazionali ignorano. Il CA e il CM non si collocano nello stesso punto della catena di controllo. Il revisore legale testa i controlli automatizzati del cliente (inclusi quelli di CM) come risposta al rischio identificato ex ISA Italia 315, nei termini dell'ISA Italia 330.8. Il collegio sindacale, invece, vigila sull'adeguatezza del sistema di controllo interno ai sensi dell'art. 2403 C.C., e in questa vigilanza il CM rientra pienamente. Quando il sindaco chiede al revisore se il CM del cliente funziona, sta facendo una domanda legittima. La risposta non è la stessa che il revisore userebbe per la propria strategia di risposta al rischio.
Cosa significa nella pratica: nella matrice dei controlli si documenta due volte il CM, con finalità diverse. Una riga serve alla strategia di risposta del revisore (ISA Italia 330). Una riga separata serve al dialogo con il collegio sindacale ex art. 2403 C.C. I due documenti non coincidono, e non dovrebbero coincidere.
Cosa è cambiato davvero, e cosa non è cambiato
Gli ERP moderni (SAP, Oracle, Microsoft Dynamics nella versione italiana) incorporano controlli configurabili che dieci anni fa richiedevano sviluppi ad hoc. I dati si estraggono via API. I tool di data analytics leggono tracciati che prima erano inaccessibili. Questo è il cambiamento tecnologico. La domanda che molti studi medio-piccoli non si fanno è un'altra: se la tecnologia è matura, perché il CA non è ancora la norma?
Si osserva che la risposta non è tecnica. È economica e organizzativa. Nel corpus dei forum italiani ricorre il tema dei compensi irrisori, e ricorre per una ragione sostanziale: un'attività di CA richiede senior con competenze IT che, a compensi medi di mercato, non stanno sui fascicoli di revisione più di qualche ora. Il resto del lavoro viene fatto da junior durante la busy season, e un junior non progetta routine di CA. Testa, tutt'al più, i controlli del CM del cliente quando il manager gli dice di farlo. Questa è la vera architettura del fieldwork italiano, al di là della narrativa tecnologica.
C'è anche un secondo fattore, meno discusso. I sistemi IT dei clienti italiani di fascia medio-bassa (tipicamente SRL con ricavi sotto i 50M) non sempre sono configurati con il livello di maturità che il CA richiede. Le interfacce fra software gestionali e contabilità non sempre si parlano. In questi casi il CA non è infattibile per ragioni tecniche, è infattibile perché costruire la fiducia nell'infrastruttura costerebbe al revisore più di quanto il compenso copra.
L'obiezione legittima: il CA come cerimonia inefficiente
Esiste un'obiezione seria al CA che va presa sul serio, non confutata per default. L'obiezione suona così: su clienti con controlli IT immaturi, il CA rischia di diventare una cerimonia costosa che produce molti alert, pochi dei quali rilevanti ai sensi della significatività fissata in pianificazione. Il revisore insegue eccezioni che sono rumore, non segnale. A quel punto il testing sostantivo tradizionale, ben mirato, resta più efficiente e più difendibile davanti al reviewer.
Qualora il revisore ritenga che i controlli generali IT del cliente non siano sufficientemente robusti, l'ISA Italia 315.A91-A94 indica di non fare affidamento sui controlli automatizzati. In quei casi il CA come strategia di risposta è semplicemente inappropriato, e insistere sarebbe un errore di giudizio professionale. La posizione contraria (il CA è sempre preferibile perché copre il 100% della popolazione) è un'affermazione che ignora il costo di validazione dell'infrastruttura sottostante. Il 100% di copertura su dati la cui integrità non è testata non è una copertura migliore del 15% su dati estratti manualmente e riconciliati.
Cosa significa nella pratica: la scelta fra CA e testing tradizionale va motivata nel memorandum di pianificazione, non assunta. E la motivazione va ancorata all'esito del testing dei controlli generali IT ai sensi dell'ISA Italia 315.
Esempio pratico: Mediterranea Logistics S.r.l.
Mediterranea Logistics S.r.l., operatore con sede a Napoli, ricavi per EUR 28M, ha implementato un sistema integrato: CA sui ricavi lato cliente e CM sui costi carburante. Il CA analizza tutte le fatture di trasporto contro contratti e listini approvati. Il CM confronta i prezzi carburante con indici Reuters e genera exception report settimanali quando lo scostamento supera il 5%. La direzione finanziaria sostiene che il sistema dia al revisore piena assurance. Il revisore non può accettare questa affermazione senza testarla.
Step 1: Comprensione del sistema (ISA Italia 315.12)
Si documenta l'architettura del sistema, i controlli configurati, la frequenza di esecuzione e i report generati nella sezione "Understanding of IT Environment" della carta di lavoro. La complicazione, nel caso Mediterranea, è che il sistema CM sui costi carburante riceve dati da un provider esterno (Reuters) via API gestita da un fornitore terzo. Si ha quindi un controllo a catena: Reuters → provider → ERP cliente → exception report. Il revisore deve valutare ogni snodo, non solo l'output finale.
Step 2: Identificazione dei controlli chiave
Si elenca ogni controllo automatizzato nella matrice dei controlli, classificandolo come IT-dependent ai sensi dell'ISA Italia 315.A77. I controlli del CA sui ricavi includono: verifica automatica di prezzi contro contratti, controllo di completezza attraverso matching con documenti di trasporto, test di accuratezza IVA. Per ciascuno si distingue fra controllo applicativo (configurato nell'ERP) e controllo generale IT (gestione accessi, change management, backup). Senza i secondi, i primi non sono affidabili.
Step 3: Testing dell'efficacia operativa (ISA Italia 330.8)
Per il CA sui ricavi si seleziona un campione di 40 fatture dal periodo gennaio-settembre, si riesegue il controllo automatizzato e si verifica che le eccezioni siano state rilevate correttamente. Per il CM sui costi, si analizzano gli alert generati nei nove mesi e si verifica l'adeguatezza del follow-up della direzione. Decorrenza del testing: la nostra policy di studio impone di completarlo entro il 31 ottobre, perché dopo quella data la busy season rende irrealistico attendersi disponibilità dell'IT del cliente.
Qualora emerga che due alert del CM sono stati chiusi senza evidenza di analisi (capita più spesso di quanto non si ammetta), si documenta l'eccezione e si riduce l'affidabilità attesa sul controllo. Non si chiude l'incidente. Lo si fa risalire.
Step 4: Modifiche alle procedure sostantive
Sulla base dell'affidabilità dimostrata, si riduce il campione per il testing dei ricavi di circa il 30%, concentrando il testing sostantivo sui costi su categorie non coperte dal CM (manutenzioni, consulenze, personale). La riduzione è giustificata solo se i controlli generali IT hanno superato il testing. Altrimenti si torna al campionamento tradizionale sull'intera popolazione.
Checklist operativa per la valutazione CA/CM
1. Mappare l'architettura tecnologica completa — identificare sistemi, interfacce, provider terzi e controlli automatizzati configurati ai sensi dell'ISA Italia 315.12. Non fermarsi all'ERP; includere gli snodi esterni.
2. Testare i controlli generali IT prima dei controlli applicativi — se i primi non reggono, i secondi non sono affidabili e il CA non è una risposta valida al rischio (ISA Italia 315.A91-A94).
3. Distinguere nella matrice fra CA e CM — il CA produce evidenze per il revisore, il CM produce informazioni per la direzione. Non sono intercambiabili. Nella documentazione tale distinzione va resa visibile al reviewer e al collegio sindacale.
4. Documentare l'impatto sulla strategia di risposta — specificare come l'affidamento sui controlli automatizzati modifichi natura, tempistica ed estensione delle procedure sostantive. La riduzione del campione va motivata, non assunta.
Errori ricorrenti che emergono in sede di review
- Confondere CA con audit data analytics occasionali. Il CA opera in modo continuativo durante l'anno, non solo durante il fieldwork finale. Un data analytics eseguito una volta a ottobre non è CA, qualunque cosa dica il software. - Assumere che il CM sia affidabile senza testing. I controlli automatizzati richiedono testing ai sensi dell'ISA Italia 330 come qualsiasi altro controllo interno. Le carte leggere su questo punto sono il primo rilievo del reviewer. - Sottovalutare la catena IT. Sistemi CA/CM richiedono comprensione di architettura dati, interfacce, provider terzi e controlli applicativi ai sensi dell'ISA Italia 315.A77-A94. Fermarsi al singolo software è un errore di perimetro.
Risorse correlate
- Glossario: Data Analytics nella Revisione — definizioni tecniche e differenze fra analytics tradizionali e continuous auditing - Calcolatore ISA 315 — strumento per documentare la valutazione dei controlli IT-dependent e automatizzati - [FUTURE POST: ISA Italia 330 e testing dei controlli automatizzati] — guida al testing dell'efficacia operativa dei controlli IT