Indice
1. La prassi difettosa che tutti conosciamo 2. Cosa richiede davvero l'ISA Italia 330 sul periodo 3. Dove vive il giudizio: quanti touch intermedi e come campionarli 4. Automatizzato puro o semi-automatizzato: perché la distinzione cambia tutto 5. Esempio pratico: Tessuti Industriali Milano e il rollover di luglio 6. Risposta al collega: "ma tutti testano a fine anno" 7. L'incentivo perverso: budget tempo e fee economics 8. Risorse correlate
La prassi difettosa che tutti conosciamo
Partiamo da quello che succede davvero. Il team senior programma i test CUECs in seconda settimana di gennaio, sul sistema in produzione al 31 dicembre. Screenshot, qualche transazione tickata, un paragrafo di conclusione copiato dal fascicolo dell'anno prima. Se va peggio, le carte si scrivono dopo — espressione che nel nostro studio si usa con una certa ironia, perché tutti la conoscono e nessuno l'ammette in una peer review. Il fascicolo formalmente c'è. La sostanza è che nessuno ha verificato se il controllo di blocco credito abbia funzionato a marzo, a giugno o a settembre, quando la direzione ha riconfigurato le soglie tre volte.
Il problema non è teorico. La Delibera CONSOB n. 22436/2022 sul caso di un network medio-grande ha sanzionato proprio questa dinamica: "carenze afferenti l'attività di revisione contabile" per assenza di evidenze sull'efficacia operativa dei controlli IT per il periodo su cui si è fatto affidamento. Traduzione del professionista: le carte erano leggere, e la CONSOB ha letto il fascicolo con attenzione.
Noi revisori abbiamo un interesse pratico a prendere sul serio la questione adesso, prima che arrivi un controllo del MEF. I controlli qualitativi su studi non-EIP sono partiti nel 2025 e stanno arrivando ai network regionali. Un rilievo sui CUECs è tra i più semplici da contestare perché è documentale: o il fascicolo mostra test intermedi con data, sample e conclusione, o non li mostra.
Cosa richiede davvero l'ISA Italia 330 sul periodo
L'ISA Italia 330.10 impone di ottenere elementi probativi "per il periodo su cui il revisore intende fare affidamento". Non dice quante volte testare. Questa è la zona grigia in cui vive il giudizio, e dove le letture divergono tra partner.
Il paragrafo A42 chiarisce un punto che spesso si legge distrattamente: per i controlli automatizzati, "una volta che sia stato determinato che il controllo opera in modo efficace", si può ridurre l'estensione dei test, purché gli ITGC sottostanti siano stati testati e risultino efficaci. Qualora però il revisore rilevi un cambiamento nel controllo automatizzato, nell'ambiente IT, o negli ITGC che lo supportano, la riduzione non si applica e occorre ri-testare.
Sul fronte italiano, il collegio sindacale entra in scena per il suo dovere di vigilanza sull'adeguatezza del sistema di controllo interno ai sensi dell'art. 2403 C.C. Se il revisore legale rileva un fallimento del CUEC e non lo comunica al collegio, l'art. 2409-septies C.C. sul flusso informativo reciproco scatta. Non è un dettaglio procedurale: il coordinamento revisore–collegio è territorio statutario, e le delibere CONSOB lo citano sistematicamente quando sanzionano la qualità inadeguata dell'incarico ai sensi del D.Lgs. 39/2010.
Cosa succede davvero nella pratica. Quando in studio si discute "quante volte testare", la risposta onesta dipende da tre fattori: quanto sono stabili gli ITGC (se il cliente ha un change management maturo, il rischio di rollover non monitorato è basso), quanto è materiale il controllo per l'audit plan (un blocco credito su una popolazione MUS da EUR 40M pesa diversamente da una validazione di campo data), e quanto il budget lo consente (la variabile che nessuno cita nel memo ma che decide la prassi reale).
Dove vive il giudizio: quanti touch intermedi e come campionarli
Qualora l'ITGC sia stabile e non si rilevino cambi di release significativi, due touch intermedi più il test di fine esercizio costituiscono in genere la soglia minima difendibile. Uno all'inizio del periodo, uno dopo il primo rollover significativo, uno a chiusura. Sul campionamento di ciascun touch, ISA Italia 330.A27 rimanda alle tabelle di frequency-based testing: controllo che opera quotidianamente, sample minimo di 25; controllo che opera settimanalmente, sample di 5–10; controllo che opera trimestralmente (come molte riconciliazioni), sample di 2–3 per trimestre.
La nostra opinione, e qui serve dichiararla: due touch intermedi non bastano quando la release di sistema cambia un parametro di business logic (soglie di credito, matrici di approvazione, regole di three-way match). In quel caso ogni release è un nuovo controllo finché non si dimostra il contrario, e il test deve ripartire con walkthrough completo. La ragione è che il controllo automatizzato, a differenza del controllo manuale, non ha un "operatore" la cui competenza porti continuità: la continuità è la configurazione stessa.
Sul fascicolo di revisione, il rollover va tickato riga per riga con: - La data della release (dalla release note del cliente, non dalla data in cui il revisore ne è venuto a conoscenza) - Il parametro cambiato, con screenshot pre e post - Il walkthrough di una transazione post-release che confermi il nuovo comportamento - La conclusione sul se il controllo può essere considerato unitario o se va spezzato in pre e post
Il quarto punto è quello in cui l'IA cade costantemente. La direzione dirà che "è lo stesso controllo, solo con soglie aggiornate". Il revisore competente decide autonomamente.
Automatizzato puro o semi-automatizzato: perché la distinzione cambia tutto
L'ISA Italia 330 non codifica la distinzione, ma il paragrafo A29 la implica. Un controllo puramente automatizzato (three-way match in SAP che rifiuta la registrazione se la fattura supera la tolleranza configurata rispetto all'ordine) ha natura binaria: la configurazione è corretta o non lo è. Un test benchmark all'inizio del periodo, combinato con test efficaci sugli ITGC (change management, access, operations), può reggere l'intero anno se non ci sono release sulla business logic.
Il controllo semi-automatizzato è un animale diverso. Il sistema genera un report di eccezioni sulle fatture duplicate; una persona lo deve esaminare e disporre il rigetto. Qui l'efficacia dipende da due componenti separate: la logica di generazione del report (automatizzata) e la review umana (manuale). Il test deve coprirle entrambe, e la componente umana va campionata come qualunque controllo manuale su base frequenza, non su base point-in-time.
Il rischio pratico: team meno esperti applicano la logica del controllo puro anche al semi-automatizzato, testando solo il report generator. Nei fascicoli che vediamo, questa è la prima cosa che un inspection CONSOB rileva, e spesso chiude la discussione sull'affidamento.
Esempio pratico: Tessuti Industriali Milano e il rollover di luglio
Tessuti Industriali Milano S.r.l., produttore di tessuti tecnici per il settore automotive, ricavi EUR 28M, usa SAP S/4HANA per il ciclo order-to-cash. Il controllo rilevante: blocco automatico della spedizione se l'esposizione del cliente supera il credit limit approvato. Il revisore legale, fase di planning, identifica il controllo come chiave per le asserzioni di existence e valuation sul credito commerciale. L'audit plan prevede affidamento e riduzione delle procedure di validità.
Touch 1 — gennaio. Walkthrough completo. Screenshot della configurazione, benchmark su 25 transazioni selezionate dal log (20 bloccate correttamente, 5 non bloccate perché sotto limite). Test degli ITGC sottostanti: segregation of duties sui ruoli SAP (controllo del BASIS su chi può modificare i master data dei limiti), gestione degli accessi, change management. Tutto pulito. Si conclude che il controllo opera efficacemente al 15 gennaio.
Touch 2 — luglio. Il cliente comunica, durante la fase interim, che a maggio il consiglio ha approvato un nuovo modello di scoring del credito e che la release SAP del 12 luglio ha implementato i nuovi algoritmi. Punto di rottura. Si sospende l'affidamento sul periodo pre-release e si apre la questione: il controllo di luglio è ancora lo stesso controllo? Qui i partner dello studio non concordano.
Partner A sostiene che due test intermedi (uno pre-release, uno post-release con 10 transazioni ciascuno) siano sufficienti, perché la logica di blocco è identica — cambia solo la soglia. Il suo ragionamento: l'essenza del controllo è il meccanismo di blocco, non il parametro numerico che lo attiva.
Partner B sostiene che una release che cambi l'algoritmo di scoring richieda walkthrough completo post-release e un sample di 25 transazioni, perché il nuovo algoritmo potrebbe generare casi limite non previsti dalla configurazione vecchia. Il suo ragionamento: se il revisore non testa la nuova logica su una popolazione significativa, non sta testando il controllo attuale, sta testando il controllo di gennaio e assumendo che il nuovo sia equivalente.
Nella nostra esperienza, il Partner B ha ragione quando la release tocca la business logic che determina il blocco (soglie, matrici di rischio, scoring); il Partner A può avere ragione quando la release è cosmetica o infrastrutturale (UI, performance, security patch). Nel caso TIM S.r.l. si è andati con il Partner B. La decisione è costata 1,5 giorni di team senior e 0,5 giorni di IT auditor, impatto diretto sul budget dell'incarico.
Touch 3 — ottobre. Sample di 15 transazioni post-release Q3, focalizzato sui clienti con scoring cambiato tra luglio e ottobre. Tutte bloccate correttamente quando sopra soglia. Si conclude che il controllo post-12 luglio opera efficacemente.
Conclusione nel fascicolo: il controllo di blocco credito ha operato efficacemente per il periodo gennaio–12 luglio (versione pre-rollover) e per il periodo 13 luglio–31 dicembre (versione post-rollover). Il fascicolo documenta i due periodi separatamente. La conclusione sull'affidamento copre l'intero anno perché entrambi i periodi sono stati testati adeguatamente.
Documentazione: release note del cliente del 12 luglio archiviata nel fascicolo; screenshot pre e post dei parametri di scoring; walkthrough post-release con tre transazioni; conclusione del Partner dell'incarico sulla spezzatura del controllo.
Risposta al collega: "ma tutti testano a fine anno"
Sì, il test a fine esercizio è la prassi diffusa, e in parte si capisce perché. Nel nostro studio lo facciamo anche noi sui clienti piccoli, dove il rapporto costi-benefici non giustifica tre touch intermedi. Su una S.r.l. con ricavi EUR 4M e un ERP base senza rollover durante l'anno, il test unico regge. La concessione è genuina.
Però il problema è che la prassi si applica per inerzia anche ai clienti mid-market con ERP complessi e release trimestrali, dove invece l'ISA Italia 330.10 richiede uno sforzo diverso. L'alternativa concreta non è "testare cinque volte l'anno". È:
- Due touch intermedi più il test di fine esercizio sui controlli IT chiave identificati in risk assessment (ISA Italia 315.A73 e seguenti) - Test ITGC una volta l'anno, con walkthrough sui cambi di release - Test point-in-time estivo solo quando ITGC risultano stabili, non ci sono cambiamenti di sistema rilevati, e il controllo è puramente automatizzato
La divergenza con il collega è specifica, non generica: non stiamo dicendo che tutti sbaglino, stiamo dicendo che il test unico va riservato al contesto in cui è appropriato, e non usato come default.
L'incentivo perverso: budget tempo e fee economics
Perché la prassi difettosa persiste? Non è ignoranza. I senior sanno cosa dice l'ISA Italia 330.10. Il vero motore è il budget.
Un incarico di revisione su Tessuti Industriali Milano ha un fee dell'ordine di EUR 35.000–45.000 per uno studio mid-tier. Tre touch CUECs con coinvolgimento dell'IT audit valgono circa EUR 4.500–6.000 di costo interno. In uno studio a budget stretto, quel costo si mangia il margine. La tentazione di tickare tutto a gennaio post-closing e archiviare il fascicolo è strutturale, non patologica. I compensi irrisori denunciati dal MEF nei Rapporti 2024 e 2025 sono la stessa realtà vista dal lato del cliente: se la revisione viene pagata come un adempimento formale, il revisore è spinto a trattarla come tale.
Questa è l'onestà che manca nei manuali. Il revisore competente può fare il test full-period solo se il partner difende il budget davanti al cliente. Se il partner non lo difende, il senior che propone tre touch intermedi viene visto come inefficiente, non come rigoroso. La pressione arriva prima che la tecnica.
Noi l'alternativa la vediamo così: se il budget non regge il full-period testing, il revisore deve rivalutare l'affidamento (ISA Italia 330.17) e aumentare le procedure di validità fino a dove il rischio residuo lo richiede. Non si può avere l'affidamento ridotto e il budget stretto e la qualità richiesta dalla CONSOB. Una delle tre salta, e il revisore sceglie quale.
Risorse correlate
- Glossario ISA 330 — definizione completa dei requisiti per i test dei controlli - Calcolatore dimensionamento campioni — strumento per determinare le dimensioni dei campioni appropriate per i test dei controlli - ISA 315 e valutazione dei rischi informatici — come identificare i rischi IT che impattano l'efficacia dei CUECs