Definition

La maggior parte dei fascicoli che vediamo capitalizza costi che non superano il test del paragrafo 57 dello IAS 38. Si trovano stipendi della fase di ricerca riclassificati come "sviluppo" a posteriori, relazioni tecniche datate dopo l'inizio della capitalizzazione, e codici di progetto aperti quando il bilancio era ormai chiuso. Il D.Lgs. 39/2010 e l'art. 2426 C.C. richiedono che il revisore valuti la coerenza fra rappresentazione contabile e sostanza, e qui la sostanza spesso non regge.

Cosa richiede lo standard

Lo IAS 38 separa nettamente due fasi. I costi di ricerca si spesano sempre nel conto economico nel momento in cui si sostengono (IAS 38.54). I costi di sviluppo si capitalizzano come immobilizzazione immateriale solo quando l'entità dimostri di aver soddisfatto tutti e cinque i criteri del paragrafo 57.

Lo IAS 38 dice che la fase di ricerca finisce quando la direzione può identificare un progetto specifico. Cosa succede davvero: nei fascicoli che leggiamo, la "fine della ricerca" coincide spesso con il momento in cui qualcuno ha bisogno di gonfiare l'attivo, non con un evento documentabile. La data di transizione viene scelta a posteriori, in sede di chiusura, e la relazione tecnica viene firmata quando il bilancio è già in bozza.

I cinque criteri dello IAS 38.57 sono questi:

1. Feasibility tecnica della realizzazione del bene (IAS 38.57(a)): l'entità deve disporre di risorse tecniche, professionali e finanziarie per completare il progetto. 2. Intenzione di completare il bene (IAS 38.57(b)): deve esistere un'intenzione manageriale documentata in modo contemporaneo. 3. Capacità di utilizzare o vendere il bene (IAS 38.57(c)): l'entità deve poter usare il bene internamente o cederlo sul mercato. 4. Probabilità che il bene generi benefici economici futuri (IAS 38.57(d)): più probabile che no, con evidenza esterna o piani interni verificabili. 5. Capacità di misurare attendibilmente i costi di sviluppo (IAS 38.57(e)): tracciabilità per commessa, codice di progetto dedicato, timesheet riconciliabili.

In teoria questi cinque criteri operano come una checklist. In pratica i problemi nascono sempre dal punto (a) e dal punto (e): la feasibility viene asserita senza relazione tecnica firmata, la misurazione dei costi viene ricostruita ex post da estratti del libro paga senza codice di commessa.

Una volta soddisfatti i criteri, i costi sostenuti da quel momento in avanti si capitalizzano. I costi precedenti (inclusi quelli della fase di ricerca pura) restano a conto economico e non possono essere ricapitalizzati successivamente, secondo IAS 38.71. Dopo il riconoscimento, il bene si misura al costo storico al netto dell'ammortamento (modello del costo) o al fair value al netto dell'ammortamento cumulato (modello della rivalutazione, applicabile solo se esiste un mercato attivo per la categoria di bene). L'ammortamento inizia quando il bene è pronto all'uso, non quando viene effettivamente messo in produzione.

La zona grigia: data di transizione e incentivi alla capitalizzazione

Il revisore non deve limitarsi a verificare che esistano i cinque criteri. Deve verificare che esistessero, in modo simultaneo e documentato, alla data che la società indica come inizio della capitalizzazione. È una distinzione di sostanza, non di forma.

Nella nostra esperienza, il bonus della direzione è spesso parametrato all'EBITDA, e capitalizzare costi di sviluppo lo migliora. Si crea così un incentivo a spostare la "data di transizione" il più indietro possibile nell'esercizio. Questa è la spiegazione che riteniamo più convincente del divario fra teoria e pratica: la zona grigia non nasce da ambiguità tecnica dello standard, ma dalla pressione sui margini reportati. Lo standard è chiaro; il fascicolo deve dimostrarlo nonostante la pressione.

Su come applicare il criterio (a) della feasibility tecnica esistono due posizioni difendibili. La prima sostiene che basti una valutazione interna firmata dal CTO o equivalente, perché lo IAS 38.57 non richiede formalmente perizia esterna. La seconda chiede evidenza di mercato (benchmark di progetti simili, prototipi funzionanti, brevetti depositati), perché un'autocertificazione rischia di confondere intenzione con capacità. Riteniamo più solida la seconda lettura, soprattutto su progetti software dove la feasibility viene spesso asserita prima che esista un proof of concept funzionante. La prima posizione è difendibile per progetti incrementali su tecnologie consolidate.

Nelle società italiane con collegio sindacale, la valutazione del trattamento contabile delle spese di sviluppo rientra nella vigilanza ex art. 2403 C.C., e il collegio interloquisce direttamente con la direzione sul punto. Coordinare la posizione del revisore con quella del collegio evita che in assemblea emergano due narrazioni diverse sulla stessa voce.

Esempio pratico: Tecnosolidi S.r.l.

Cliente: società italiana di ingegneria, FY 2024, sede in Veneto, revenue EUR 28M, IFRS reporter.

Tecnosolidi ha avviato nel gennaio 2023 un progetto interno per sviluppare un software proprietario di ottimizzazione dei processi costruttivi. Nel dicembre 2023 il progetto aveva raggiunto la fase di sviluppo. Nel gennaio 2024 il team di ingegneria ha iniziato lo sviluppo vero e proprio.

Step 1: classificazione della fase di ricerca (2023) Nel 2023 Tecnosolidi ha speso EUR 180.000 in analisi di fattibilità, test preliminari di algoritmi e ricerca di soluzioni alternative. Nessuno di questi costi era legato a un progetto specifico identificato. Sono stati tutti spesati nel conto economico 2023. Nota di documentazione: nelle carte di lavoro il revisore ha qualificato i costi 2023 come ricerca, citando IAS 38.58, e ha verificato che nessuno di essi fosse stato capitalizzato.

Step 2: data di transizione alla fase di sviluppo (gennaio 2024) A gennaio 2024 Tecnosolidi ha ottenuto l'approvazione del management per procedere allo sviluppo, con un budget di EUR 420.000 e una scadenza prevista a luglio 2024. È stata redatta una relazione tecnica datata 12 gennaio 2024, in cui si descrivevano: - Feasibility tecnica: il team disponeva di tre ingegneri software con 15 anni di esperienza e accesso alle piattaforme open source necessarie. - Intenzione di completare: il CEO aveva firmato l'approvazione del progetto; budget allocato nel piano finanziario 2024. - Capacità d'uso: il software sarebbe stato impiegato internamente in quattro cantieri della società per ridurre i tempi di pianificazione. - Probabilità di benefici economici: Tecnosolidi stimava una riduzione dei costi di progettazione del 22% (EUR 95.000 annui), documentabile su base storica. - Capacità di misurare i costi: il sistema di contabilità industriale tracciava i costi per commessa; è stato istituito un codice di progetto dedicato.

Nota di documentazione: il fascicolo contiene la relazione di approvazione del management, l'analisi dei cinque criteri IAS 38.57 e la firma di autorizzazione a capitalizzare a partire dalla data di gennaio 2024.

Step 3: capitalizzazione dei costi di sviluppo (gennaio–luglio 2024) Da gennaio a luglio 2024 Tecnosolidi ha sostenuto i costi seguenti per lo sviluppo: - Stipendi del team di sviluppo: EUR 280.000. - Licenze software temporanee per il development: EUR 18.000. - Hardware dedicato per il testing: EUR 24.000. - Costi di hosting temporaneo per gli ambienti di test: EUR 8.000.

Totale: EUR 330.000 (il progetto è rimasto sotto budget e si è concluso a giugno).

Questi costi sono stati capitalizzati come "Software interno. Progetto di ottimizzazione 2024" nello stato patrimoniale a partire da gennaio 2024. È stato stabilito un ammortamento a 5 anni (vita utile stimata) a partire da agosto 2024, mese in cui il software è stato messo in uso nei cantieri.

Nota di documentazione: le carte di lavoro elencano i costi capitalizzati per categoria, li riconciliano con il sistema contabile e documentano la data in cui il bene è stato posto in servizio (agosto 2024, mese successivo al completamento). L'ammortamento è stato calcolato come EUR 330.000 ÷ 5 anni ÷ 12 mesi × 5 mesi (agosto–dicembre) = EUR 27.500 nel 2024.

Step 4: verifica del revisore Il revisore ha: 1. Ottenuto il documento di approvazione del management e verificato la data di transizione dalla ricerca allo sviluppo. 2. Verificato che i costi di ricerca 2023 (EUR 180.000) fossero spesati e non capitalizzati (conforme a IAS 38.58). 3. Verificato i cinque criteri IAS 38.57 attraverso interviste al project manager, esame della relazione tecnica e analisi della feasibility del progetto. 4. Riconciliato i costi capitalizzati con i registri contabili e i timesheets del team di sviluppo. 5. Verificato che l'ammortamento fosse iniziato alla data corretta (quando il software era pronto all'uso, non prima). 6. Verificato la vita utile di 5 anni come ragionevole per software proprietario in un'azienda tecnologica.

Conclusione: il trattamento contabile di Tecnosolidi era conforme a IAS 38. I costi di ricerca erano stati spesati; i costi di sviluppo erano stati capitalizzati a partire dalla data in cui tutti e cinque i criteri erano dimostrabilmente soddisfatti; l'ammortamento era iniziato nel mese in cui il bene era stato messo in uso.

Cosa colgono in fallo i revisori e i professionisti

- Tier 1 (regulator finding): i dati ispettivi internazionali dell'IAASB mostrano che la distinzione fra ricerca e sviluppo è il punto di fallimento più frequente nella valutazione delle immobilizzazioni immateriali generate internamente. Molti fascicoli capitalizzavano costi di ricerca pura oppure spesavano costi di sviluppo che soddisfacevano già i cinque criteri. La causa più comune è la mancanza di documentazione contemporanea della data di transizione fra fasi.

- Tier 2 (standard-referenced error): lo IAS 38.57 richiede che tutti e cinque i criteri siano soddisfatti prima di iniziare la capitalizzazione. Un errore pratico ricorrente è capitalizzare parzialmente, ossia documentare solo alcuni criteri mentre altri restano impliciti. Alcuni team capitalizzano una volta che esiste l'intenzione manageriale e una stima di benefici economici, dimenticandosi di documentare la feasibility tecnica e la capacità di misurare i costi. Lo IAS 38.57(a) e (e) sono frequentemente trascurati.

- Tier 3 (documented practice gap): la ricapitalizzazione di costi di ricerca è rara, ma è frequente che ricerca e sviluppo non siano chiaramente separati nella contabilità analitica. Senza un codice di progetto dedicato o un timekeeping chiaro il revisore non riesce a verificare la riconciliazione fra costi a conto economico e costi capitalizzati. Non è un errore nell'applicazione dello IAS 38, ma è un gap di documentazione che rallenta la revisione e che, in caso di ispezione MEF, diventa il primo appiglio del verificatore. Quando il fascicolo arriva sul tavolo dell'ispettore senza una data di transizione documentata in modo contemporaneo, la conversazione che segue è quella che ogni revisore preferirebbe non sostenere.

Termini correlati

- Immobilizzazioni immateriali: categoria contabile più ampia che include sia le immobilizzazioni generate internamente sia quelle acquisite esternamente. - Ammortamento: processo sistematico di allocazione del costo dell'immobilizzazione lungo la sua vita utile. - Vita utile: periodo stimato durante il quale l'entità si attende di usare l'immobilizzazione e di generare benefici economici. - Fair value: prezzo che sarebbe ricevuto dalla vendita di un bene in una transazione ordinata. - Costi capitalizzabili: spese sostenute che si iscrivono all'attivo dello stato patrimoniale piuttosto che al conto economico. - Software proprietario: applicazione informatica sviluppata internamente da cui l'entità si attende benefici economici superiori al costo di sviluppo.

---

Ricevi approfondimenti pratici sulla revisione, ogni settimana.

Niente teoria d'esame. Solo ciò che rende le revisioni più efficienti.

Oltre 290 guide pubblicate20 strumenti gratuitiCreato da un revisore in esercizio

Niente spam. Siamo revisori, non venditori.