Un sondaggio Gartner del 2024 ha rilevato che il 63% dei fondatori di SaaS in fase iniziale classifica erroneamente i costi di sviluppo del software. L'errore costa loro su due fronti: gli investitori scontano i loro bilanci quando le classificazioni app appaiono approssimative, e i revisori segnalano il problema durante la due diligence, il che può ritardare i cicli di raccolta fondi o di vendita di mesi.
La capitalizzazione del software non è solo un dettaglio contabile. Influisce direttamente sull'EBITDA, sullo stato patrimoniale e su come la tua azienda appare a finanziatori, investitori e acquirenti. Le regole dell'ASC 350-40 – e un importante aggiornamento del 2025 – determinano quali costi impattano immediatamente il conto economico e quali vengono ripartiti su più anni.
Questa guida illustra cosa richiede lo standard, la recente revisione dell'ASU 2025-06, i costi che puoi capitalizzare, quelli che non puoi e le conseguenze sul bilancio di una corretta applicazione.
Cosa Copre l'ASC 350-40
L'ASC 350-40 è lo standard FASB per il software per uso interno – software che la tua azienda sviluppa o acquista per le proprie operazioni, non per venderlo ai clienti come prodotto principale. Esempi includono:
- Sistemi CRM, ERP, HR o contabili interni
- Strumenti per infrastrutture cloud e piattaforme DevOps
- Una piattaforma SaaS che gestisci per i clienti (il cliente vi accede come servizio, non come software concesso in licenza da installare)
- Pipeline di dati, dashboard e strumenti di analisi interni
- Automazione personalizzata di flussi di lavoro o back-office
Se vendi software con licenza che i clienti installano sulle proprie macchine, questo rientra nell'ASC 985-20 (software per vendita esterna), che ha regole diverse. La maggior parte delle aziende SaaS moderne rientra nell'ASC 350-40 perché i clienti consumano il software come servizio ospitato.
La domanda centrale a cui risponde lo standard: quando spendi soldi per sviluppare software, tale costo deve essere spesato immediatamente o capitalizzato come attività immateriale e ammortizzato in periodi futuri?
Il Vecchio Modello a Tre Fasi (Pre-ASU 2025-06)
Per decenni, l'ASC 350-40 ha utilizzato un quadro di riferimento basato sulle fasi. Secondo la guida legacy ancora in vigore per la maggior parte dei dichiaranti fino al 2027, lo sviluppo del software si suddivide in tre fasi distinte.
Fase 1: Fase Preliminare del Progetto
Questa è la fase esplorativa – definire i requisiti, valutare le tecnologie, ottenere demo dai fornitori e decidere se sviluppare, acquistare o rinunciare. Tutti i costi in questa fase sono spesati nel momento in cui vengono sostenuti, simili alle spese di ricerca. Il ragionamento: finché il management non si impegna, non hai ancora un'attività probabile.
Le attività qui includono:
- Formulazione concettuale e alternative di progettazione
- Demo dei fornitori e valutazioni tecnologiche
- Analisi costi-benefici e studi di fattibilità
- Selezione finale di un approccio o di un fornitore
Fase 2: Fase di Sviluppo dell'Applicazione
La capitalizzazione inizia quando il management autorizza il progetto, si impegna a finanziarlo e il completamento è probabile. Questa fase copre la costruzione effettiva – codifica, test, configurazione, integrazione e installazione.
I costi capitalizzabili in questa fase in genere includono:
- Stipendi e benefit per sviluppatori, ingegneri QA e project manager (solo il tempo direttamente attribuibile a codifica, test e configurazione del software)
- Spese di consulenza esterna per lavori di sviluppo
- Licenze software e strumenti utilizzati per sviluppare l'applicazione
- Costi diretti di materiali e servizi consumati nello sviluppo
- Oneri finanziari (in casi limitati)
La capitalizzazione cessa quando il software è sostanzialmente completo e pronto per l'uso previsto – generalmente quando i test sono terminati e il sistema è implementato in produzione, anche se il rilascio è graduale.
Fase 3: Fase Post-Implementazione
Dopo il go-live, i costi correnti tornano a essere trattati come spese. La formazione, la manutenzione, le correzioni di bug e il supporto ordinario sono tutti spesati. L'eccezione: i miglioramenti che aggiungono nuove funzionalità (non solo correggono o mantengono funzionalità esistenti) possono essere capitalizzati utilizzando gli stessi criteri della Fase 2.
Il Grande Aggiornamento del 2025: ASU 2025-06
Il 18 settembre 2025, il FASB ha emesso l'ASU 2025-06, che modernizza in modo significativo l'ASC 350-40. L'aggiornamento è obbligatorio per i periodi annuali che iniziano dopo il 15 dicembre 2027, con adozione anticipata consentita.
Il cambiamento è strutturale: il modello a tre fasi è scomparso. Il FASB ha esplicitamente rimosso tutti i riferimenti alle fasi del progetto perché il quadro legacy non si adattava alle moderne pratiche di sviluppo agile e iterativo, dove i requisiti si evolvono e le "fasi" si sovrappongono o procedono in parallelo.
La Nuova Soglia Basata su Principi
Secondo lo standard rivisto, capitalizzi i costi del software solo quando vengono soddisfatte entrambe queste condizioni:
- Autorizzazione del management: Il management ha autorizzato e si è impegnato a finanziare il progetto.
- Soglia di probabile completamento: È probabile che il progetto venga completato e che il software svolga la sua funzione prevista.
Questo secondo test è quello che fa la differenza. Il FASB ha introdotto un concetto chiamato incertezza significativa sullo sviluppo per valutare se il completamento è probabile. Devi valutare:
- Se il software include funzionalità nuove o non comprovate che non sono state validate tramite codifica o test
- Se i requisiti di prestazione sono ancora indeterminati o soggetti a revisioni sostanziali
Se esiste un'incertezza significativa, la capitalizzazione deve essere rinviata fino a quando l'incertezza non viene risolta. Il FASB ha segnalato che si aspetta che la nuova regola porti a più costi software spesati, in particolare nelle aziende SaaS dove i requisiti iterano continuamente.
Cosa Significa in Pratica
Per una startup che sviluppa qualcosa di veramente nuovo – una piattaforma di agenti AI, un motore di automazione innovativo – la nuova regola potrebbe spingere più spese nei costi operativi prima. Per le aziende mature che migliorano sistemi ben definiti, l'impatto pratico sarà minore. In ogni caso, il passaggio da un controllo meccanico delle fasi a una soglia basata sul giudizio significa che le aziende necessitano di una documentazione più chiara delle decisioni del management, della fattibilità tecnica e dello stato di avanzamento del progetto.
Cosa Puoi e Non Puoi Capitalizzare: Una Checklist Pratica
Che tu stia applicando il modello legacy a fasi o il nuovo test basato su principi, la linea di demarcazione tra spesa capitalizzabile e spesabile è simile nello spirito. Ecco una checklist operativa.
Generalmente Capitalizzabili
- Costi diretti del lavoro per sviluppatori, designer e QA durante la fase di costruzione
- Imposte sui salari e benefit allocati per quei dipendenti
- Spese di consulenza esterna e compensi per appaltatori per lavori di sviluppo
- Costi di software, strumenti e infrastruttura cloud direttamente consumati nello sviluppo
- Costi per sviluppare nuove funzionalità dopo il lancio (miglioramenti che espandono materialmente le capacità)
- Costi per sviluppare software di conversione (il software che migra i dati vecchi a quelli nuovi), in opposizione all'attività di conversione dati stessa
Generalmente Spesati
- Ricerca preliminare, selezione del fornitore e analisi di fattibilità
- Formazione dei dipendenti sul nuovo sistema
- Pulizia, riconciliazione e migrazione dei dati
- Manutenzione ordinaria, correzioni di bug e refactoring minori
- Costi software sostenuti durante periodi di significativa incertezza sullo sviluppo
- Spese generali amministrative non direttamente collegate allo sviluppo
- Attività di marketing, supporto e successo del cliente post-lancio
Il Problema della Tracciabilità del Tempo
La sfida pratica più grande è allocare il tempo di ingegneria. È improbabile che un ingegnere senior che lavora 40 ore a settimana svolga lavoro al 100% capitalizzabile – sta anche correggendo bug in produzione, facendo da mentore ai colleghi, partecipando a standup e revisionando le pull request per i sistemi legacy. Senza un metodo difendibile di tracciamento del tempo (ticket di ingegneria etichettati per progetto, software di time-tracking o sondaggi formali di allocazione), le stime di capitalizzazione non supereranno il controllo di audit.
L'Impatto sul Bilancio
Capitalizzare rispetto a spesare lo stesso dollaro produce bilanci drammaticamente diversi.
Effetto sul Conto Economico
Un costo capitalizzato non impatta il conto economico nel periodo in cui è stato speso. Invece, viene ammortizzato – tipicamente a quote costanti in tre-cinque anni per il software per uso interno. Quindi, 1 milione di dollari di spesa di ingegneria capitalizzata nell'Anno 1 potrebbe creare solo da 200.000 a 333.000 dollari di spese di ammortamento ogni anno, lasciando il reddito operativo dell'Anno 1 materialmente più alto.
Questo è il motivo per cui l'EBITDA riceve un impulso dalla capitalizzazione. L'ammortamento è, per definizione, escluso dall'EBITDA – quindi capitalizzare più costi di sviluppo sposta dollari dalle spese operative (che riducono l'EBITDA) all'ammortamento (che non lo riduce). Gli investitori che analizzano le metriche SaaS spesso guardano all'"EBITDA prima della R&S capitalizzata" o ai calcoli della regola del 40 utilizzando la R&S in contanti per vedere attraverso questa dinamica.
Effetto sullo Stato Patrimoniale
Il software capitalizzato appare come un'attività immateriale a lungo termine, spesso etichettata come "Costi di Sviluppo Software Capitalizzati" o simile. Questo:
- Aumenta il totale delle attività e del patrimonio netto
- Migliora il rendimento delle attività (ROA) solo se gli utili crescono più velocemente della base patrimoniale
- Crea un'attività che deve essere testata per la riduzione di valore se il progetto viene abbandonato o il suo valore diminuisce
Se un progetto viene abbandonato a metà dello sviluppo, i costi precedentemente capitalizzati devono essere svalutati – il che produce una perdita improvvisa, spesso materiale. Questa è una delle ragioni per cui il nuovo ASU 2025-06 enfatizza così tanto la soglia di probabile completamento.
Effetto sul Rendiconto Finanziario
I costi di sviluppo capitalizzati sono tipicamente classificati come attività di investimento (non operative), il che rende il flusso di cassa operativo più forte. Gli investitori sofisticati correggono questo dato quando confrontano le aziende – ma il numero principale ne beneficia comunque.
Errori Comuni che Mettono nei Guai le Aziende
Revisori e acquirenti vedono gli stessi errori più e più volte.
Capitalizzare i Costi Pre-Autorizzazione
L'errore classico è capitalizzare il tempo di ingegneria speso prima che il management approvasse formalmente il progetto. Senza un'autorizzazione documentata e un impegno di finanziamento, quei costi avrebbero dovuto essere spesati. Assicurati di avere verbali di riunione, approvazioni del consiglio di amministrazione o nulla osta scritti che stabiliscano quando il management si è impegnato.
Nessuna Documentazione a Livello di Progetto
Se un regolatore o un revisore chiede "mostrami i progetti che hai capitalizzato", e puoi solo indicare una spesa di ingegneria generale, perderai. Hai bisogno di registrazioni progetto per progetto: ambito, data di autorizzazione, budget, stato e tempo addebitato.
Trattare Tutto il Tempo di Ingegneria come Capitalizzabile
Gli ingegneri senior correggono bug, revisionano il codice, partecipano alle riunioni e rispondono agli incidenti. Niente di tutto ciò è capitalizzabile. Le aziende che semplicemente moltiplicano la busta paga del team di ingegneria per una certa percentuale raramente sopravvivono a un audit.
Continuare a Capitalizzare Dopo il Lancio
Nel momento in cui il software è pronto per l'uso previsto, la capitalizzazione cessa. Le correzioni di bug, l'ottimizzazione delle prestazioni e i miglioramenti minori dopo quel punto sono spese operative. Nuove funzionalità con ambito separato possono avviare un nuovo periodo di capitalizzazione – ma il lavoro ordinario post-lancio non può.
Dimenticare il Test per la Riduzione di Valore
Il software capitalizzato è un'attività, e le attività devono essere svalutate se il loro valore diminuisce. Se accantoni un prodotto, dismetti una funzionalità o riscrivi fondamentalmente il sistema, devi rivalutare e probabilmente cancellare il saldo precedente.
Come Impostare un Processo Difendibile
Se decidi che la capitalizzazione è giusta per la tua azienda, il processo conta tanto quanto la politica.
-
Scrivi una politica di capitalizzazione del software. Definisci quali progetti si qualificano, il tuo processo di autorizzazione, la tua stima della vita utile e come allocherai il tempo. Ottieni l'approvazione del tuo CFO o del comitato di audit.
-
Traccia il tempo di ingegneria a livello di progetto. Questo è l'input fondamentale. Che tu usi etichette Jira, tag personalizzati in un tracker di progetto o fogli presenze formali, devi essere in grado di difendere "l'ingegnere X ha speso Y% del suo tempo su lavoro capitalizzabile sul progetto Z."
-
Documenta l'approvazione del management. Ogni progetto capitalizzabile necessita di prove di autorizzazione – approvazione scritta datata, verbali del consiglio di amministrazione o una carta di progetto firmata dalla dirigenza.
-
Rivaluta l'incertezza significativa regolarmente. Secondo la nuova regola, devi monitorare se le funzionalità sono ancora nuove o non comprovate e se i requisiti si stanno stabilizzando. Revisioni trimestrali con la dirigenza di ingegneria sono ragionevoli.
-
Crea piani di ammortamento per progetto. Ogni progetto capitalizzato inizia ad essere ammortizzato quando è pronto per l'uso e devi tracciare la base di costo di quell'attività, l'ammortamento accumulato e la vita residua.
-
Testa la riduzione di valore quando i progetti cambiano. Ogni volta che abbandoni, riscrivi materialmente o dismetti lavoro capitalizzato, esegui un'analisi di riduzione di valore e registra le svalutazioni necessarie.
Perché Questo è Importante per la Contabilità
La capitalizzazione del software è una di quelle aree in cui la disciplina contabile fin dal primo giorno ripaga anni dopo. Gli investitori durante un round di Serie B estrarranno il tuo saldo di verifica; gli acquirenti in un processo di vendita tracceranno le transazioni fino alle scritture contabili; l'IRS potrebbe confrontare il tuo trattamento GAAP con il tuo trattamento fiscale R&S ai sensi della Sezione 174, che ha le sue regole. Se i tuoi libri contabili non separano i progetti capitalizzati dalle spese operative, non possono collegare gli addebiti di tempo di ingegneria a progetti specifici, o non mantengono piani di ammortamento puliti, ogni ciclo di audit e due diligence diventa doloroso.
La soluzione è semplice in teoria: mantenere una struttura contabile pulita, tracciare il tempo a livello di progetto e documentare le decisioni alla base di ogni voce di capitalizzazione. Farlo dall'inizio evita costose pulizie successive.
Mantieni la Tua Contabilità Software Pronta per l'Audit
Che tu stia capitalizzando la tua prima piattaforma interna o gestendo piani di ammortamento su dozzine di progetti, registri finanziari puliti sono il fondamento. Beancount.io offre una contabilità in testo semplice che ti dà libri contabili trasparenti e con controllo di versione – ogni voce tracciabile, ogni account verificabile, ogni report riproducibile. Per le aziende software che tracciano lo sviluppo capitalizzato su più progetti, avere libri contabili che si leggono come codice è un serio vantaggio. Inizia gratuitamente e scopri perché sviluppatori e professionisti finanziari stanno passando alla contabilità in testo semplice.