La mancata adozione di questa azione iniziale potrebbe rendere difficile separare correttamente i costi tra quelli che dovrebbero essere capitalizzati e quelli che dovrebbero essere spesi. Ciò potrebbe portare a errori nell’applicazione del GAAP e errori nell’ammontare del rapporto delle entità di reddito o perdita netta., Questo articolo è progettato per aiutare i lettori a rispondere a questa domanda: quali costi del software dovrebbero essere capitalizzati e quali costi dovrebbero essere spesi quando un’entità costruisce software per uso esterno utilizzando un ambiente di sviluppo agile?
La tendenza verso lo sviluppo agile
Il metodo di sviluppo software noto come agile è diventato popolare nel settore del software negli ultimi anni., Poiché l’approccio agile (vedere il grafico “Approccio agile”) è ampiamente percepito come più veloce e più reattivo ai requisiti in rapida evoluzione, molte aziende ora lo utilizzano come alternativa preferita al tradizionale approccio di sviluppo a cascata.
L’approccio di sviluppo a cascata convenzionale prevede l’organizzazione di un progetto in una serie di fasi tradizionali, come la concezione, l’avvio, l’analisi, la progettazione, la costruzione, il collaudo, la produzione e l’implementazione e la manutenzione., Queste fasi sono contrassegnate da attività, che la guida utilizza come quadro per concludere quando si raggiunge la fattibilità tecnologica e i costi del progetto di sviluppo software possono essere capitalizzati.
Sotto un modello agile, d’altra parte, un progetto è organizzato in moduli separati, e il lavoro di sviluppo e test su questi moduli è fatto in brevi sprint., Identificare quando si verificano le attività tradizionali dell’approccio a cascata richiede un’analisi significativa e un giudizio nello sviluppo agile, che può rendere più difficile applicare la guida GAAP per capitalizzare le spese.
In definitiva, entrambi i modelli agile e waterfall possono produrre un progetto di successo; tuttavia, determinare il punto nel processo di sviluppo del software per iniziare e terminare la capitalizzazione dei costi può essere più impegnativo con il modello agile.,
2 set di regole di capitalizzazione del software
Come punto di partenza per capitalizzare in modo appropriato i costi di sviluppo del software, è importante determinare la guida corretta. Secondo U. S. GAAP, due potenziali serie di regole principali possono applicarsi per determinare se i costi di sviluppo del software devono essere capitalizzati o spesi.
Un insieme di regole (FASB Accounting Standards Codification (ASC) Topic 985, Software) è progettato per i costi del software che l’entità intende vendere o affittare., Queste regole, comunemente indicate come le regole di capitalizzazione del software per il software per uso esterno, sono l’obiettivo principale di questo articolo. L’altro insieme di regole (ASC Topic 350, Intangibili-Goodwill e altro) disciplina il software che l’entità non intende vendere o affittare. Queste regole sono comunemente indicate come le regole di capitalizzazione del software per il software di uso interno.
È importante notare che la soglia per la capitalizzazione è inferiore per il software per uso interno., Secondo le regole del software per uso interno, i costi di sviluppo possono generalmente essere capitalizzati dopo la fine della fase preliminare del progetto. La soglia per i costi di sviluppo del software per la vendita esterna o la licenza — il focus di questo articolo-è più rigorosa, il che significa che è necessaria una maggiore analisi per determinare quali costi di sviluppo dovrebbero essere capitalizzati.
Dove GAAP e agile non si allineano
Sotto l’argomento 985, il problema critico nel determinare se i costi di sviluppo del software per uso esterno debbano essere capitalizzati ruota attorno al termine “fattibilità tecnologica.,”Tutti i costi di sviluppo del software sostenuti prima del punto in cui il progetto ha dimostrato la fattibilità tecnologica dovrebbero essere spesi man mano che vengono sostenuti.
Una volta stabilita la fattibilità tecnologica, la maggior parte (ma non tutti) i costi di sviluppo possono essere capitalizzati. Infine, una volta che lo sviluppo è completo e il software è reso disponibile per il rilascio ai clienti, la capitalizzazione non è più appropriata perché eventuali costi rimanenti sono considerati manutenzione e supporto in corso. Questi costi devono sempre essere spesi come sono sostenuti.,
La definizione di “fattibilità tecnologica” è quindi il fattore critico per determinare quando un’azienda dovrebbe iniziare a capitalizzare i suoi costi di sviluppo. L’argomento 985 afferma: “la fattibilità tecnologica di un prodotto software per computer viene stabilita quando l’entità ha completato tutte le attività di pianificazione, progettazione, codifica e test necessarie per stabilire che il prodotto può essere prodotto per soddisfare le sue specifiche di progettazione, incluse funzioni, caratteristiche e requisiti di prestazioni tecniche.,”È anche importante notare che i costi di sviluppo del software sono soggetti a queste regole indipendentemente dal fatto che i costi siano stati generati internamente (come il tempo dei dipendenti) o esternamente (come le commissioni dei fornitori).
Nei progetti di sviluppo software convenzionali con fasi consecutive ben definite, la fattibilità tecnologica viene generalmente dimostrata attraverso una progettazione dettagliata del programma o, quando una progettazione dettagliata del programma è assente, un modello funzionante pronto per il test del cliente. Queste sono pietre miliari familiari per i progetti che utilizzano l’approccio a cascata.,
In un ambiente di progetto agile, tuttavia, singole funzioni e funzionalità vengono sviluppate separatamente in una serie di sprint. Ogni sprint o modulo è previsto, pianificato, finanziato, sviluppato e testato individualmente per essere incorporato nel progetto complessivo quando è pronto.
In un tale ambiente, progetti di programmi completi o modelli di lavoro spesso sono poco pratici o irrilevanti., Le aziende che utilizzano un approccio agile per sviluppare software potrebbero concludere in modo inappropriato che la fattibilità tecnologica non è stata soddisfatta in modo significativo prima che il miglioramento del software sia disponibile per i clienti, con il risultato che i costi vengono spesi come sostenuti piuttosto che essere capitalizzati. Se i costi significativi maturano tra quando la fattibilità tecnologica è stata effettivamente raggiunta e quando il software è disponibile per i clienti, la contabilità risultante potrebbe essere incoerente con GAAP.,
Applicazione di GAAP in un ambiente agile
Sebbene le attuali linee guida GAAP per il software per uso esterno non siano adattate all’ambiente agile, ciò non significa che i costi di sviluppo agile non possano essere capitalizzati affatto. Ci sono, dopo tutto, diversi livelli di agilità. Mentre un progetto agile puro potrebbe iniziare con solo un’idea e relativamente poco lavoro di progettazione, alcuni progetti agili hanno progetti di programma dettagliati con storyboard approfonditi, studi di accettazione del mercato e altri documenti di lavoro di progettazione messi insieme prima dell’inizio dello sviluppo effettivo., Tali documenti potrebbero essere utilizzati per valutare la fattibilità tecnologica.
Il punto critico da ricordare è che per valutare i costi che dovrebbero essere capitalizzati, ci deve essere una pianificazione del progetto sufficiente per dimostrare che i criteri per una “progettazione dettagliata del programma” sono stati soddisfatti. Il rischio è che i team di progetto non facciano abbastanza pianificazione front-end o conservino documentazione adeguata per dimostrare di aver raggiunto questa soglia., È probabile che la dimostrazione della fattibilità tecnologica richieda al team di progetto di fare più pianificazione e compilare più documentazione di quella tipica nella maggior parte dei progetti agili.
Altre considerazioni importanti nel determinare la fattibilità tecnologica riguardano le caratteristiche di sviluppo ad alto rischio. Ad esempio, il progetto è una piattaforma software completamente nuova o è un miglioramento o una ri-creazione di qualcosa che è stato fatto prima? L’azienda sta sviluppando software da zero o sta mettendo insieme vari componenti software già esistenti?, Le caratteristiche di sviluppo ad alto rischio possono richiedere un’ulteriore analisi del raggiungimento della fattibilità tecnologica e, in alcuni casi, la spesa dei costi precedentemente capitalizzati.
I miglioramenti del prodotto che non sono considerati attività di manutenzione a volte possono soddisfare più facilmente la soglia di fattibilità tecnologica perché gli sviluppatori aggiungono funzioni a un prodotto già di successo. I fattori decisivi in tali casi includono il tipo di software, il livello di modifica richiesto e il livello di lavoro di progettazione completato prima dell’inizio dello sviluppo.,
Anche quando viene stabilita la fattibilità tecnologica, non tutti i costi di sviluppo agile possono essere capitalizzati. Nella maggior parte dei casi, solo alcuni dei costi in ogni sprint possono essere capitalizzati. I costi che non dovrebbero essere capitalizzati includono l’analisi iniziale, l’acquisizione di conoscenze, la pianificazione iniziale del progetto, la prototipazione e il lavoro di progettazione comparabile che deve essere fatto per ottenere una comprensione delle caratteristiche e della fattibilità desiderate del prodotto.
Ma grandi porzioni dei costi sostenuti per sviluppare e testare tali caratteristiche spesso dovrebbero essere capitalizzati se si raggiunge la fattibilità tecnologica., Questi costi includono la codifica effettiva, test e costi di manodopera associati.
Tenere presente, tuttavia, che eventuali costi relativi alla manutenzione o alla correzione degli errori sostenuti durante lo sprint potrebbero dover essere spesi piuttosto che capitalizzati, poiché molte attività durante lo sprint potrebbero non essere di codifica e test, ma potrebbero essere attività come la risoluzione dei problemi e la scoperta. Inoltre, la capitalizzazione termina una volta che il progetto è completo e il software è pronto per l’uso.,
La distinzione tra i costi che possono essere capitalizzati e quelli che non possono essere capitalizzati può complicare in qualche modo le fasi di contabilità, reporting e documentazione del progetto all’interno di ogni sprint. Ma il lavoro amministrativo aggiuntivo non deve essere oneroso. Nella maggior parte dei casi le varie attività e i risultati finali all’interno di ogni sprint possono essere segmentati in ampie categorie, in modo che tutti i costi associati a tale attività possano essere spesi o capitalizzati.,
Preparazione e comunicazione: I passaggi critici
Decidere quali costi di sviluppo software per uso esterno possono essere capitalizzati in un ambiente di progetto agile comporta una certa quantità di giudizio. In molti casi, i fatti e le circostanze specifiche che circondano il tipo di software in fase di sviluppo guideranno il trattamento dei costi. Un’attenta pianificazione può aiutare nell’analisi di quali costi capitalizzare rispetto alle spese.,
Per questo motivo, di solito è consigliabile discutere il trattamento contabile con il team di gestione del progetto e gli esperti in materia prima di iniziare qualsiasi grande progetto di sviluppo. È anche importante capire fin dall’inizio di un progetto il livello di supporto e documentazione che sarà necessario per consentire le decisioni appropriate in materia di capitalizzazione dei costi. Inoltre, è necessaria una chiara comprensione del livello di documentazione che dovrà essere mantenuto per i revisori per valutare e affermare le decisioni di capitalizzazione e di spesa.,
Ad esempio, il team di progetto dovrebbe documentare accuratamente il ruolo di ogni persona nel progetto in modo che la contabilità possa distinguere tra quegli individui il cui tempo e attività potrebbero potenzialmente essere soggetti a capitalizzazione e quelli le cui attività non rientrerebbero mai in questa categoria. È inoltre importante mantenere controlli interni aggiuntivi come revisioni mensili delle attività, importi capitalizzati e spesi e modelli di comunicazione che i project manager possono compilare per verificare che il tempo dei dipendenti sia codificato correttamente.,
Sebbene si siano verificate alcune discussioni di settore sull’aggiornamento degli standard pertinenti per renderli più applicabili al framework agile, tali aggiornamenti in genere comportano diversi anni di pianificazione, discussione, proposte e feedback del settore. Ciò significa che, per il prossimo futuro, le aziende che utilizzano un modello agile per sviluppare software per la vendita o le licenze esterne dovranno continuare a coordinarsi strettamente con i loro team contabili per applicare le linee guida GAAP esistenti e capitalizzare i costi di sviluppo in modo appropriato.
Lascia un commento