Indice dei contenuti
1. La posizione diffusa e dove diverge 2. Quattro competenze che servono davvero 3. Caso pratico: quando l'analytics apre piu domande di quante ne chiuda 4. Formare il team: centralizzato o distribuito 5. Dove il budget incontra la popolazione completa 6. Errori ricorrenti nei fascicoli che vediamo
La posizione diffusa e dove diverge
L'ISA Italia 315 (Revised) richiede al revisore di identificare i rischi di errore significativo attraverso la comprensione dell'entita e del suo ambiente, incluso il sistema informativo. L'ISA Italia 520 regola le procedure di analisi comparativa. L'ISA Italia 330 chiede risposte ai rischi coerenti con la valutazione. Nessuno dei tre principi prescrive uno strumento specifico. Tutti e tre presuppongono che il revisore abbia formulato un'aspettativa prima di interrogare i dati.
Secondo la ricerca EY Global Audit Analytics Survey 2023, il 78% degli studi medio-piccoli considera l'analytics una priorita, ma solo il 31% ha investito in formazione dedicata. Il dato viene citato regolarmente come conferma che serve piu formazione tecnica. La lettura e parziale. Nei fascicoli che vediamo, il problema non e che il senior non sappia scrivere una query SQL. Il problema e che lancia il test senza aver formulato l'aspettativa: si ottiene un output, lo si allega, il reviewer non trova tracce del ragionamento che dovrebbe precedere il run.
Cosa succede davvero quando lo studio compra lo strumento
Un partner firma il contratto annuale con CaseWare IDEA. Il team segue le due giornate di training. Torna in studio e usa IDEA per gli stessi test che prima faceva con Excel: duplicati fattura, gap nella numerazione, totale importi per fornitore. Non perche IDEA non sappia fare altro. Perche l'engagement e pianificato con le stesse ore di Audit Work Program dell'anno precedente, e quelle ore prevedevano campionamento, non analisi di popolazione. Il budget copre 60 ore di "sostanziale ricavi." L'analytics su popolazione completa ne richiederebbe 90 tra preparazione del dato, definizione della soglia, indagine delle eccezioni, documentazione. La direzione dello studio non ha ricontrattato il forfait con il cliente. Il senior, quindi, usa lo strumento nuovo per riprodurre la vecchia procedura in meno tempo, non per cambiare la procedura.
Non e un problema di competenza tecnica. E un problema di economia dell'incarico.
Quattro competenze che servono davvero
Non campionare quando si puo interrogare la popolazione
L'ISA Italia 530.A3 riconosce che l'esame della popolazione completa possa risultare piu efficiente del campionamento quando i dati sono disponibili in formato elettronico. La parola chiave non e "efficiente." E "quando i dati sono disponibili." Nei fascicoli che vediamo, il senior scarica un export dal gestionale, scopre che le date contabili sono in formato testo, tre campi sono concatenati, i resi sono registrati come importi positivi con un flag separato, e il tempo per pulire il dato supera quello del campionamento tradizionale. La competenza non e sapere che si puo testare il 100%. E sapere quando conviene.
Stratificare per la dimensione che racconta il rischio, non per importo
La stratificazione classica divide per scaglioni di importo. Si ottiene una matrice con gli importi maggiori concentrati nella fascia alta. Fin qui niente di nuovo. La stratificazione che produce valore d'audit usa dimensioni che il campionamento per importo non vede: utente inseritore, giorno della settimana, orario di registrazione, tipologia di documento. Un fornitore che rappresenta il 2% del volume ma il 15% degli storni e un pattern che emerge dalla dimensione "utente + tipo documento," non dallo scaglione di importo. La direzione non ti dira mai che il problema e concentrato in un utente specifico. Il dato lo dice, se si sa come interrogarlo.
Serie storiche che smascherano la stagionalita raccontata
La procedura tradizionale fotografa un momento. L'analytics mostra l'evoluzione. Ricavi che crescono linearmente per undici mesi e schizzano a dicembre vanno letti contro la spiegazione della direzione. Se il management racconta "picco natalizio" e il cliente produce componenti industriali B2B, la spiegazione non regge. Se produce abbigliamento, probabilmente si. L'analisi temporale serve a testare la plausibilita del racconto, non a sostituirlo.
Benford come indicatore, mai come prova
La Benford's Law prevede la distribuzione delle prime cifre nei dataset naturali. Deviazioni significative segnalano anomalie da indagare. Non sono prova di frode e nessun reviewer prendera mai per buono un fascicolo che tratta Benford come conclusione. La legge funziona solo su dataset con almeno 1.000 osservazioni che coprono piu ordini di grandezza. Applicata a 300 fatture di un cliente piccolo, produce rumore. Applicata a 50.000 transazioni di una SPA manifatturiera, pone domande.
Caso pratico: quando l'analytics apre piu domande di quante ne chiuda
Contesto: Manifatture Tessili Lombarde S.p.A., ricavi EUR 45M, 35.000 fatture di vendita nell'esercizio, ciclo produttivo stagionale (picco novembre-dicembre). Il controller fornisce un export completo in formato CSV. Il budget dell'area ricavi e 80 ore per il senior e 20 per l'assistant.
Preparazione del dato (otto ore che non erano nel budget)
Si importa il file in Power Query. Le date sono in formato testo "gg/mm/aaaa" con quattro righe in formato "aaaa-mm-gg" (export corrotto da una precedente migrazione). Gli importi hanno il punto come separatore di migliaia in 34.000 righe e la virgola in 1.000 (fatture emesse da una sede estera riconvertite). Tre campi sono concatenati con un separatore "|" diverso in due periodi dell'anno. La pulizia richiede otto ore. Non erano previste. Il senior decide di procedere comunque perche altrimenti l'intera pianificazione salta.
Nota documentazione: la metodologia di pulizia del dato va tracciata nella carta di lavoro A01 con riconciliazione degli importi totali al saldo contabile. Senza questa riconciliazione, qualunque conclusione successiva e contestabile.
Test di duplicazione e Benford (quattro ore, due findings)
Il test di duplicazione individua tre fatture con numerazione saltata. Vanno indagate: in due casi sono annulli formalmente documentati, nel terzo no. Il test di Benford sulla prima cifra mostra uno scostamento sulla cifra 7 del 3,2% (attesa 5,8%, osservata 9,0%). Va indagato.
Dove il test prende una piega che il budget non aveva previsto
Si interroga il dato: le fatture che iniziano per 7 sono concentrate in un range di importo tra EUR 700 e EUR 799 e provengono tutte da un segmento di clientela specifico (retail di piccole dimensioni nel Sud Italia). La direzione ha attivato uno sconto promozionale a volume durante l'anno che porta molte fatture in quella fascia. Plausibile, ma il senior non lo sapeva: non era in alcun verbale del consiglio di amministrazione letto in fase di pianificazione. La domanda diventa: c'e un incentivo di vendita al team commerciale che premia quel segmento? Se si, qual e il rischio di cutoff o di fatture emesse per raggiungere target?
Il reviewer, leggendo il fascicolo, probabilmente chiedera di espandere il test. Il senior lo sa. E gli restano dodici ore nel budget della sezione ricavi.
L'anomaly detection che produce 40 flag e 38 falsi positivi
Lo script di anomaly detection, tarato per flaggare fatture con aliquota IVA fuori dal pattern atteso del cliente, produce 40 osservazioni. Alla revisione manuale, 38 risultano false positive: sono operazioni in reverse charge (art. 17 DPR 633/72, cessioni intracomunitarie e appalti in edilizia) con aliquota a zero legittimamente applicata. Il revisore deve ritarare la soglia, aggiornare la documentazione del test, ripetere il run. Non era nel budget.
Cosa succede davvero: il senior, a questo punto, affronta un bivio che il corso di formazione non affrontava. Puo documentare le 38 false positive come "rumore da disciplina IVA," chiudere il test con le 2 anomalie genuine, espanderle a test sostanziale, e sforare il budget di 14 ore. Oppure puo abbassare la sensibilita del test per non generare cosi tanto rumore al prossimo run, sapendo che la soglia piu permissiva rischia di mancare anomalie vere. La ISA Italia 330 chiede risposte proporzionate al rischio. Non chiede risposte proporzionate al forfait. La tensione e reale e non e risolvibile con piu formazione tecnica.
Conclusione operativa: l'incarico chiude in 98 ore contro le 80 pianificate. La perdita viene assorbita dal margine dell'engagement. L'anno successivo, al momento di preventivare, il partner alza il forfait del 4%. Il cliente obietta. Si negozia al 2%. Il problema strutturale non si risolve.
Formare il team: centralizzato o distribuito
Esiste un dibattito legittimo nel settore sul modello organizzativo. Due posizioni difendibili:
Modello centralizzato. Lo studio costruisce un piccolo "analytics lab" (due o tre persone, una delle quali con formazione statistica) che supporta tutti gli engagement. Vantaggio: profondita tecnica, riuso di script, qualita della documentazione. Svantaggio: il lab e un collo di bottiglia nella busy season. Gli engagement piu piccoli non ci arrivano perche i partner non vogliono assorbire il costo. Il senior sull'incarico non impara a pensare in termini di popolazione, perche delega.
Modello distribuito. Ogni senior riceve formazione base (SQL, Power Query, un tool di analytics) e la usa autonomamente sui propri incarichi. Vantaggio: velocita di esecuzione, l'analytics si integra nel ragionamento d'audit del senior. Svantaggio: la qualita tecnica e eterogenea. Nei fascicoli che vediamo con modello distribuito, alcuni test sono brillanti, altri riproducono procedure manuali in Python senza aggiungere valore. Il reviewer deve leggere codice ogni volta, e raramente sa farlo.
Nella nostra esperienza, nessuno dei due modelli puri funziona per uno studio mid-tier sotto i 50 professionisti. Il modello ibrido piu sensato: un referente analytics per ufficio (non full-time, 30-40% del tempo dedicato), formazione base diffusa sugli strumenti, escalation verso il referente quando il test richiede piu di quattro ore di progettazione. Il referente tiene la libreria degli script ricorrenti e fa la peer review. Funziona perche distribuisce l'esecuzione ma centralizza la qualita.
Dove il budget incontra la popolazione completa
La ragione per cui i progetti di data analytics falliscono negli studi mid-tier non e tecnologica. E che l'analytics rivela piu rischi di quanti il budget permetta di testare: il senior sceglie di non farla perche, trovato l'anomalo, deve indagarlo, e nessuno paga l'indagine. Finche il forfait non distingue tra "procedura base" e "procedura estesa in presenza di anomalia rilevata," l'incentivo e eseguire la procedura che minimizza la probabilita di trovare qualcosa.
Questo non e un argomento per fare meno analytics. E un argomento per ricontrattare l'engagement quando l'approccio cambia. Il CNDCEC, nelle linee guida sull'uso delle tecnologie in revisione, indica che l'uso di tecniche di analisi dati non sostituisce il giudizio professionale ma ne modifica la natura delle procedure. Modificare la natura delle procedure vuol dire anche modificare il preventivo. La maggior parte degli studi mid-tier non lo fa, perche il cliente compara sul prezzo e il collega sul territorio offre il forfait basso. Si resta incastrati.
Fasi realistiche di adozione (ordine di grandezza, non piano di progetto)
Primi sei mesi. Audit delle competenze Excel del team. Si identifica chi sa gia scrivere tabelle pivot con campi calcolati e formule INDEX/MATCH. Su questa base si sceglie un incarico pilota (cliente con dati puliti, non il piu complesso). Si misura l'incarico pilota rispetto allo stesso dell'anno precedente in ore, in anomalie identificate, in commenti del reviewer.
Mesi sei-diciotto. Si sceglie uno strumento in base alla dimensione media degli export clienti e all'integrazione col software di compliance dello studio. IDEA e ACL hanno curva di apprendimento piu alta ma maggiore stabilita su dataset grandi. Power Query copre la maggior parte dei casi sotto il milione di righe. La scelta di strumento e secondaria rispetto alla progettazione del test: uno studio che compra IDEA senza aver rivisto i propri Audit Work Program sprecha la licenza.
Mesi diciotto-trentasei. Si costruiscono librerie di script per settori ricorrenti nel portafoglio. Retail: aging inventario, rotazione per SKU, margin analysis per categoria. Manifatturiero: cost variance, resa produttiva, scarto. Servizi: riconoscimento ricavi su progetti, utilizzo risorse. Ogni script va accompagnato da documentazione d'uso e soglie tarate sul settore.
Errori ricorrenti nei fascicoli che vediamo
Volume scambiato per valore
Analizzare milioni di transazioni non produce valore se l'analisi e superficiale. Nel fascicolo, un test condotto su 1.000.000 di righe con una conclusione di tre righe di prosa e piu debole di un test su 10.000 righe con quattro pagine di ragionamento sulle eccezioni. Il reviewer legge la conclusione, non la query.
Qualita del dato ignorata
L'analytics amplifica gli errori del dato di partenza. Nei casi che vediamo, l'export del cliente ha almeno un problema strutturale nel 70% degli incarichi: campi formattati inconsistentemente, saldi non riconciliati al bilancio, finestre temporali tagliate male. La pulizia richiede tempo che il budget non prevede. La tentazione e procedere "tanto non sara cosi grave." A volte lo e.
Curva d'apprendimento sottovalutata
Il team avra bisogno di sei-dodici mesi per diventare operativo, non tre. La produttivita scende per il primo anno su incarichi pilota. La direzione dello studio deve mettere in conto questo costo nel business plan, altrimenti il progetto viene abbandonato dopo la prima busy season (gennaio-maggio) quando i senior tornano a metodi familiari sotto pressione.
Nessuna documentazione della domanda
Il problema ricorrente nei fascicoli: il test c'e, l'output c'e, la conclusione c'e. Manca il ragionamento tra l'output e la conclusione. Perche quell'anomalia e stata considerata rumore? Perche la soglia e stata fissata a quel livello? Chi ha approvato la ritaratura dopo i primi falsi positivi? Se il fascicolo non risponde, non reggera a un controllo qualita CONSOB. Le carte erano leggere e' il rilievo piu frequente nei provvedimenti disciplinari sulle tecniche analitiche.
Link correlati
- Calcolatore di materialita - Per dimensionare correttamente le soglie prima del test - Guida ISA 530 campionamento - Quando analytics e quando campionamento - Template analisi aging crediti - Strumento Excel per una delle analytics piu frequenti