Pregunteu a un cap d'enginyeria de programari quan va "començar" un projecte i us respondrà amb un número d'sprint. Pregunteu el mateix al seu controller i, segons les normes comptables que han regit el programari d'ús intern des de 1998, la resposta havia de sorgir d'una llista de verificació rígida de tres etapes que dona per fet que ningú escriu codi fins que els requisits estan tancats. Qualsevol que hagi llançat programari durant l'última dècada sap que ja no funciona així — i, el setembre de 2025, el FASB finalment també ho va admetre.
Accounting Standards Update (ASU) 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software, elimina completament l'antiga prova basada en etapes i la substitueix per una única pregunta basada en el judici professional: és probable que aquest programari realment s'acabi i faci allò que se suposa que ha de fer? Per a qualsevol empresa que desenvolupi programari internament — i especialment per als equips àgils per als quals l'antiga norma mai va ser pensada — això canvia el moment en què els costos de desenvolupament passen del compte de pèrdues i guanys al balanç, i en quina mesura.
El problema: un reglament de 1998 per al desenvolupament en cascada
La norma que substitueix l'ASU 2025-06, l'ASC 350-40 (originalment la SOP 98-1), es va redactar quan "desenvolupament de programari" significava un procés lineal en cascada. Dividia tot projecte de programari d'ús intern en tres etapes seqüencials:
- Etapa preliminar del projecte — formulació conceptual, avaluació d'alternatives, selecció de proveïdors. Tot el que passa aquí es registra com a despesa a mesura que s'incorre.
- Etapa de desenvolupament de l'aplicació — codificació, configuració i proves reals. Els costos d'aquesta etapa es capitalitzen.
- Etapa posterior a la implementació — formació i manteniment. Es torna a registrar com a despesa.
Aquest marc funciona bé si un equip dedica tres mesos a redactar un document de requisits, obté l'aprovació i després comença a construir. Es desmunta en el moment en què un equip treballa amb sprints de dues setmanes, publica versions incrementals i revisa l'abast a cada retrospectiva. En un entorn àgil, "preliminar" i "desenvolupament de l'aplicació" no són fases seqüencials — s'entrellacen, de vegades dins del mateix sprint. Les empreses i els seus auditors han passat anys discutint a quina etapa pertany realment un sprint concret de dues setmanes, i la resposta honesta sovint era "una mica de totes dues, estem endevinant". La pròpia consulta del FASB va constatar que les parts interessades assenyalaven de manera constant que aquest era un dels aspectes més dolorosos operativament d'aplicar de manera coherent dins del GAAP.
La solució: una única prova, no tres etapes
L'ASU 2025-06 elimina qualsevol referència a les antigues etapes del projecte. En el seu lloc, estableix un únic llindar de reconeixement de "probable de completar". Segons la nova norma, una empresa capitalitza els costos de programari d'ús intern un cop es compleixen alhora totes dues condicions següents:
- La direcció ha autoritzat i s'ha compromès a finançar el projecte. No és un concepte nou — també existia a la norma antiga — però ara té més pes en ser una de només dues condicions determinants, en lloc de quedar amagat dins de l'anàlisi per etapes.
- És probable que el projecte es completi i que el programari s'utilitzi per exercir la funció prevista. Aquesta és la peça genuïnament nova, i aquí és on resideix el judici professional.
Aquest segon criteri exigeix avaluar si encara existeix una incertesa significativa en el desenvolupament. El FASB assenyala dues fonts principals d'aquesta incertesa:
- Tecnologia no provada o funcionalitat nova la viabilitat de la qual encara no s'ha demostrat mitjançant codificació i proves reals — no un document de disseny, ni una especificació, sinó una prova funcional.
- Requisits de rendiment indefinits o encara canviants — la norma els defineix com "allò que una entitat necessita que faci el programari, p. ex., funcions o característiques." Si l'equip encara està debatent de manera substancial què ha de fer el producte, aquesta incertesa no s'ha resolt.
A la pràctica, això significa que el moment de la capitalització ara segueix l'evidència de viabilitat, no la fase del calendari. Un equip que dedica dos sprints a explorar (spike) una funcionalitat tècnicament nova abans de comprometre's a construir-la de debò registraria aquests sprints d'exploració com a despesa — la incertesa sobre si fins i tot es pot construir encara no s'ha resolt. Un cop l'exploració ho demostra i la direcció compromet pressupost per a la construcció completa, es compleix el llindar de "probable de completar" i els costos de desenvolupament posteriors es capitalitzen, malgrat les cerimònies àgils.
Per què el FASB diu que la capitalització no canviarà gaire — excepte per al SaaS
La pròpia expectativa del FASB és que, per a la majoria del programari d'ús intern local o basat en llicències, les esmenes no canviaran dràsticament els resultats de capitalització — les empreses ja capitalitzaven un cop començava la codificació real, i la nova prova arriba aproximadament al mateix punt, només sense l'exercici d'etiquetatge per etapes.
El programari desenvolupat per oferir-se mitjançant un acord SaaS o al núvol és una història diferent. El FASB espera explícitament que la capitalització disminueixi per a aquests projectes. La raó: els productes SaaS, per la seva pròpia naturalesa, es construeixen i es reconstrueixen contínuament, amb una incertesa tècnica i de producte significativa que persisteix fins ben endins del calendari de desenvolupament — de vegades fins gairebé el moment en què una funcionalitat s'acosta al llançament. Segons la prova de "probable de completar", aquesta incertesa persistent implica que molts costos de desenvolupament SaaS no superaran el llindar de capitalització fins molt més tard en la construcció del que hauria suggerit l'antic model per etapes. L'efecte net: una part més gran de la nòmina d'enginyeria d'un producte SaaS es registra com a despesa de R+D del període actual en lloc de com a actiu amortitzable a diversos anys. Es tracta d'un canvi significatiu per a l'EBITDA declarat i la base d'actius de qualsevol empresa SaaS, fins i tot abans que canviï una sola línia del codi real.
Un exemple concret: dos equips, dos resultats
Suposem que una empresa SaaS de 40 persones decideix construir un mòdul de previsió amb IA per al seu producte. Vegem com les normes antigues i noves tractarien de manera diferent la mateixa construcció de vuit mesos.
Amb l'antic model per etapes, l'equip financer intentaria traçar una línia: les primeres sis setmanes de recopilació de requisits i avaluació de proveïdors eren "preliminars" (despesa), i tot el que passava després de la reunió de llançament era "desenvolupament de l'aplicació" (capitalitzat) — encara que l'equip d'enginyeria dediqués els dos mesos següents a fer proves exploratòries (spikes) per determinar si l'enfocament de previsió triat podia assolir una precisió acceptable amb volums de dades de producció. Segons la lletra de la norma antiga, un cop canviava l'"etapa", aquests sprints d'exploració sovint també es capitalitzaven, perquè tècnicament passaven després de la reunió de llançament.
Amb l'ASU 2025-06, l'equip financer es pregunta, en canvi: quan es va tornar probable que aquesta funcionalitat es completés i funcionés tal com estava previst? Si l'enfocament de precisió encara no estava provat durant els dos primers mesos — l'equip provava tres enfocaments de modelització diferents i no sabia si algun assoliria el llindar — tot aquest període d'exploració es registra com a despesa, independentment de a quina "etapa" del calendari pertanyia. La capitalització comença només un cop l'equip tria un enfocament validat i la direcció compromet pressupost per construir-lo, cosa que en aquest exemple podria ser al tercer mes, no al segon. El resultat: un actiu capitalitzat més petit, una despesa de R+D del període actual més gran i — el més important — una xifra que el CFO pot defensar realment en una auditoria, perquè està vinculada a un punt de decisió específic i documentat en lloc d'una etiqueta d'etapa aplicada a posteriori.
Aquest és exactament el canvi que el FASB espera en tot el sector SaaS: menys "ho vam anomenar desenvolupament de l'aplicació perquè és el que va venir després de la trucada de llançament" i més "podem assenyalar l'sprint on es va eliminar el risc tècnic."
Dates d'entrada en vigor i transició
L'ASU 2025-06 entra en vigor per a totes les entitats — públiques i privades — per als períodes anuals d'informació que comencin després del 15 de desembre de 2027, i per als períodes intermedis dins d'aquests anys. S'admet l'adopció anticipada per a qualsevol entitat, en qualsevol període intermedi o anual, un cop s'hagi emès la norma.
Les entitats poden aplicar les esmenes fent servir un de tres enfocaments de transició: de manera prospectiva només als nous costos de programari incorreguts després de la data d'entrada en vigor, de manera prospectiva als costos incorreguts en o després de l'inici de l'any d'adopció, o de manera retrospectiva a tots els períodes presentats. Aquesta flexibilitat és important — una empresa que estigui a mig camí de reescriure una plataforma important quan entri en vigor la norma no ha de desfer anys d'historial de costos capitalitzats tret que triï l'opció retrospectiva.
Què haurien de fer ara les empreses de programari petites i mitjanes
Desembre de 2027 sona llunyà, però la feina pràctica de preparació no és una tasca per a l'últim trimestre, sobretot per a les empreses que operen amb equips financers reduïts i sense una funció dedicada de comptabilitat tècnica.
Comenceu a documentar el judici de "probable de completar" en temps real, no a posteriori. L'antic model per etapes era mecànic — es podia reconstruir en quina etapa estava un projecte mesos després a partir de les dates dels sprints. La nova prova pregunta quan vam deixar de tenir incertesa tècnica, un judici que és molt més difícil de reconstruir a posteriori. Creeu ara un hàbit senzill: quan el lideratge d'enginyeria i finances coincideixin que una funcionalitat ha superat la seva exploració tècnica i s'ha compromès per construir-se, registreu aquesta data. Aquest registre es convertirà en la vostra data d'inici de capitalització i en el vostre suport d'auditoria.
Separeu la feina d'"exploració" de la feina de "construcció compromesa" en el vostre seguiment del temps o en els codis de projecte, si encara no ho feu. Ja sigui mitjançant un indicador d'èpica a Jira, un codi de centre de cost separat, o simplement una etiqueta a la vostra eina de seguiment del temps, tenir un rastre de dades net sobre quan una funcionalitat va passar d'exploració/prototip a desenvolupament compromès farà que aplicar la nova norma sigui dràsticament menys dolorós que intentar reconstruir-ho de memòria durant una auditoria.
Modelitzeu les dues opcions de transició abans de triar-ne una. Si la vostra empresa ha capitalitzat de manera agressiva els costos de desenvolupament SaaS sota l'antic marc per etapes, l'aplicació retrospectiva podria produir una amortització única d'actius prèviament capitalitzats a mesura que aquests costos es reclassifiquen com si sempre s'haguessin registrat com a despesa. Un enfocament prospectiu evita aquesta reformulació, però significa que el vostre compte de pèrdues i guanys no reflectirà la nova metodologia fins que comencin nous projectes després de l'adopció. Feu els càlculs amb totes dues abans que el vostre comitè d'auditoria hagi de fer-ho.
Parleu amb el vostre auditor amb antelació, especialment si sou una empresa SaaS. Atesa la pròpia expectativa del FASB d'una disminució de la capitalització per al desenvolupament SaaS, és probable que els auditors escrutinin els judicis de "probable de completar" més de prop del que escrutinaven les classificacions per etapes sota la norma antiga — precisament perquè és més subjectiu. Una empresa que arribi a la seva auditoria de 2028 amb un marc documentat i contemporani per prendre aquesta decisió tindrà una conversa molt més fàcil que una que l'hagi de reconstruir a posteriori.
Uns llibres nets fan que els judicis siguin més fàcils de defensar
Tot judici comptable — i "probable de completar" és clarament un judici — només és tan defensable com els registres que el sustenten. Si el vostre pla de comptes ja separa la despesa de R+D per projecte, i els assentaments del vostre llibre major estan versionats i són auditables en lloc de viure en fulls de càlcul desconnectats, aplicar una norma com l'ASU 2025-06 esdevé una qüestió d'etiquetar dades existents en lloc de reconstruir la història a partir de fils de Slack. La comptabilitat en text pla de Beancount.io us ofereix, per defecte, aquest tipus de llibre major transparent i versionat amb git — cada assentament és traçable, cada canvi és revisable, sense dependència de proveïdor. Comenceu gratis i construïu uns llibres que aguantin, tant si la pregunta ve d'un auditor, d'un adquirent, o de la propera actualització del FASB.