Misstatement Tracker: Tecnologia | ciferi

Quando gli errori nella tecnologia diventano significativi

Gli incarichi di revisione presso società di tecnologia presentano una sfida strutturale per l'ISA Italia 450. Una tipica società di software con revenue recognition basata su contratti pluriennali, cloud hosting con allocazione dei costi per tenant, e capitalizzazione del software development può produrre una densità di errori stimati superiore a quella che si riscontra in altri settori. Un'allocazione errata dei costi di sviluppo fra due prodotti, applicata ad una base di prodotti in fase di ammortamento, crea un errore stimato che attraversa tre periodi. La capitalizzazione di costi di hosting che dovrebbe essere espensata secondo l'IFRS 16 produce un errore rettificato solo al momento della revisione. ISA Italia 450.5 richiede di cumulare tutti questi errori, e lo strumento è costruito per gestire quel volume senza perdere le voci individuali nel rumore.

Le aree ad alta densità di errori nelle revisioni di tecnologia

Revenue recognition nei contratti software

La IFRS 15 richiede ai revisori di identificare le obbligazioni di prestazione distinte nei contratti con clienti. Una società di software tipica vende simultaneamente il software (licenza perpetua o annuale), il supporto tecnico (obbligazione distinta), la manutenzione (obbligazione di prestazione futura), e spesso componenti di cloud hosting. L'allocazione del prezzo di transazione fra queste componenti crea opportunità ricorrenti di errore. Se l'azienda alloca il 70% del prezzo alla licenza software e il 30% al supporto, mentre le vostre procedure di revisione indicano che il supporto rappresenta il 40% del valore di mercato osservabile, avete identificato un errore giudiziale secondo l'ISA Italia 450.A1. L'errore affetta il bilancio corrente (attraverso l'allocazione) e i periodi futuri (attraverso la manutenzione differita). Documentate sia l'effetto del periodo corrente sia l'effetto stimato sui periodi futuri quando accumulate questo errore.

Capitalizzazione del software development

Lo IAS 38 richiede che i costi di sviluppo software siano capitalizzati quando il progetto soddisfa i criteri di riconoscimento di un'attività immateriale. La pratica comune è che le società di tecnologia capitalizzano i costi lordi dello stipendio del team di sviluppo, dell'hardware usato dal team, e di una quota dei costi generali. Tre errori ricorrenti emergono durante la revisione:

Valutazione dei diritti di utilizzo secondo l'IFRS 16

Le società di tecnologia che utilizzano infrastruttura cloud (server, storage, licensing dei database) hanno contratti che potrebbero rientrare nella definizione di locazione secondo l'IFRS 16. Un contratto di cloud hosting per il quale il fornitore dedica una porzione specifica dell'infrastruttura al cliente, e il cliente non può cambiare il fornitore senza costi significativi, soddisfa la definizione di locazione (IFRS 16.9). L'errore comune è che l'azienda contabilizza questo come un costo di servizio mensile (nella linea "outsourcing tecnico") piuttosto che come una locazione con un diritto di utilizzo capitalizzato e un'obbligazione di pagamento. Se la società ha tre contratti di cloud hosting non riconosciuti come locazioni, gli errori cumulati possono essere significativi.

• Costi infrastrutturali non allocati correttamente: Se un team di 20 sviluppatori lavora su cinque prodotti diversi, la base di allocazione (numero di sviluppatori, ore di progetto, o linee di codice) deve essere applicata coerentemente. Se questo anno è stata usata l'allocazione per ore di progetto mentre lo scorso anno è stata usata l'allocazione per numero di sviluppatori, il saldo di apertura dell'immateriale sarà incomparabile con l'ammortamento dell'anno corrente.
• Hosting infrastrutturale capitalizzato invece di espensato: I costi dei server in cloud che ospitano l'infrastruttura di sviluppo (non il prodotto stesso) vengono talvolta erroneamente capitalizzati come parte del costo del software. Lo IAS 38.69 richiede che i costi di tenere in funzione un'attività immateriale dopo il suo completamento siano espensati, non capitalizzati.
• Capitalizzazione di costi di amministrazione tecnica: I costi di supporto tecnico interno, manutenzione del codice legacy, e test di qualità ricorrente sono costi di gestione post-lancio, non costi di sviluppo, e devono essere espensati.

Come il calcolatore di errori applica l'ISA Italia 450 nel settore tecnologico

Soglia chiaramente trascurabile

Per una società di tecnologia con ricavi fra EUR 15M e EUR 60M e significatività complessiva attorno a EUR 750.000, una soglia chiaramente trascurabile fra EUR 25.000 e EUR 40.000 è tipica. Questa cattura la densità elevata di errori di allocazione (di solito tra EUR 5.000 e EUR 20.000 ciascuno) senza intasare il prospetto degli errori non corretti. Impostate una soglia più bassa se le revisioni precedenti hanno rilevato numerosi errori di allocazione che singolarmente sembravano piccoli ma aggregati raggiungevano l'importanza relativa. Una regola empirica nel settore tecnologico è stata dimostrata: le società che sottoutilizzano le procedure di revisione su revenue recognition e capitalizzazione del software producono errori stimati che si accumulano oltre la significatività di esecuzione in quattro incarichi su cinque.

Errori fattuali vs. errori stimati

Quando il vostro test del software di fatturazione identifica che due clienti sono stati sovrafatturati a causa di un errore nel motore di calcolo, avete un errore fattuale (ISA Italia 450.A1). Quando la vostra analisi retrospettiva della capitalizzazione del software suggerisce che il 12% dei costi dichiarati come sviluppo erano in realtà costi infrastrutturali post-lancio che dovrebbero essere stati espensati, e applicate questa percentuale alla base degli immobilizzazioni immateriali, avete un errore stimato (ISA Italia 450.A3). Lo strumento consente di tracciare separatamente questi due tipi. Gli errori fattuali vengono sommati direttamente. Gli errori stimati includono una componente per il rischio di campionamento.

Effetto sui periodi futuri

Un errore nella capitalizzazione di un progetto software nel 2024 (EUR 180.000 capitalizzati in modo errato, EUR 120.000 ammortizzati nel 2024) crea effetti che si portano avanti: EUR 60.000 rimangono nelle immobilizzazioni immateriali al 31 dicembre 2024 e verranno ammortizzati negli anni 2025 e successivi. ISA Italia 450.A6 richiede ai revisori di considerare l'effetto degli errori non corretti dei periodi precedenti sui bilanci attuali. Se questo errore di capitalizzazione non viene corretto nel 2024, la significatività dei saldi immateriali nel 2025 sarà inflazionata di EUR 60.000. Documentate entrambi gli effetti quando accumulate questi errori.

Domande comuni sulla valutazione degli errori nelle revisioni di tecnologia

D: Come faccio a trattare gli errori che interessano sia la capitalizzazione che l'ammortamento?
R: Registrate l'effetto netto sul reddito operativo (ammortamento errato del periodo corrente) e l'effetto sul bilancio (saldo immateriale errato al 31 dicembre). Questi sono due componenti dello stesso errore. Se capitalizzate EUR 180.000 che dovrebbero essere espensati, e ne ammortizzate EUR 120.000 durante l'anno, registrate un errore di reddito di EUR 120.000 (ammortamento sovrastimato) e un errore patrimoniale di EUR 180.000 (immateriale sovrastimato). L'effetto netto sulla posizione patrimoniale e finanziaria complessiva è EUR 180.000; l'effetto netto sul reddito del periodo è EUR 120.000.
D: Cosa costituisce una soglia chiaramente trascurabile realistica per una società di tecnologia con IPO pianificata?
R: Se l'azienda si prepara a una quotazione in borsa, una soglia più rigida è appropriata. Una società di tecnologia IPO-ready con ricavi di EUR 45M e significatività complessiva di EUR 650.000 dovrebbe usare una soglia chiaramente trascurabile attorno a EUR 15.000-20.000. I potenziali investitori e i revisori che condurranno la due diligence post-IPO si aspettano una qualità del fascicolo di revisione molto più elevata. Gli errori che una società privata avrebbe potuto tollerare al di sotto di una soglia trascurabile diventeranno questioni di rilievo dopo la quotazione.
D: Devo ricumulare gli errori stimati ogni anno, oppure posso trascinare in avanti gli errori del periodo precedente?
R: ISA Italia 450.11(b) richiede che considerate l'effetto degli errori non corretti dei periodi amministrativi precedenti sui saldi, le classi di operazioni e le informazioni del bilancio attuale. Questo significa che se un errore stimato di EUR 45.000 nella capitalizzazione del software è rimasto non corretto nel 2024, il suo effetto si porta avanti nel 2025 attraverso l'ammortamento e il saldo residuo dell'immateriale. Non lo ricumulate come errore nuovo nel 2025; piuttosto, valutate il suo effetto continuo sulla posizione complessiva. Se la correzione di questo errore nel 2025 porterebbe il saldo immateriale al di sotto di quello dichiarato nel 2024, questo è un elemento qualitativo importante nella vostra valutazione di cui discutere con il management.
D: Come tratto gli errori in cui il management ha completamente ricapitalizzato un progetto software che non soddisfa i criteri dello IAS 38?
R: Questo è un errore giudiziale significativo (ISA Italia 450.A1). La determinazione del fact non è in dubbio: il progetto non soddisfa i criteri di riconoscimento di un'attività. Documentate con chiarezza perché il progetto non soddisfa i criteri (per esempio, il progetto è ancora in fase di ricerca secondo lo IAS 38.56, non in fase di sviluppo; oppure l'azienda non ha dimostrato la probabilità di generare flussi di cassa futuri secondo lo IAS 38.57). Quantificate l'errore come l'importo totale capitalizzato. Nella vostra comunicazione ai responsabili delle attività di governance secondo l'ISA Italia 450.12, spiegate il fondamento della vostra conclusione che il progetto non soddisfa i criteri.
D: Quali sono le aspettative locali sulla documentazione degli errori nelle revisioni presso società di tecnologia italiane?
R: CONSOB, tramite il suo Ordine del 7 dicembre 2020 di attuazione dell'articolo 14-ter del D.Lgs. 39/2010, ha pubblicato linee guida che si applicano alle revisioni delle società quotate. Anche se il vostro cliente non è quotato, questi orientamenti riflettono lo standard di qualità atteso dalle società di tecnologia di media dimensione. La documentazione dovrebbe includere: una descrizione chiara di ogni errore e il fondamento per la sua identificazione (ISA Italia 450.15); la categoria di errore (fattuale, giudiziale, stimato); l'effetto sia sul reddito che sul bilancio; e, per gli errori non corretti, il motivo documentato della conclusione che non sono significativi singolarmente o aggregatamente (ISA Italia 450.11). Per le società che si preparano alla quotazione, questa documentazione sarà esaminata da revisori esperti e investitori istituzionali.

Varianti del calcolatore per sottosettori tecnologici

Il calcolatore di base è stato preconfigurato per società di software e cloud computing. Se state revisionando un'azienda di hardware, le soglie di importanza relativa e le aree ad alto rischio cambiano:

• Società di semiconduttori e manifattura di chip: Applicare le linee guida del settore manifatturiero (vedere il Misstatement Tracker: Manifattura). Le sottiglianze specifiche del software sono meno rilevanti; la densità di errori è guidata dalla contabilizzazione dell'inventario e dai costi di ricerca e sviluppo capitalizzati.
• Società di e-commerce con componente di tecnologia: Consultare il Misstatement Tracker: Retail. La revenue recognition secondo la IFRS 15 è simile, ma la gestione dell'inventario fisico crea ulteriori opportunità di errore.
• Società di servizi di telefonia mobile e broadcasting: Le specificità riguardano l'allocazione dei costi di rete, la contabilizzazione di contratti di interconnessione, e l'ammortamento accelerato di infrastrutture tecnologiche obsolete.

Come iniziare

• Inserite le vostre soglie di importanza relativa: Se non le avete ancora calcolate, consultate il Misstatement Tracker: Calcolatore di Significatività (ISA Italia 320). Usate la stessa significatività complessiva e significatività di esecuzione che avete determinato nel vostro memorandum di pianificazione.
• Selezionate la vostra società dal database del settore tecnologico: Se la vostra società non è esattamente un'azienda di software pure-play, usate il sottosettore più vicino o tornate alle linee guida generali.
• Documentate la vostra soglia chiaramente trascurabile: Secondo l'ISA Italia 450.15(a), la documentazione della revisione deve includere l'importo al di sotto del quale gli errori sono considerati chiaramente trascurabili. Lo strumento vi dà la possibilità di impostare questo valore una sola volta e applicarlo a ogni errore.
• Accumulate ogni errore identificato: Non appena identificate un errore durante la revisione (dall'esame di una transazione, dal risultato di una procedura di analisi, da una richiesta al management), inseritelo nello strumento e classificatelo (fattuale, giudiziale, o stimato).
• Riesaminare la vostra strategia di revisione se necessario: Secondo l'ISA Italia 450.6, dovete valutare se la natura e le circostanze degli errori identificati suggeriscono che potrebbero esistere altri errori. Lo strumento evidenzia quando gli errori identificati si avvicinano alla vostra significatività di esecuzione, innescando questa rivalutazione.
• Comunicare ai responsabili delle attività di governance: ISA Italia 450.12 richiede di comunicare singolarmente ciascun errore significativo non corretto. Lo strumento produce un prospetto riepilogativo che potete includere nella vostra lettera di gestione o nel memorandum di completamento.
• Ottenere un'attestazione scritta: ISA Italia 450.14 richiede una dichiarazione scritta dal management (e, se appropriato, dai responsabili delle attività di governance come il Collegio Sindacale) attestando che gli effetti degli errori non corretti non sono significativi per il bilancio nel suo insieme. Lo strumento vi aiuta a preparare un riepilogo di questi errori da includere nell'attestazione.

Contesti specifici del settore tecnologico italiano

Le società di tecnologia italiane operano spesso secondo il regime fiscale dei Principi Contabili OIC (Organismo Italiano di Contabilità) per i rendiconti finanziari stand-alone e secondo IFRS per i rendiconti consolidati. Questo crea una complicazione ISA Italia 450: un errore nel rendiconto consolidato IFRS potrebbe non essere un errore nel rendiconto stand-alone OIC. Ad esempio, le regole OIC sulla capitalizzazione del software sono meno rigorose rispetto allo IAS 38, quindi potrebbe essere consentito capitalizzare costi che sarebbero un errore secondo IFRS. Se state revisionando una società di tecnologia italiana con rendiconti consolidati (richiedendo IFRS) e rendiconti finanziari annuali (permettendo OIC), mantenete prospetti di errori separati per ciascun framework oppure, al minimo, contrassegnate quale framework ogni errore influenza. La vostra conclusione sulla significatività deve essere riferita al bilancio IFRS consolidato (se quotato) oppure al rendiconto OIC stand-alone (se non quotato), ma il file di revisione deve tracciare dove si verificano gli errori.
---