Chiedi a un responsabile dell'ingegneria del software quando è "iniziato" un progetto e otterrai un numero di sprint. Chiedi la stessa cosa al loro controller e, secondo le regole contabili che hanno governato il software per uso interno dal 1998, la risposta doveva provenire da una rigida lista di controllo in tre fasi che presume che nessuno scriva codice finché i requisiti non sono bloccati. Chiunque abbia rilasciato software nell'ultimo decennio sa che non funziona più così — e a settembre 2025, anche il FASB lo ha finalmente ammesso.
L'Accounting Standards Update (ASU) 2025-06, Immobilizzazioni immateriali—Avviamento e altro—Software per uso interno (Sottotema 350-40): Miglioramenti mirati alla contabilizzazione del software per uso interno, elimina completamente il vecchio test basato sulle fasi e lo sostituisce con un'unica domanda basata sul giudizio: è probabile che questo software venga effettivamente completato e faccia ciò che deve fare? Per qualsiasi azienda che sviluppa software internamente — e specialmente per gli ambienti agile per cui la vecchia regola non è mai stata progettata — questo cambia quando i costi di sviluppo passano dal conto economico allo stato patrimoniale, e di quanto.
Il Problema: Un Manuale del 1998 per lo Sviluppo a Cascata
La guida che l'ASU 2025-06 sostituisce, l'ASC 350-40 (originariamente SOP 98-1), è stata scritta quando "sviluppo software" significava un processo lineare a cascata. Suddivideva ogni progetto software per uso interno in tre fasi sequenziali:
- Fase preliminare del progetto — formulazione concettuale, valutazione delle alternative, selezione del fornitore. Tutto qui viene spesato come sostenuto.
- Fase di sviluppo dell'applicazione — codifica effettiva, configurazione e test. I costi qui vengono capitalizzati.
- Fase post-implementazione — formazione e manutenzione. Spesato di nuovo.
Questo quadro funziona bene se un team passa tre mesi a scrivere un documento dei requisiti, ottiene l'approvazione e poi inizia a costruire. Crolla nel momento in cui un team esegue sprint di due settimane, rilascia incrementi e rivede l'ambito ad ogni retrospettiva. In un ambiente agile, le fasi "preliminare" e "sviluppo dell'applicazione" non sono fasi sequenziali — sono intrecciate, a volte all'interno dello stesso sprint. Le aziende e i loro revisori hanno passato anni a discutere a quale fase appartenesse effettivamente un dato sprint di due settimane, e la risposta onesta era spesso "un po' di entrambi, crediamo". La stessa attività di sensibilizzazione del FASB ha rilevato che le parti interessate segnalavano costantemente questa come una delle aree più dolorose dal punto di vista operativo dei GAAP da applicare in modo coerente.
La Soluzione: Un Test, Non Tre Fasi
L'ASU 2025-06 rimuove ogni riferimento alle vecchie fasi del progetto. Al loro posto, stabilisce un'unica soglia di "probabile completamento" . Secondo la nuova guida, un'azienda capitalizza i costi del software per uso interno una volta che entrambe le seguenti condizioni sono vere contemporaneamente:
- La direzione ha autorizzato e si è impegnata a finanziare il progetto. Questo non è un concetto nuovo — esisteva anche nella vecchia guida — ma ora svolge un ruolo maggiore come una delle due sole condizioni di blocco, invece di essere sepolto all'interno dell'analisi delle fasi.
- È probabile che il progetto venga completato e che il software venga utilizzato per la sua funzione prevista. Questo è l'elemento veramente nuovo, ed è qui che risiede il giudizio.
Questo secondo criterio richiede di valutare se esiste ancora un'incertezza significativa sullo sviluppo. Il FASB individua due fonti principali di tale incertezza:
- Tecnologia non comprovata o funzionalità innovative la cui fattibilità non è stata ancora dimostrata attraverso codifica e test effettivi — non un documento di progettazione, non un capitolato, ma una prova funzionante.
- Requisiti prestazionali non definiti o ancora mutevoli — lo standard li definisce come "ciò di cui l'entità ha bisogno che il software faccia, ad esempio, funzioni o caratteristiche". Se il team sta ancora dibattendo attivamente su ciò che il prodotto deve fare, tale incertezza non è stata risolta.
In pratica, ciò significa che la tempistica di capitalizzazione ora segue l'evidenza di fattibilità, non la fase di calendario. Un team che esegue uno spike per una funzionalità tecnicamente innovativa per due sprint prima di impegnarsi a svilupparla seriamente dovrebbe spesare quegli sprint di spike — l'incertezza sulla possibilità stessa di realizzarla non è stata ancora risolta. Una volta che lo spike dimostra la fattibilità e la direzione si impegna con un budget per lo sviluppo completo, la soglia di "probabile completamento" viene raggiunta e i costi di sviluppo successivi vengono capitalizzati, indipendentemente dalle cerimonie agile.
Perché il FASB Dice che la Capitalizzazione Non Cambierà Molto — Tranne per il SaaS
Il FASB stesso prevede che, per la maggior parte del software per uso interno on-premise o basato su licenza, gli emendamenti non modificheranno drasticamente i risultati di capitalizzazione — le aziende già capitalizzavano una volta iniziata la codifica vera e propria, e il nuovo test porta approssimativamente allo stesso punto, solo senza l'esercizio di etichettatura delle fasi.
Il software sviluppato per la fornitura tramite SaaS o cloud è una storia diversa. Il FASB si aspetta esplicitamente che la capitalizzazione diminuisca per questi progetti. Il ragionamento: i prodotti SaaS sono, per loro natura, costruiti e ricostruiti continuamente, con un'incertezza tecnica e di prodotto significativa che persiste in profondità nella tempistica di sviluppo — a volte fino a poco prima del rilascio di una funzionalità. Con il test di probabile completamento, quell'incertezza persistente significa che molti costi di sviluppo SaaS non supereranno la soglia di capitalizzazione fino a molto più tardi nel processo di sviluppo di quanto avrebbe implicato il vecchio modello a fasi. L'effetto netto: una parte maggiore della massa salariale ingegneristica di un prodotto SaaS finisce come costo di R&S del periodo corrente piuttosto che come attività pluriennale da ammortizzare. Questo è un cambiamento significativo per l'EBITDA riportato e la base patrimoniale di qualsiasi azienda SaaS.
Un Esempio Concreto: Due Team, Due Risultati
Supponiamo che un'azienda SaaS con 40 dipendenti decida di costruire un modulo di previsione basato sull'IA per il suo prodotto. Ecco come le vecchie e le nuove regole tratterebbero la stessa costruzione di otto mesi.
Secondo il vecchio modello a fasi, il team finanziario avrebbe cercato di tracciare una linea: le prime sei settimane di raccolta dei requisiti e valutazione dei fornitori erano "preliminari" (spesate), e tutto dopo la riunione di kickoff era "sviluppo dell'applicazione" (capitalizzato) — anche se il team di ingegneria ha passato i due mesi successivi a eseguire spike esplorativi per capire se l'approccio di previsione scelto potesse raggiungere un'accuratezza accettabile con volumi di dati di produzione. Secondo la lettera della vecchia regola, una volta che la "fase" era stata superata, anche quegli sprint di spike venivano spesso capitalizzati, perché tecnicamente avvenivano dopo la riunione di kickoff.
Secondo l'ASU 2025-06, il team finanziario invece si chiede: quando è diventato probabile che questa funzionalità sarebbe stata completata e avrebbe funzionato come previsto? Se l'approccio all'accuratezza era ancora non comprovato per i primi due mesi — il team stava testando tre diversi approcci di modellazione e non sapeva se nessuno avrebbe superato la soglia — l'intero periodo di esplorazione viene spesato, indipendentemente dalla "fase" in cui cadeva sul calendario. La capitalizzazione inizia solo quando il team sceglie un approccio convalidato e la direzione si impegna con un budget per svilupparlo, che in questo esempio potrebbe essere il terzo mese, non il secondo. Il risultato: un'attività capitalizzata più piccola, un costo di R&S del periodo corrente più grande e — cosa importante — un numero che il CFO può effettivamente difendere in una revisione, perché è legato a un punto decisionale specifico e documentato, piuttosto che a un'etichetta di fase applicata a posteriori.
Questo è esattamente il cambiamento che il FASB si aspetta nel settore SaaS: meno "lo abbiamo chiamato sviluppo dell'applicazione perché è successo dopo la chiamata di kickoff" e più "possiamo indicare lo sprint in cui il rischio tecnico è stato superato".
Date di Efficacia e Transizione
L'ASU 2025-06 è efficace per tutte le entità — pubbliche e private — per i periodi di rendicontazione annuali che iniziano dopo il 15 dicembre 2027 e per i periodi infrannuali all'interno di tali anni. L'adozione anticipata è consentita per qualsiasi entità, in qualsiasi periodo infrannuale o annuale, una volta emesso lo standard.
Le entità possono applicare gli emendamenti utilizzando uno dei tre approcci di transizione: prospetticamente solo ai nuovi costi software sostenuti dopo la data di efficacia, prospetticamente ai costi sostenuti a partire dall'inizio dell'esercizio di adozione, o retrospettivamente a tutti i periodi presentati. Questa flessibilità è importante — un'azienda a metà della riscrittura di una piattaforma importante quando la regola entra in vigore non deve stornare anni di costi capitalizzati a meno che non scelga l'opzione retrospettiva.
Cosa Dovrebbero Fare Ora le Piccole e Medie Aziende Software
Dicembre 2027 sembra lontano, ma il lavoro preparatorio pratico non è un'attività dell'ultimo trimestre, soprattutto per le aziende con team finanziari snelli senza una funzione contabile tecnica dedicata.
Iniziare a documentare la decisione basata sul giudizio "probabile completamento" in tempo reale, non a posteriori. Il vecchio modello a fasi era meccanico — si poteva ricostruire in quale fase si trovava un progetto mesi dopo dalle date degli sprint. Il nuovo test chiede quando abbiamo smesso di essere tecnicamente incerti, che è una decisione basata sul giudizio che diventa molto più difficile da ricostruire dopo i fatti. Costruisci ora un'abitudine leggera: quando la direzione ingegneristica e la finanza concordano sul fatto che una funzionalità ha superato il suo spike tecnico ed è impegnata per lo sviluppo, registra quella data. Quel registro diventa la tua data di inizio capitalizzazione e il supporto per la revisione.
Separare il lavoro di "esplorazione" dal lavoro di "sviluppo impegnato" nella tua tracciatura del tempo o nei codici di progetto, se non lo fai già. Che si tratti di un flag epic in Jira, di un codice centro di costo separato o semplicemente di un'etichetta taggata nel tuo strumento di tracciamento del tempo, avere una traccia dati pulita per quando una funzionalità è passata da spike/prototipo a sviluppo impegnato renderà l'applicazione del nuovo standard drasticamente meno dolorosa che cercare di ricostruirlo a memoria durante una revisione.
Modellare entrambe le opzioni di transizione prima di sceglierne una. Se la tua azienda ha capitalizzato aggressivamente i costi di sviluppo SaaS secondo il vecchio quadro a fasi, l'applicazione retrospettiva potrebbe produrre una svalutazione una tantum delle attività precedentemente capitalizzate, poiché tali costi vengono riclassificati come se fossero sempre stati spesati. Un approccio prospettico evita quella rideterminazione, ma significa che il tuo conto economico non rifletterà la nuova metodologia fino a quando non inizieranno nuovi progetti dopo l'adozione. Esegui i calcoli con entrambe le opzioni prima di presentarle al tuo comitato di revisione.
Parlare con il tuo revisore il prima possibile, specialmente se sei SaaS. Data l'aspettativa del FASB stesso di una diminuzione della capitalizzazione per lo sviluppo SaaS, è probabile che i revisori esaminino le decisioni di probabile completamento più attentamente di quanto abbiano esaminato le classificazioni di fase secondo la vecchia regola — proprio perché è più soggettiva. Un'azienda che si presenta al suo audit del 2028 con un quadro documentato e contemporaneo per prendere questa decisione avrà una conversazione molto più facile di una che la ricostruisce a posteriori.
Libri Contabili Puliti Rendono le Decisioni Basate sul Giudizio Più Facili da Difendere
Ogni giudizio contabile — e "probabile completamento" è chiaramente un giudizio — è difendibile solo quanto i registri su cui si basa. Se il tuo piano dei conti separa già la spesa in R&S per progetto e le tue scritture contabili sono versionate e verificabili invece di vivere in fogli di calcolo disconnessi, applicare uno standard come l'ASU 2025-06 diventa una questione di etichettare dati esistenti piuttosto che ricostruire la storia da thread di Slack. La contabilità in testo semplice di Beancount.io ti offre questo tipo di registro trasparente e versionato con git per impostazione predefinita — ogni voce tracciabile, ogni modifica revisionabile, senza vincolo al fornitore. Inizia gratuitamente e costruisci libri contabili che reggano sia che la domanda arrivi da un revisore, da un acquirente o dal prossimo aggiornamento del FASB.