Controlli applicativi

Come funziona

I controlli applicativi non si valutano isolatamente, ma in combinazione con i controlli generali IT. Operano su due piani: prevenzione e rilevamento. Un controllo preventivo blocca il salvataggio di una transazione che viola una regola (per esempio, non si registra una fattura passiva con importo superiore all'ordine di acquisto accoppiato). Un controllo di rilevamento lascia salvare la transazione fuori parametri ma la flagga come eccezione, in coda di revisione manuale.

Secondo ISA Italia 315.29, il revisore comprende i controlli applicativi rilevanti per l'asserzione. La parola pesante e' "rilevanti". Non ogni controllo nel sistema entra nel fascicolo. Sono rilevanti i controlli che indirizzano rischi identificati ai sensi di ISA Italia 315.27. Una validazione sulla causale contabile diventa rilevante per la completezza delle spese di funzionamento solo se in sede di pianificazione si fosse identificato come rischio significativo la registrazione di costi su conti errati.

Cosa succede davvero. Si compila la matrice rischi-controlli elencando il controllo per identificativo di sistema (ad es. "Validation Rule VR-1047: SKU non presente in tabella prodotti attivi") e si indica l'asserzione mitigata. Poi si testa: prima, che la regola sia configurata come dichiara la direzione; seconda, che funzioni eseguendo transazioni di test che dovrebbero essere bloccate o flaggate; terza, che non esista uno storico di eccezioni non gestite tale da invalidare il controllo (per esempio, una procedura che permette agli utenti di forzare la registrazione di transazioni che il controllo avrebbe dovuto bloccare).

A questo punto entra il nodo che la maggior parte dei fascicoli salta. Senza un test ITGC effettivo del change management nel periodo, non si puo' assumere che la regola VR-1047 osservata oggi fosse la stessa attiva al 1 gennaio. Quando il revisore tickasse la regola corrente e si fermasse li', il test sarebbe formalmente completato ma sostanzialmente vuoto: la direzione potrebbe avere modificato la regola in marzo e ripristinata in dicembre, e nessuno se ne accorgerebbe.

Esempio pratico: Metalplast S.r.l.

Cliente: societa' manifatturiera italiana, FY2024, ricavi EUR 38M, ERP SAP, bilancio IFRS, EIP non quotato.

Passo 1: identificazione del rischio e del controllo In pianificazione si identifica il rischio di completezza delle vendite: ordini consegnati senza fatturazione. Il controllo applicativo associato e' "Validation Rule VR-2301: nessuna consegna senza ordine di vendita accoppiato". Quando una nota di consegna arriva nel modulo Spedizione, SAP verifica che esista un ordine conforme e blocca il salvataggio se l'accoppiamento manca.

Documentazione di carta di lavoro: screenshot della configurazione nel modulo di amministrazione SAP, testo della regola, campi coinvolti, messaggio di errore.

Passo 2: test del controllo Si chiede al referente IT del cliente una query sulla tabella LIPS (righe consegna) per i record con campo VBELN (numero ordine) NULL. Risultato: zero record negli ultimi tre anni. Conclusione preliminare: il controllo regge.

Carte di lavoro: output query, data esecuzione, firma del responsabile IT che attesta l'accuratezza della query e dei filtri.

Passo 3: validazione della configurazione e procedure di bypass Si verifica se qualche profilo possa scavalcare la regola. Il ruolo "Gestore_Ordini_Senior" puo' forzare un'eccezione tramite la transazione SD43 (Manutenzione eccezioni). Il log eccezioni (tabella TSTCV) registra 47 forzature in tre anni. Si analizza ogni forzatura: 44 risultano documentate (ordini di servizio post-consegna, ordini verbali confermati via email); 3 non hanno alcuna giustificazione tracciabile.

Carte di lavoro: log eccezioni completo, analisi delle 47 forzature, memo sulle tre anomalie.

Passo 4: complicazione e conclusione Qui il caso si sporca. Durante la revisione del log si nota che a luglio la regola VR-2301 e' stata modificata per due settimane: il blocco e' diventato un warning. Il change ticket esiste, approvato dal CFO, ma senza giustificazione di business. Si estende il test: 25 consegne nel periodo finestra, di cui 4 risultano fatturate con un mese di ritardo e 1 non fatturata fino al 12 gennaio dell'anno successivo. L'errore di cut-off e' EUR 47.000, sotto la performance materiality (EUR 380.000), ma il fatto stesso che la regola sia stata addomesticata senza che ITGC lo segnalasse cambia la conclusione: il controllo VR-2301 mitiga la completezza per 50 settimane, non per 52. Le restanti due si testano in via sostanziale.

Conclusione documentale: memo che riassume test, finestra di degrado del controllo, procedure sostanziali aggiuntive, errore di cut-off identificato e rettificato dalla direzione.

L'arringa: perche' i fascicoli si rompono qui

Si dovrebbe smettere di trattare il superamento dei test ITGC come licenza automatica per fare affidamento sui controlli applicativi, perche' i due livelli di test rispondono a domande diverse e nessuno dei due risponde alla domanda che importa al revisore: "questa regola era attiva, in questa configurazione, in ogni giorno del periodo?". A me piace la formulazione di un partner che, in una review di un fascicolo CONSOB-relevant, scrisse a margine "le carte erano leggere": il team aveva tickato l'ITGC, tickato il walkthrough applicativo, e scritto le carte dopo, ricostruendo a posteriori una catena logica che il fascicolo non sosteneva.

Il punto vero e' un incentivo perverso. I controlli manuali costano ore, perche' richiedono selezione, riesecuzione e documentazione per asserzione; i controlli applicativi sembrano poter essere "risolti" con un walkthrough e una query. Sotto pressione di compensi irrisori e budget compressi, i team si appoggiano alla via applicativa anche quando le condizioni di affidamento non sono soddisfatte. Il risultato lo si vede quando il Bollettino CONSOB pubblica una sanzione: la motivazione, ripulita dal linguaggio amministrativo, racconta sempre la stessa storia di output di sistema trattati come prova senza che le procedure di bridging fossero state eseguite.

Secondo ISA Italia 315.A100, l'efficacia di un controllo applicativo dipende dall'efficacia continuativa degli ITGC nel periodo. Secondo ISA Italia 330.10, se ci si affida ai controlli, il revisore ottiene evidenza della loro efficacia operativa. Quando uno dei due tasselli manca, il controllo non e' affidabile e il fascicolo lo registra in chiaro.

Il punto di vista del collegio sindacale

Vale la pena ricordare che il collegio sindacale, ai sensi dell'art. 2403 C.C., vigila sull'adeguatezza dell'assetto organizzativo, amministrativo e contabile. Quando il sistema gestionale ospita controlli applicativi su cui il revisore legale fa affidamento, il collegio ha titolo per chiedere alla direzione documentazione del processo di change management e dei log eccezioni, indipendentemente dal lavoro del revisore legale ai sensi del D.Lgs. 39/2010. Se il bilancio fosse contestato, le due posizioni vengono lette in parallelo: dove il fascicolo del revisore legale si appoggi su controlli applicativi e il libro del collegio non riporti nulla sul tema, l'asimmetria diventa argomento difficile da sostenere.

Cosa i revisori interpretano male

- Si tratta la configurazione non documentata come se il controllo non esistesse. Quando il team non riesce a ottenere la documentazione tecnica della regola (numero, parametri, messaggio di errore), molti fascicoli saltano il controllo e lo riclassificano come procedura manuale. Secondo ISA Italia 315.29 si comprende il controllo, e la comprensione si documenta. La regola e' nel sistema, la query restituisce zero errori, ma nessuno ha mai scritto il documento "cosi e' configurato, cosi e' stato testato": le carte erano leggere.

- Il test di efficacia operativa non verifica le procedure di bypass. Si testa il funzionamento in condizioni ordinarie e ci si ferma. In SAP, Oracle e NetSuite ogni controllo di validazione e' bypassabile da un ruolo amministrativo o da una transazione di manutenzione. Ai sensi di ISA Italia 330.8, se il fascicolo non documenta che si sia verificata l'esistenza di queste procedure e non analizzi il loro utilizzo nel periodo, il test risulterebbe incompleto.

- I report "system-generated" si trattano come evidenza, non come IPE. Un report estratto dal gestionale, anche con timestamp e logo dell'ERP, resta IPE (information produced by entity) e rientra nelle procedure di completezza e accuratezza ai sensi di ISA Italia 500.9. Se non si testano i parametri della query, i filtri applicati e la riconciliazione con il dato di sistema, il report non fonda l'opinione.

- I log di eccezione non si analizzano nel periodo. Quasi ogni sistema applicativo registra le forzature di controllo. Se il fascicolo non includesse un'analisi del log per il periodo di revisione, il test assumerebbe la continuita' del controllo senza prova specifica. La pratica corretta estrae il log, conta le eccezioni, ne valuta la natura e riconcilia il numero con la popolazione complessiva.

- Il bridging del SOC 1 si salta. Quando una funzione critica gira presso un service organisation (paghe, hosting, fatturazione elettronica), il SOC 1 Type 2 copre un periodo che raramente coincide con il periodo di revisione. ISA Italia 402.16 richiede procedure di bridging per il gap. Si vedono fascicoli con il SOC allegato e nessuna procedura di bridging: il documento c'e', il lavoro no.

Disaccordo legittimo: due partner sullo stesso fascicolo

Su una controllata italiana di un gruppo quotato, il partner di engagement riteneva sufficiente fare affidamento sulla regola VR-2301 perche' la query non aveva restituito eccezioni e l'ITGC era stato testato in apertura. Il quality reviewer dissentiva: senza un test del change management nel periodo (non solo a una data), l'affidamento non sarebbe stato giustificato e si sarebbero dovute eseguire procedure sostanziali sulla completezza delle vendite. La discussione e' legittima e ricorrente: il partner di engagement leggeva ISA Italia 330.A29 in chiave di efficienza; il quality reviewer leggeva ISA Italia 315.A105 in chiave di rigore. Si chiuse con procedure sostanziali aggiuntive sui due trimestri non coperti da test ITGC continuativo e con la nota nel fascicolo che, se la societa' fosse stata EIP, l'affidamento puro non sarebbe stato accettabile.

Controlli applicativi vs. controlli manuali

La differenza pratica si lascia condensare. Un controllo applicativo non lascia commettere un errore sistematico finche' non venga disabilitato o bypassato. Un controllo manuale puo' essere saltato da una sola persona in una sola giornata. Per questo le procedure pianificate sui controlli applicativi richiedono evidenza minore sul controllo stesso e maggiore sulla persistenza della configurazione nel periodo.

Termini correlati

- Controlli generali IT — Controlli su sistema operativo, change management e accesso ai dati che assicurano l'integrita' dell'ambiente in cui girano i controlli applicativi. - Campionamento delle transazioni — Metodo per testare l'efficacia operativa selezionando un insieme di transazioni nel periodo. - Log di audit del sistema — Registro di accessi, modifiche e bypass di un controllo, base per il test di eccezioni. - Validazione dei dati — Meccanismo tecnico con cui un controllo applicativo verifica che i dati rispettino le regole prima del salvataggio. - ISA 315 — identificazione dei rischi — Standard che richiede di identificare e comprendere i controlli rilevanti, comprese le regole applicative. - Prova di efficacia del controllo — Processo di test che dimostra se un controllo abbia funzionato come progettato nel periodo.

Calcolatore di controlli applicativi

Il Calcolatore di controlli applicativi di Ciferi guida il test di efficacia operativa attraverso le domande che il fascicolo deve coprire: la configurazione e' documentata, il controllo ha funzionato come configurato, esistono eccezioni documentate, il numero e la natura delle eccezioni risultano accettabili per l'asserzione, gli ITGC reggono nel periodo. Produce un memo di conclusione pronto per il fascicolo.

---