ASC 350-40 — il tema di codificazione che chi cerca spesso digita come 350/40 — è la regola FASB per il software per uso interno: quando il costo di sviluppo viene spesato ora rispetto a essere capitalizzato come attività immateriale e ammortizzato in seguito. Nel modello legacy a tre fasi (ancora quello applicato dalla maggior parte dei dichiaranti fino alla data obbligatoria dell'ASU 2025-06), la risposta sta in una tabella:
| Fase | Cosa succede | Capitalizzare o spendere? |
|---|---|---|
| Progetto preliminare | Requisiti, demo dei fornitori, fattibilità, build-vs-buy | Spesare come sostenuto |
| Sviluppo dell'applicazione | Codifica, configurazione, test, integrazione dopo l'impegno della direzione | Capitalizzare i costi diretti di costruzione |
| Post-implementazione | Formazione, manutenzione, correzione di bug dopo il go-live | Spesare (la nuova funzionalità può riavviare la capitalizzazione) |
L'ASU 2025-06 (emesso il 18 settembre 2025; obbligatorio per i periodi annuali che iniziano dopo il 15 dicembre 2027) elimina quelle etichette di fase per una soglia di probabile-completamento e indica che più costi saranno spesati. Le sezioni seguenti coprono cosa include l'ASC 350-40, il dettaglio delle fasi, l'aggiornamento 2025, la lista di controllo capitalizzare/spendere, e come la scelta influisce su EBITDA e bilancio.
Cosa Copre l'ASC 350-40
L'ASC 350-40 è lo standard FASB per il software per uso interno — software che la tua azienda costruisce o acquista per le proprie operazioni piuttosto che per venderlo ai clienti come prodotto principale. Gli esempi includono:
- Sistemi CRM, ERP, HR o contabili interni
- Strumentazione per infrastruttura cloud e piattaforme DevOps
- Una piattaforma SaaS che gestisci per i clienti (il cliente vi accede come servizio, non come software con licenza che installa)
- Pipeline di dati interni, dashboard e strumenti di analisi
- Automazione personalizzata di flussi di lavoro o back-office
Se vendi software con licenza che i clienti installano sui propri computer, questo ricade sotto l'ASC 985-20 (software per vendita esterna), che ha regole diverse. La maggior parte delle aziende SaaS moderne ricade sotto l'ASC 350-40 perché i clienti consumano il software come servizio ospitato.
La domanda centrale a cui risponde lo standard: quando spendi denaro per costruire software, quel costo deve essere spesato immediatamente o capitalizzato come attività immateriale e ammortizzato nei periodi futuri?
Il Vecchio Modello a Tre Fasi (Pre-ASU 2025-06)
Per decenni, l'ASC 350-40 ha utilizzato un quadro basato sulle fasi. Sotto la guida legacy ancora in vigore per la maggior parte dei dichiaranti fino al 2027, lo sviluppo del software rientra in tre fasi distinte.
Fase 1: Fase del Progetto Preliminare
Questa è la fase esplorativa — definire i requisiti, valutare le tecnologie, ottenere demo dai fornitori e decidere se costruire, acquistare o rinunciare. Tutti i costi in questa fase sono spesati come sostenuti, simili alle spese di ricerca. Il ragionamento: finché la direzione 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 fornitore
Fase 2: Fase di Sviluppo dell'Applicazione
La capitalizzazione inizia quando la direzione autorizza il progetto, impegna i finanziamenti e il completamento è probabile. Questa fase copre la costruzione effettiva — codifica, test, configurazione, integrazione e installazione.
I costi capitalizzabili in questa fase includono tipicamente:
- Stipendi e benefici per sviluppatori, ingegneri QA e project manager (solo il tempo direttamente attribuibile a codifica, test e configurazione del software)
- Spese di consulenza esterna per il lavoro di sviluppo
- Licenze software e strumenti usati per costruire l'applicazione
- Costi diretti di materiali e servizi consumati nello sviluppo
- Costi di interesse (in casi limitati)
La capitalizzazione si ferma quando il software è sostanzialmente completo e pronto per l'uso previsto — generalmente quando i test sono finiti e il sistema è distribuito in produzione, anche se il rollout è graduale.
Fase 3: Fase Post-Implementazione
Dopo il go-live, i costi correnti tornano al trattamento di spesa. Formazione, manutenzione, correzione di bug e supporto di routine sono tutti spesati. L'eccezione: i miglioramenti che aggiungono nuova funzionalità (non solo correggono o mantengono la funzionalità esistente) possono essere capitalizzati usando gli stessi criteri della Fase 2.
Il Maggiore Aggiornamento 2025: ASU 2025-06
Il 18 settembre 2025, il FASB ha emesso l'ASU 2025-06, che modernizza significativamente 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 è sparito. Il FASB ha esplicitamente rimosso tutti i riferimenti alle fasi di progetto perché il quadro legacy non si adattava alle moderne pratiche di sviluppo agile e iterativo, dove i requisiti evolvono e le "fasi" si sovrappongono o procedono in parallelo.
La Nuova Soglia Basata su Principi
Sotto lo standard rivisto, capitalizzi i costi del software solo quando entrambe queste condizioni sono soddisfatte:
- Autorizzazione della direzione: La direzione ha autorizzato e si è impegnata a finanziare il progetto.
- Soglia di probabile-completamento: È probabile che il progetto sarà completato e il software svolgerà la funzione prevista.
Questo secondo test sta facendo un lavoro reale. Il FASB ha introdotto un concetto chiamato incertezza significativa di sviluppo per valutare se il completamento è probabile. Devi valutare:
- Se il software include caratteristiche nuove o non comprovate che non sono state validate tramite codifica o test
- Se i requisiti di prestazione sono ancora indeterminati o soggetti a revisione sostanziale
Se esiste incertezza significativa, la capitalizzazione deve essere differita finché l'incertezza non è risolta. Il FASB ha segnalato che si aspetta che la nuova regola risulti in più costi del software spesati, particolarmente nelle aziende SaaS dove i requisiti iterano continuamente.
Cosa Significa Questo in Pratica
Per una startup che costruisce qualcosa di genuinamente nuovo — una piattaforma di agenti AI, un motore di automazione innovativo — la nuova regola può spingere più spesa nelle spese operative prima. Per aziende mature che migliorano sistemi ben definiti, l'impatto pratico sarà minore. In ogni caso, il passaggio da un controllo meccanico di fase a una soglia basata su giudizio significa che le aziende necessitano di documentazione più chiara delle decisioni della direzione, fattibilità tecnica e stato del progetto.
Cosa Puoi e Non Puoi Capitalizzare: Una Lista di Controllo Pratica
Sia che tu applichi il modello legacy a fasi o il nuovo test basato su principi, la linea tra spesa capitalizzabile e spesa da spesare è simile nello spirito. Ecco una lista di controllo operativa.
Generalmente Capitalizzabile
- Costi di lavoro diretto per sviluppatori, designer e QA durante la fase di costruzione
- Tasse sul libro paga e benefici allocati per quei dipendenti
- Spese di consulenza esterna e appaltatori per il lavoro di sviluppo
- Software, strumenti e costi di infrastruttura cloud consumati direttamente nello sviluppo
- Costi per sviluppare nuova funzionalità post-lancio (miglioramenti che espandono materialmente le capacità)
- Costi per sviluppare software di conversione (il software che migra i dati vecchi al nuovo), a differenza dell'attività di conversione dei dati stessa
Generalmente Spesato
- Ricerca preliminare, selezione dei fornitori e analisi di fattibilità
- Formazione dei dipendenti sul nuovo sistema
- Pulizia dei dati, riconciliazione e migrazione dei registri
- Manutenzione di routine, correzione di bug e refactoring minore
- Costi del software sostenuti durante periodi di incertezza significativa di sviluppo
- Spese generali amministrative non direttamente legate allo sviluppo
- Marketing, supporto e attività di successo dei clienti post-lancio
Il Problema del Tracciamento del Tempo
La sfida pratica più grande è allocare il tempo ingegneristico. Un ingegnere senior che spende 40 ore a settimana è improbabile che svolga lavoro 100% capitalizzabile — sta anche facendo debug della produzione, mentoring dei colleghi, partecipando a standup e revisionando pull request per sistemi legacy. Senza un metodo difendibile di tracciamento del tempo (ticket ingegneristici etichettati per progetto, software di tracciamento del tempo o sondaggi formali di allocazione), le stime di capitalizzazione falliranno lo scrutinio di audit.
L'Impatto sul Bilancio
Capitalizzare rispetto a spendere lo stesso dollaro produce bilanci drammaticamente diversi.
Effetto sul Conto Economico
Un costo capitalizzato non tocca il conto economico nel periodo speso. Invece, viene ammortizzato — tipicamente a quote costanti su tre-cinque anni per il software per uso interno. Quindi $1M di spesa ingegneristica capitalizzata nell'Anno 1 potrebbe creare solo $200K-$333K di spesa 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ù costo di sviluppo sposta dollari dalla spesa operativa (che riduce l'EBITDA) all'ammortamento (che non lo riduce). Gli investitori che scrutano le metriche SaaS spesso guardano all'"EBITDA prima di R&S capitalizzata" o ai calcoli della regola dei 40 utilizzando R&S in contanti per vedere attraverso questa dinamica.
Effetto sul Bilancio
Il software capitalizzato appare come un'attività immateriale a lungo termine, spesso etichettata "Costi di sviluppo software capitalizzati" o simile. Questo:
- Aumenta le attività totali e il patrimonio netto
- Migliora il rendimento sulle attività (ROA) solo se gli utili crescono più velocemente della base patrimoniale
- Crea un'attività che deve essere testata per riduzione di valore se il progetto viene abbandonato o il suo valore diminuisce
Se un progetto viene abbandonato a metà sviluppo, i costi precedentemente capitalizzati devono essere svalutati — il che produce una perdita improvvisa, spesso materiale. Questo è uno dei motivi 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. Investitori sofisticati si adattano a questo quando confrontano le aziende — ma il numero in evidenza ne beneficia comunque.
Errori Comuni che Mettono nei Guai le Aziende
I revisori e gli acquirenti vedono gli stessi errori ripetersi.
Capitalizzare Costi Pre-Autorizzazione
L'errore classico è capitalizzare il tempo ingegneristico speso prima che la direzione 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 o firme scritte che stabiliscono quando la direzione si è impegnata.
Nessuna Documentazione a Livello di Progetto
Se un regolatore o un revisore chiede "mostrami i progetti che hai capitalizzato", e puoi solo indicare la spesa ingegneristica generale, perderai. Hai bisogno di registri progetto per progetto: ambito, data di autorizzazione, budget, stato e tempo addebitato.
Trattare Tutto il Tempo Ingegneristico come Capitalizzabile
Gli ingegneri senior correggono bug, revisionano codice, partecipano a riunioni e rispondono agli incidenti. Niente di tutto ciò è capitalizzabile. Le aziende che semplicemente moltiplicano il libro paga del team ingegneristico per una percentuale raramente sopravvivono all'audit.
Continuare a Capitalizzare Dopo il Lancio
Nel momento in cui il software è pronto per l'uso previsto, la capitalizzazione si ferma. Correzioni di bug, ottimizzazione delle prestazioni e miglioramenti minori dopo quel punto sono spese operative. Nuove funzionalità separate e delimitate possono iniziare un nuovo periodo di capitalizzazione — ma il lavoro di routine post-lancio non può.
Dimenticare il Test per Riduzione di Valore
Il software capitalizzato è un'attività, e le attività devono essere svalutate se il loro valore diminuisce. Se metti in naftalina un prodotto, elimini una funzionalità o riscrivi fondamentalmente il sistema, devi rivalutare e probabilmente svalutare 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 la firma del tuo CFO o del comitato di audit.
-
Traccia il tempo ingegneristico a livello di progetto. Questo è l'input fondamentale. Che tu usi etichette Jira, tag personalizzati in un tracker di progetti o fogli di presenza formali, devi difendere "l'ingegnere X ha speso Y% del proprio tempo su lavoro capitalizzabile nel progetto Z."
-
Documenta l'approvazione della direzione. Ogni progetto capitalizzabile necessita di prova di autorizzazione — approvazione scritta datata, verbali del consiglio o una carta di progetto firmata dalla leadership.
-
Rivaluta regolarmente l'incertezza significativa. Sotto 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 leadership ingegneristica sono ragionevoli.
-
Costruisci programmi di ammortamento per progetto. Ogni progetto capitalizzato inizia ad ammortizzarsi quando è pronto per l'uso, e devi tracciare la base di costo di quell'attività, l'ammortamento accumulato e la vita residua.
-
Testa per riduzione di valore quando i progetti cambiano. Ogni volta che abbandoni, riscrivi materialmente o metti in pensione lavoro capitalizzato, esegui un'analisi di riduzione di valore e registra le svalutazioni come necessario.
Perché Questo Conta per la Contabilità
La capitalizzazione del software è una di quelle aree dove la disciplina contabile del giorno uno ripaga anni dopo. Gli investitori durante un round di Serie B tireranno il tuo bilancio di verifica; gli acquirenti in un processo di vendita tracceranno le transazioni fino alle registrazioni contabili; l'IRS potrebbe confrontare il tuo trattamento GAAP con il tuo trattamento fiscale R&S Sezione 174, che ha le sue regole. Se i tuoi libri non separano i progetti capitalizzati dalle spese operative, non possono collegare i costi del tempo ingegneristico a progetti specifici, o non mantengono programmi di ammortamento puliti, ogni ciclo di audit e due diligence diventa doloroso.
La soluzione è semplice nel concetto: mantenere una struttura contabile pulita, tracciare il tempo a livello di progetto e documentare le decisioni dietro ogni registrazione di capitalizzazione. Fare questo dall'inizio evita costose pulizie in seguito.
Mantieni la Tua Contabilità del Software Pronta per l'Audit
Sia che tu stia capitalizzando la tua prima piattaforma interna o gestendo programmi di ammortamento su dozzine di progetti, registri finanziari puliti sono la base. Beancount.io fornisce contabilità a testo semplice che ti dà libri trasparenti e versionati — ogni registrazione tracciabile, ogni conto verificabile, ogni report riproducibile. Per aziende software che tracciano sviluppo capitalizzato su più progetti, avere libri che si leggono come codice è un vantaggio serio. Inizia gratis e scopri perché sviluppatori e professionisti della finanza stanno passando alla contabilità a testo semplice.
