Costi di sviluppo software: come capitalizzarli o spesarli nel 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

I costi di sviluppo software sono il denaro speso in persone, fornitori, strumenti e infrastruttura per progettare, sviluppare e testare un software – e nel 2026 la domanda più difficile non è più soltanto quanto valgano, ma dove finiscano nel bilancio. Gli stessi 500.000 $ possono pesare sul risultato operativo di un solo anno oppure diventare un’attività ripartita su tre-cinque anni, a seconda di cosa è stato finanziato, quando e secondo quale principio contabile.

La contabilizzazione dei costi di sviluppo software diventa di solito urgente in un momento prevedibile: la prima revisione contabile, un round di finanziamento o la prima fattura importante di un team esterno. Le aziende che acquistano servizi di product engineering per aziende software si trovano spesso davanti alla questione quando il revisore chiede di suddividere le fatture mensili del fornitore tra ricerca, nuove funzionalità e manutenzione – e nessuno aveva previsto questa suddivisione alla firma del contratto.

Due novità rendono il 2026 un buon anno per rivedere la vostra policy. Negli Stati Uniti l’ASU 2025-06 del FASB riscrive le regole sul software ad uso interno per la prima volta dopo decenni, e il One Big Beautiful Bill Act ha ripristinato, con la nuova Section 174A, la deduzione fiscale immediata delle spese di ricerca e sperimentazione svolte negli Stati Uniti. Questa guida spiega entrambe, insieme alle regole IFRS seguite da molte aziende europee. Si tratta di un’informazione generale e non di una consulenza fiscale o di revisione: verificate la vostra policy con il revisore e il consulente fiscale.

Cosa sono i costi di sviluppo software?

I costi di sviluppo software sono tutti i costi direttamente attribuibili alla realizzazione di un software: personale interno, compensi di fornitori e agenzie, licenze e strumenti, ambienti cloud e lavoro sui dati durante lo sviluppo. I costi indiretti come l’affitto degli uffici o la direzione generale fanno parte del costo di gestione dell’azienda, ma i principi contabili raramente consentono di includerli nel valore del software.

In contabilità conviene classificare i costi prima per natura e poi per attività. La natura dice cosa è stato pagato; l’attività, trattata nella sezione successiva, stabilisce se il costo può essere capitalizzato. La tabella riassume le componenti abituali e il loro trattamento tipico secondo gli US GAAP per il software ad uso interno.

Questo articolo tratta di come registrare questi costi, non di quanto dovrebbero essere. Per le fasce di prezzo per tipo di progetto, dimensione del team e area geografica consultate i nostri benchmark dei costi di sviluppo software per il 2026.

I costi di sviluppo software vanno capitalizzati o spesati?

I costi di sviluppo software si capitalizzano quando creano un software con benefici futuri o gli aggiungono funzionalità e la soglia contabile applicabile è stata raggiunta; tutto il resto si spesa quando sostenuto. In pratica ricerca, pianificazione, manutenzione, formazione e spese generali vanno a conto economico, mentre progettazione, codifica e test di nuove funzionalità possono diventare un’attività.

La decisione si prende attività per attività, non fattura per fattura. Un solo sprint può contenere lavoro capitalizzabile su un nuovo modulo, correzioni di bug su un modulo esistente (costo) e spike di ricerca (costo). La tabella mostra l’esito tipico per il software ad uso interno secondo gli US GAAP; gli IFRS arrivano a risultati simili per la maggior parte delle righe, ma con un test diverso, spiegato più avanti.

Il test decisivo per il lavoro successivo al lancio è semplice da formulare e difficile da applicare: il software acquisisce una capacità che prima non aveva? Un nuovo modulo di reporting supera il test; un refactoring per le prestazioni o la correzione di difetti di solito no. Mettete la regola per iscritto, aggiungete esempi e applicatela allo stesso modo ogni mese.

Come funziona oggi l’ASC 350-40 per il software ad uso interno?

Secondo l’attuale ASC 350-40, il software ad uso interno segue un modello in tre fasi: i costi della fase preliminare di progetto si spesano, quelli della fase di sviluppo dell’applicazione si capitalizzano e quelli della fase post-implementazione e di esercizio si spesano di nuovo. Finché un’azienda non adotta l’ASU 2025-06, questa resta la regola per chi applica gli US GAAP.

Il software ad uso interno è il software acquistato, sviluppato o modificato esclusivamente per le esigenze interne dell’azienda, senza un piano sostanziale di commercializzazione esterna. Comprende personalizzazioni ERP, strumenti interni, portali clienti e, aspetto importante, la maggior parte delle piattaforme SaaS, come spiegato più avanti.

Le tre fasi

• Fase preliminare di progetto — formulazione del concetto, valutazione delle alternative, definizione della tecnologia necessaria e scelta finale. Tutti i costi si spesano.
• Fase di sviluppo dell’applicazione — progettazione della soluzione scelta, codifica, installazione dell’hardware e test, incluso il funzionamento in parallelo. La capitalizzazione inizia quando la fase preliminare è conclusa, il management autorizza il progetto e si impegna a finanziarlo ed è probabile che il progetto sarà completato e il software usato come previsto.
• Fase post-implementazione e di esercizio — formazione e manutenzione. La capitalizzazione termina quando il software è sostanzialmente completato e pronto per l’uso previsto, in genere dopo la conclusione di tutti i test significativi.

Cosa potete capitalizzare e cosa no

Sono capitalizzabili i costi esterni diretti di materiali e servizi consumati per sviluppare il software, gli stipendi e i relativi oneri dei dipendenti direttamente coinvolti nel progetto nella misura del tempo che vi dedicano, e gli interessi passivi sostenuti durante lo sviluppo secondo l’ASC 835-20. Spese generali e amministrative, costi indiretti, formazione e conversione dei dati si spesano anche quando avvengono durante la fase di sviluppo dell’applicazione.

Contratti di cloud computing: costi di implementazione di un SaaS acquistato

Quando la vostra azienda è cliente di un prodotto SaaS in hosting, i costi di implementazione seguono le stesse regole per fasi dell’ASC 350-40 in base all’ASU 2018-15, anche se il software non diventa mai vostro. I costi di configurazione, integrazione e test della soluzione in hosting durante la fase di sviluppo dell’applicazione si capitalizzano, si ammortizzano lungo la durata del contratto di hosting, inclusi i rinnovi ragionevolmente certi, e si presentano nella stessa voce di conto economico dei canoni di abbonamento. Il canone in sé resta un costo operativo.

Per le aziende che gestiscono più sistemi, queste regole valgono per ogni progetto di integrazione. I nostri team di sviluppo software su misura documentano configurazione e integrazione separatamente dal supporto proprio per questo motivo.

Cosa cambia con l’ASU 2025-06?

L’ASU 2025-06, emanato dal FASB il 18 settembre 2025, elimina le tre fasi di progetto dall’ASC 350-40 e le sostituisce con un’unica soglia di rilevazione: si capitalizza quando il management ha autorizzato il progetto e si è impegnato a finanziarlo ed è probabile che il progetto sarà completato e il software usato per svolgere la funzione prevista. Società di consulenza come RSM la descrivono come la più ampia revisione della contabilizzazione del software ad uso interno dal 1998, spinta in larga parte dallo sviluppo agile.

Il modello per fasi presupponeva un progetto lineare a cascata, in cui la pianificazione terminava prima dell’inizio della codifica. I team agili pianificano, progettano, sviluppano e testano in ogni sprint, quindi le fasi non si sono mai adattate davvero al loro lavoro. Il nuovo principio abbandona questa ipotesi e pone una domanda più pratica sull’incertezza.

La soglia del completamento probabile e l’incertezza di sviluppo significativa

Per valutare se il completamento è probabile, l’azienda deve considerare se esiste un’incertezza di sviluppo significativa. Il principio indica due indicatori:

• il software ha funzioni o caratteristiche nuove, uniche o non collaudate e l’incertezza su di esse non è ancora stata risolta tramite codifica e test;
• i requisiti di prestazione significativi non sono stati definiti o sono ancora soggetti a revisioni importanti.

Finché è presente uno dei due indicatori, la soglia non è raggiunta e i costi si spesano. Questo può ritardare la capitalizzazione per i prodotti sperimentali – per esempio una nuova funzionalità di machine learning – e al contempo farla iniziare prima e in modo più prevedibile per progetti di routine come un portale clienti su tecnologia consolidata.

Vecchio modello in tre fasi e ASU 2025-06 a confronto

Entrata in vigore e modalità di transizione

L’ASU 2025-06 si applica agli esercizi annuali che iniziano dopo il 15 dicembre 2027 e ai periodi infrannuali al loro interno, cioè all’esercizio 2028 per le aziende con esercizio coincidente con l’anno solare. L’adozione anticipata è consentita dall’inizio di un esercizio annuale. Le aziende possono adottarlo in tre modi:

• Prospettico — le nuove regole si applicano ai costi sostenuti dopo l’adozione;
• Transizione modificata — applicazione ai progetti ancora in corso alla data di adozione, con una rettifica cumulativa degli utili portati a nuovo di apertura;
• Retrospettico — rideterminazione dei periodi precedenti presentati.

Conviene adottarlo in anticipo nel 2026?

L’adozione anticipata ha senso per le aziende il cui sviluppo è in prevalenza agile e di routine, e meno per quelle con molto lavoro sperimentale o con investitori che confrontano da vicino i periodi. Valutate questi punti con il vostro revisore:

• A favore: meno mappatura manuale tra sprint e fasi e meno giudizi da documentare ogni trimestre.
• A favore: una policy che rispecchia il modo in cui lavorano davvero i team agili e di prodotto, più facile da spiegare a nuovi revisori e investitori.
• A favore: i costi di sviluppo dei siti web confluiscono nello stesso modello, quindi una sola policy copre prodotto e sito marketing.
• Contro: policy, controlli e configurazione dei sistemi vanno riscritti prima dell’inizio dell’esercizio di adozione.
• Contro: i progetti con funzionalità nuove potrebbero essere capitalizzati più tardi di oggi, riducendo nel breve periodo attività e risultato operativo.
• Contro: con il metodo prospettico la comparabilità con i periodi precedenti ne risente, e la rideterminazione completa richiede impegno.
• In ogni caso: la nuova informativa sul modello dell’ASC 360-10 richiede dati – movimentazione delle attività, vite utili e svalutazioni – che molte aziende oggi non raccolgono.

Come si contabilizza il software che vendete o concedete in licenza (ASC 985-20)?

Il software destinato a essere venduto, noleggiato o altrimenti commercializzato segue l’ASC 985-20: tutti i costi si spesano come ricerca e sviluppo finché non è dimostrata la fattibilità tecnologica, e si capitalizzano solo i costi sostenuti dopo quel momento e prima del rilascio generale sul mercato. Poiché la fattibilità arriva spesso tardi nel progetto, la maggior parte delle aziende soggette all’ASC 985-20 capitalizza molto poco.

La fattibilità tecnologica è dimostrata quando l’azienda ha completato una progettazione dettagliata del programma o, in sua assenza, un modello funzionante del prodotto. I team che non redigono in anticipo una progettazione dettagliata – il caso abituale nello sviluppo agile – arrivano a un modello funzionante verso la fine dello sviluppo, per cui la finestra di capitalizzazione può ridursi a poche settimane di test finali e di produzione dei master del prodotto.

I costi capitalizzati si ammortizzano prodotto per prodotto, usando il maggiore tra due importi: il rapporto tra i ricavi lordi del periodo e i ricavi totali attuali e futuri attesi, oppure l’ammortamento a quote costanti lungo la vita economica residua stimata del prodotto. A ogni data di bilancio il valore residuo non ammortizzato si confronta con il valore netto di realizzo e si svaluta se superiore. L’ASU 2025-06 non cambia nulla di tutto questo.

Dove si collocano i prodotti SaaS?

La maggior parte dei prodotti SaaS rientra nell’ASC 350-40 come software ad uso interno, non nell’ASC 985-20. Se i clienti accedono al software solo tramite un contratto di hosting e non hanno alcun diritto contrattuale di entrarne in possesso e gestirlo autonomamente, il fornitore usa il software internamente per erogare un servizio. I founder danno spesso per scontato che «vendiamo software» significhi ASC 985-20, e finiscono per spesare sviluppo che avrebbe potuto essere capitalizzato – oppure per avere policy incoerenti quando si aggiunge una versione on-premise. Se state progettando o facendo crescere una piattaforma SaaS, la nostra guida allo sviluppo di software SaaS copre il lato prodotto delle stesse decisioni.

Come si trattano i costi di sviluppo software secondo gli IFRS (IAS 38)?

Secondo gli IFRS, lo IAS 38 Attività immateriali divide ogni progetto interno in una fase di ricerca, sempre spesata, e una fase di sviluppo, che deve essere capitalizzata quando l’azienda è in grado di dimostrare tutti i sei criteri del paragrafo 57. A differenza degli US GAAP, gli IFRS usano lo stesso modello sia che il software sia usato internamente sia che venga venduto.

I sei criteri dello IAS 38 richiedono all’azienda di dimostrare:

1. la fattibilità tecnica di completare il software in modo che sia disponibile per l’uso o la vendita;
2. l’intenzione di completare il software e di usarlo o venderlo;
3. la capacità di usare o vendere il software;
4. in che modo il software genererà probabili benefici economici futuri, per esempio l’esistenza di un mercato o la sua utilità interna;
5. la disponibilità di adeguate risorse tecniche, finanziarie e di altro tipo per completare lo sviluppo e usare o vendere il software;
6. la capacità di valutare in modo attendibile le spese attribuibili al software durante lo sviluppo.

Quando tutti e sei sono soddisfatti, la capitalizzazione è obbligatoria, non facoltativa. Se l’azienda non riesce a distinguere la fase di ricerca da quella di sviluppo, lo IAS 38 tratta l’intero progetto come ricerca e lo spesa. Il software capitalizzato si ammortizza lungo la vita utile e si sottopone a impairment test secondo lo IAS 36; il software non ancora disponibile per l’uso va testato almeno una volta l’anno. Il modello della rideterminazione del valore è ammesso solo in presenza di un mercato attivo, cosa che per il software su misura non accade praticamente mai.

Per il SaaS acquistato anziché sviluppato, gli IFRS si discostano dall’ASU 2018-15. In base alle agenda decision dell’IFRS Interpretations Committee del 2019 e del 2021, i costi di configurazione e personalizzazione di un servizio cloud che il cliente non controlla si spesano di norma, a meno che creino un’attività separata controllata dal cliente, come codice su misura.

US GAAP e IFRS a colpo d’occhio

I gruppi che redigono il bilancio secondo entrambi i quadri – per esempio una capogruppo europea con una controllata statunitense – dovrebbero tracciare i costi al livello di dettaglio richiesto dal quadro più rigoroso e ricavare entrambi i risultati dagli stessi dati.

Come ammortizzare il software capitalizzato?

L’ammortamento del software ad uso interno inizia quando è pronto per l’uso previsto e segue di norma il metodo a quote costanti lungo la vita utile stimata. Molte aziende usano da tre a cinque anni, ma si tratta di una prassi diffusa e non di una regola: il periodo deve riflettere per quanto tempo il software porterà realmente valore prima di essere sostituito o riscritto.

• Data di inizio — quando il software, o un modulo utilizzabile separatamente, è sostanzialmente completato e pronto all’uso, anche se non è ancora stato distribuito a tutti gli utenti.
• Metodo — a quote costanti, a meno che un altro andamento rifletta meglio il consumo dei benefici; il software soggetto all’ASC 985-20 usa il maggiore tra l’importo basato sui ricavi e quello a quote costanti.
• Vita utile — considerate lo storico dei rilasci, la velocità di cambiamento della tecnologia sottostante ed eventuali piani di sostituzione della piattaforma.
• Revisioni — riesaminate le vite utili almeno una volta l’anno e adeguatele in modo prospettico se le aspettative cambiano.
• Indicatori di svalutazione — abbandono del progetto, cambiamento rilevante nell’uso del software, sforamenti di costo molto superiori al piano o decisione di sostituirlo in anticipo.
• Progetti abbandonati — quando il completamento non è più probabile, interrompete la capitalizzazione e svalutate l’attività invece di continuare a iscriverla.

Come tratta il fisco i costi di sviluppo software nel 2026 (Section 174A)?

Ai fini dell’imposta federale statunitense, il One Big Beautiful Bill Act del luglio 2025 ha introdotto la Section 174A, che consente di dedurre nell’anno in cui sono sostenute le spese di ricerca e sperimentazione svolte negli Stati Uniti – incluso esplicitamente lo sviluppo software – per i periodi d’imposta che iniziano dopo il 31 dicembre 2024. La ricerca svolta fuori dagli Stati Uniti deve ancora essere capitalizzata e ammortizzata in 15 anni secondo la Section 174.

La regola sull’estero riguarda chiunque sviluppi software con un team offshore o nearshore. Lo sviluppo svolto negli Stati Uniti è ora deducibile subito, mentre lo stesso lavoro svolto all’estero viene ripartito su 15 anni. Questa differenza va inclusa in ogni confronto del costo totale tra sviluppo interno, onshore e offshore.

• Le piccole imprese con ricavi lordi annui medi non superiori a 31 milioni di dollari possono applicare la deduzione immediata in modo retroattivo ai periodi d’imposta che iniziano dopo il 31 dicembre 2021, rettificando le dichiarazioni 2022–2024.
• Gli altri contribuenti possono dedurre il saldo residuo non ammortizzato delle spese domestiche ai sensi della Section 174 per il 2022–2024 interamente nel 2025 oppure in quote uguali tra 2025 e 2026.
• Procedura — l’IRS ha definito opzioni e cambi di metodo nella Rev. Proc. 2025-28.
• Bilancio e fisco — non procedono più insieme: un’attività capitalizzata a bilancio con una deduzione fiscale immediata genera una passività per imposte differite da monitorare.

La Section 174A disciplina la deduzione; il credito d’imposta per la ricerca della Section 41 è un beneficio distinto, con un proprio test in quattro parti. La nostra guida al credito d’imposta R&D per lo sviluppo software spiega nel dettaglio requisiti e documentazione.

Come tracciare i costi capitalizzabili in un team agile?

Per tracciare i costi capitalizzabili in un team agile, classificate il lavoro a livello di epic e ticket come nuova funzionalità, manutenzione o ricerca, registrate il tempo per persona e per epic e chiedete ai fornitori esterni di fatturare con la stessa struttura. In questo modo la capitalizzazione diventa un report mensile anziché una ricostruzione a fine trimestre.

1. Scrivete una policy di capitalizzazione. Definite quali attività si capitalizzano, quale soglia applicate (per fasi o ASU 2025-06), una dimensione minima di progetto, le vite utili standard e chi approva le eccezioni.
2. Classificate epic e ticket. Ogni epic riceve una categoria – nuova funzionalità, evoluzione, manutenzione, ricerca o infrastruttura – che i ticket ereditano. I product owner assegnano la classificazione, la finanza la verifica.
3. Registrate il tempo per persona e per epic. Basta una ripartizione settimanale leggera per epic; non servono timesheet al minuto, ma le stime devono essere ragionevoli e coerenti.
4. Fissate regole per i fornitori. Chiedete ai fornitori di sviluppo di fatturare per epic o funzionalità con le ore per ruolo, così da classificare i costi esterni come quelli del personale.
5. Chiudete ogni mese. Effettuate il cut-off a fine mese, calcolate i costi capitalizzabili di personale e fornitori, registrate le scritture e mettete in esercizio i moduli completati perché l’ammortamento parta in tempo.
6. Conservate le evidenze. Archiviate le autorizzazioni di finanziamento, le roadmap, le release note e il ragionamento alla base dei giudizi sul completamento probabile; il revisore li chiederà.
7. Fate una revisione trimestrale. Controllate la qualità della classificazione, riesaminate le vite utili e individuate i progetti abbandonati o fermi da svalutare.

Quali sono gli errori più frequenti nella contabilità dello sviluppo software?

Gli errori più frequenti nella contabilità dello sviluppo software sono capitalizzare lavoro che è ancora ricerca, capitalizzare la manutenzione, scegliere il principio sbagliato per il SaaS e non documentare i giudizi. Ciascuno emerge di solito alla prima revisione approfondita, quando correggerlo costa di più.

• Capitalizzare ricerca e prototipi — spike proof-of-concept ed esperimenti precedenti all’autorizzazione del finanziamento sono costi.
• Capitalizzare la manutenzione — correzioni di bug, refactoring e piccoli ritocchi all’interfaccia non aggiungono funzionalità, anche se occupano un intero sprint.
• Trattare il SaaS secondo l’ASC 985-20 — i prodotti in hosting senza diritto del cliente di entrarne in possesso sono software ad uso interno.
• Includere le spese generali nell’attività — affitto, HR e direzione generale sono costi per il software ad uso interno.
• Nessuna prova del completamento probabile — senza autorizzazioni di finanziamento e roadmap, il revisore può spostare in avanti l’inizio della capitalizzazione.
• Dimenticare la svalutazione — un modulo abbandonato ancora iscritto in bilancio sopravvaluta l’attivo.
• Trattare fiscalmente lo sviluppo estero come domestico — il lavoro svolto fuori dagli Stati Uniti si ammortizza in 15 anni e non si deduce ai sensi della Section 174A.

Esempio numerico: un progetto da 600.000 $, due esiti contabili

Lo stesso progetto da 600.000 $ può produrre un’attività di 480.000 $ o di 40.000 $ a seconda del modello US GAAP applicabile. L’esempio seguente è ipotetico, usa cifre tonde e presuppone che il progetto soddisfi le condizioni di finanziamento e completamento probabile dopo la fase di discovery; illustra il meccanismo e non riguarda alcuna azienda reale.

L’esito A tratta il prodotto come software ad uso interno o piattaforma SaaS secondo l’ASC 350-40. L’esito B lo tratta come software in licenza installato dai clienti secondo l’ASC 985-20, con la fattibilità tecnologica dimostrata tramite un modello funzionante tardi nella fase di test.

Nell’esito A, l’ammortamento a quote costanti di 480.000 $ in quattro anni aggiunge 120.000 $ di ammortamento all’anno. Se il software entra in produzione a inizio anno, l’impatto sul conto economico del primo anno è di 240.000 $ (120.000 $ spesati più 120.000 $ di ammortamento) invece di 600.000 $. Nell’esito B, quasi l’intero progetto riduce il risultato operativo dell’anno in cui viene speso.

L’ASU 2025-06 aggiunge una terza possibilità all’esito A. Se 150.000 $ della codifica riguardano una funzionalità nuova la cui incertezza è stata risolta solo tardi nello sviluppo, quell’importo si spesa secondo le nuove regole. L’attività capitalizzata scende a 330.000 $ e l’ammortamento annuo in quattro anni a 82.500 $. Il calcolo è semplice; ciò che va documentato è il giudizio sull’incertezza.

Domande frequenti

Pubblicato il 26 ottobre 2026. Fonti: testo integrale dell’ASU 2025-06 del FASB tramite PwC Viewpoint; Deloitte DART Heads Up (2025); commenti di AICPA & CIMA, RSM US e Grant Thornton sull’ASU 2025-06; IFRS Foundation, IAS 38 Attività immateriali; Baker Newman Noyes e Kaufman Rossin sulla Section 174A e sulla Rev. Proc. 2025-28; The Tax Adviser (AICPA) sulla definizione dei costi di sviluppo software. Questo articolo è un’informazione generale e non costituisce consulenza contabile, di revisione o fiscale.