Capitalització de Programari sota la normativa ASC 350-40: Una guia pràctica per a la decisió de capitalitzar vs. carregar a despeses

Una enquesta de Gartner de 2024 va revelar que el 63% dels fundadors de SaaS en etapes inicials classifiquen incorrectament els costos de desenvolupament de programari. Aquest error els costa en dos fronts: els inversors apliquen descomptes a les seves finances quan les classificacions semblen poc rigoroses, i els auditors assenyalen el problema durant la diligència deguda, cosa que pot retardar les rondes de finançament o els processos de venda durant mesos.

La capitalització de programari no és només una qüestió tècnica de comptabilitat. Afecta directament l'EBITDA, el balanç de situació i la imatge que projecta la vostra empresa davant prestadors, inversors i compradors. Les regles sota l'ASC 350-40 —i una actualització important de 2025— determinen quins costos impacten immediatament en el compte de resultats i quins es reparteixen al llarg dels anys.

Aquesta guia repassa el que exigeix la norma, la recent reforma de l'ASU 2025-06, els costos que podeu capitalitzar, els que no, i les conseqüències en els estats financers de fer-ho correctament.

Què cobreix l'ASC 350-40

L'ASC 350-40 és la norma FASB per al programari d'ús intern —programari que la vostra empresa construeix o compra per a les seves pròpies operacions en lloc de vendre'l als clients com a producte principal. Alguns exemples inclouen:

• Sistemes interns de CRM, ERP, RRHH o comptabilitat
• Eines d'infraestructura en el núvol i plataformes DevOps
• Una plataforma SaaS que opereu per als clients (el client hi accedeix com a servei, no com a programari amb llicència que instal·len)
• Conduccions de dades internes, quadres de comandament i eines d'anàlisi
• Automatització personalitzada de fluxos de treball o de suport administratiu (back-office)

Si veneu programari amb llicència que els clients instal·len a les seves pròpies màquines, això recau sota l'ASC 985-20 (programari per a la venda externa), que té regles diferents. La majoria d'empreses SaaS modernes entren dins de l'ASC 350-40 perquè els clients consumeixen el programari com un servei allotjat.

La pregunta central que respon la norma és: quan gasteu diners construint programari, aquest cost s'hauria de comptabilitzar immediatament com a despesa o capitalitzar-se com un actiu intangible i amortitzar-se en períodes futurs?

L'antic model de tres etapes (abans de l'ASU 2025-06)

Durant dècades, l'ASC 350-40 va utilitzar un marc basat en etapes. Sota la guia llegada que encara està en vigor per a la majoria de declarants fins al 2027, el desenvolupament de programari es divideix en tres fases discretes.

Etapa 1: Etapa preliminar del projecte

Aquesta és la fase exploratòria: definició de requisits, avaluació de tecnologies, obtenció de demostracions de proveïdors i decisió sobre si construir, comprar o descartar. Tots els costos en aquesta etapa es comptabilitzen com a despeses a mesura que es produeixen, de manera similar a les despeses de recerca. El motiu: fins que la direcció no es compromet, encara no teniu un actiu probable.

Les activitats aquí inclouen:

• Formulació conceptual i alternatives de disseny
• Demostracions de proveïdors i avaluacions tecnològiques
• Anàlisis de cost-benefici i estudis de viabilitat
• Selecció final d'un enfocament o d'un proveïdor

Etapa 2: Etapa de desenvolupament de l'aplicació

La capitalització comença quan la direcció autoritza el projecte, compromet el finançament i la finalització és probable. Aquesta etapa cobreix la construcció real: programació, proves, configuració, integració i instal·lació.

Els costos capitalitzables en aquesta etapa solen incloure:

• Salaris i beneficis per a desenvolupadors, enginyers de QA i gestors de projectes (només el temps directament atribuïble a la programació, proves i configuració del programari)
• Honoraris de consultoria externa per a treballs de desenvolupament
• Llicències de programari i eines utilitzades per construir l'aplicació
• Costos directes de materials i serveis consumits en el desenvolupament
• Costos per interessos (en casos limitats)

La capitalització s'atura quan el programari està substancialment complet i llest per al seu ús previst —generalment quan s'han acabat les proves i el sistema s'ha desplegat en producció, encara que el llançament sigui gradual.

Etapa 3: Etapa de post-implementació

Després de la posada en marxa, els costos continus tornen a tractar-se com a despeses. La formació, el manteniment, la correcció d'errors i el suport rutinari es comptabilitzen com a despeses. L'excepció: les millores que afegeixen noves funcionalitats (no només arreglar o mantenir la funcionalitat existent) es poden capitalitzar utilitzant els mateixos criteris que a l'Etapa 2.

La gran actualització de 2025: ASU 2025-06

El 18 de setembre de 2025, el FASB va emetre l'ASU 2025-06, que modernitza significativament l'ASC 350-40. L'actualització és obligatòria per als períodes anuals que comencin després del 15 de desembre de 2027, tot i que se'n permet l'adopció anticipada.

El canvi és estructural: el model de tres etapes ha desaparegut. El FASB va eliminar explícitament totes les referències a les etapes del projecte perquè el marc llegat no s'ajustava a les pràctiques de desenvolupament àgils i iteratives modernes, on els requisits evolucionen i les "etapes" se superposen o s'executen en paral·lel.

El nou llindar basat en principis

Sota la norma revisada, només es capitalitzen els costos de programari quan es compleixen aquestes dues condicions:

1. Autorització de la direcció: La direcció ha autoritzat i s'ha compromès a finançar el projecte.
2. Llindar de probabilitat de finalització: És probable que el projecte es completi i que el programari realitzi la funció prevista.

Aquesta segona prova és determinant. El FASB va introduir un concepte anomenat incerteza significativa de desenvolupament per avaluar si la finalització és probable. Heu d'avaluar:

• Si el programari inclou característiques noves o no provades que no s'han validat mitjançant la programació o les proves
• Si els requisits de rendiment encara estan per determinar o estan subjectes a una revisió substancial

Si existeix una incerteza significativa, la capitalització s'ha de ajornar fins que la incerteza es resolgui. El FASB ha indicat que espera que la nova regla faci que es comptabilitzin més costos de programari com a despeses, especialment en empreses SaaS on els requisits iteren contínuament.

Què significa això a la pràctica

Per a una startup que construeix quelcom genuïnament nou —una plataforma d'agents d'IA, un motor d'automatització innovador— la nova norma pot empènyer més despesa cap a despeses d'explotació abans d'hora. Per a empreses madures que milloren sistemes ben definits, l'impacte pràctic serà menor. En qualsevol cas, el pas d'una verificació d'etapa mecànica a un llindar basat en el judici significa que les empreses necessiten una documentació més clara de les decisions de gestió, la viabilitat tècnica i l'estat del projecte.

Què es pot capitalitzar i què no: una llista de verificació pràctica

Tant si apliqueu el model d'etapes heretat com la nova prova basada en principis, la línia entre la despesa capitalitzable i la imputable com a despesa és similar en essència. Aquí teniu una llista de verificació de treball.

Generalment capitalitzable

• Costos directes de mà d'obra per a desenvolupadors, dissenyadors i QA durant la fase de construcció
• Impostos sobre la nòmina i beneficis socials assignats per a aquests empleats
• Honoraris de consultoria externa i contractistes per a treballs de desenvolupament
• Costos de programari, eines i infraestructura al núvol consumits directament en el desenvolupament
• Costos per desenvolupar noves funcionalitats post-llançament (millores que amplien materialment les capacitats)
• Costos per desenvolupar programari de conversió (el programari que migra dades antigues a les noves), a diferència de l'activitat de conversió de dades en si mateixa

Generalment imputat com a despesa

• Recerca preliminar, selecció de proveïdors i anàlisi de viabilitat
• Formació dels empleats en el nou sistema
• Neteja de dades, conciliació i migració de registres
• Manteniment rutinari, correcció d'errors (bug fixes) i refactorització menor
• Costos de programari incorreguts durant períodes d'incertesa significativa en el desenvolupament
• Despeses generals d'administració no vinculades directament al desenvolupament
• Activitats de màrqueting, suport i èxit del client (customer success) post-llançament

El problema del seguiment del temps

El repte pràctic més gran és l'assignació del temps d'enginyeria. És poc probable que un enginyer sènior que dedica 40 hores a la setmana faci un 100% de treball capitalitzable; també està depurant errors en producció, fent mentoria a companys d'equip, assistint a reunions diàries (standups) i revisant sol·licituds d'incorporació de canvis (pull requests) per a sistemes antics. Sense un mètode de seguiment del temps defendible (tiquets d'enginyeria etiquetats per projecte, programari de seguiment del temps o enquestes d'assignació formal), les estimacions de capitalització no superaran l'escrutini d'una auditoria.

L'impacte en els estats financers

Capitalitzar o imputar com a despesa el mateix dòlar produeix estats financers dràsticament diferents.

Efecte en el compte de pèrdues i guanys

Un cost capitalitzat no impacta en el compte de pèrdues i guanys en el període en què s'ha gastat. En canvi, s'amortitza —normalment de forma lineal durant tres a cinc anys per al programari d'ús intern. Així, 1 M€ de despesa d'enginyeria capitalitzada l'any 1 podria crear només entre 200.000 € i 333.000 € de despesa d'amortització cada any, deixant el resultat d'explotació de l'any 1 materialment més alt.

És per això que l'EBITDA rep un impuls de la capitalització. L'amortització, per definició, s'exclou de l'EBITDA; per tant, capitalitzar més costos de desenvolupament desplaça els diners de la despesa d'explotació (que redueix l'EBITDA) a l'amortització (que no ho fa). Els inversors que analitzen les mètriques SaaS sovint miren l'"EBITDA abans de l'R+D capitalitzat" o els càlculs de la regla del 40 utilitzant l'R+D en efectiu per veure a través d'aquesta dinàmica.

Efecte en el balanç de situació

El programari capitalitzat apareix com un actiu intangible a llarg termini, sovint etiquetat com "Costos de desenvolupament de programari capitalitzats" o similar. Això:

• Augmenta els actius totals i el patrimoni net
• Millora la rendibilitat dels actius (ROA) només si els beneficis creixen més ràpid que la base d'actius
• Crea un actiu que s'ha de sotmetre a una prova de deteriorament de valor si el projecte s'abandona o el seu valor disminueix

Si un projecte s'abandona a mig desenvolupament, els costos capitalitzats prèviament s'han de donar de baixa, la qual cosa produeix una pèrdua sobtada i sovint material. Aquesta és una de les raons per les quals la nova ASU 2025-06 posa tant d'èmfasi en el llindar de "probabilitat de finalització".

Efecte en l'estat de fluxos d'efectiu

Els costos de desenvolupament capitalitzats es classifiquen normalment com a activitats d'inversió (no d'explotació), la qual cosa fa que el flux de caixa operatiu sembli més fort. Els inversors sofisticats fan ajustos per això quan comparen empreses, però la xifra principal encara se'n beneficia.

Errors comuns que fiquen les empreses en problemes

Els auditors i els adquiridors veuen els mateixos errors una vegada i una altra.

Capitalitzar costos previs a l'autorització

L'error clàssic és capitalitzar el temps d'enginyeria passat abans que la direcció aprovés formalment el projecte. Sense una autorització documentada i un compromís de finançament, aquests costos s'haurien d'haver imputat com a despesa. Assegureu-vos de tenir actes de reunions, aprovacions de la junta o autoritzacions escrites que estableixin quan es va comprometre la direcció.

Manca de documentació a nivell de projecte

Si un regulador o auditor demana "mostra'm els projectes que has capitalitzat" i només pots assenyalar la despesa general d'enginyeria, perdràs. Necessites registres projecte per projecte: abast, data d'autorització, pressupost, estat i temps imputat.

Tractar tot el temps d'enginyeria com a capitalitzable

Els enginyers sèniors corregeixen errors, revisen codi, assisteixen a reunions i responen a incidents. Res d'això és capitalitzable. Les empreses que simplement multipliquen la nòmina de l'equip d'enginyeria per un percentatge determinat rarament sobreviuen a una auditoria.

Continuar capitalitzant després del llançament

En el moment que el programari està llest per al seu ús previst, la capitalització s'atura. La correcció d'errors, l'optimització del rendiment i les millores menors després d'aquest punt són despeses operatives. Les noves funcionalitats amb un abast independent poden iniciar un nou període de capitalització, però el treball rutinari posterior al llançament no pot fer-ho.

Oblidar les proves de deteriorament

El programari capitalitzat és un actiu, i els actius han de patir un deteriorament si el seu valor cau. Si arxiveu un producte, retireu una funcionalitat o reescriviu fonamentalment el sistema, heu de tornar a avaluar i, probablement, donar de baixa el saldo anterior.

Com establir un procés justificable

Si decidiu que la capitalització és adequada per a la vostra empresa, el procés és tan important com la política.

1. Redacteu una política de capitalització de programari. Definiu quins projectes compleixen els requisits, el vostre procés d'autorització, l'estimació de la vida útil i com assignareu el temps. Obtingueu l'aprovació del vostre CFO o del comitè d'auditoria.

2. Rastregueu el temps d'enginyeria a nivell de projecte. Aquesta és l'entrada fonamental. Tant si feu servir etiquetes de Jira, etiquetes personalitzades en un gestor de projectes o fulls de temps formals, heu de poder defensar que "l'enginyer X va dedicar el Y% del seu temps a treballs capitalitzables en el projecte Z".

3. Documenteu l'aprovació de la direcció. Cada projecte capitalitzable necessita una prova d'autorització: aprovació escrita amb data, actes de la junta o un document de constitució del projecte signat per la direcció.

4. Reavalueu les incerteses significatives regularment. Segons la nova normativa, heu de supervisar si les funcionalitats encara són noves o no estan provades i si els requisits s'estan estabilitzant. Les revisions trimestrals amb el lideratge d'enginyeria són raonables.

5. Creeu quadres d'amortització per projecte. Cada projecte capitalitzat comença a amortitzar-se quan està llest per al seu ús, i heu de fer un seguiment de la base de cost d'aquest actiu, l'amortització acumulada i la vida útil restant.

6. Feu proves de deteriorament quan els projectes canviïn. Cada vegada que abandoneu, reescriviu substancialment o retireu un treball capitalitzat, realitzeu una anàlisi de deteriorament i registreu les pèrdues de valor segons sigui necessari.

Per què això és important per a la comptabilitat

La capitalització de programari és una d'aquelles àrees on la disciplina comptable des del primer dia dóna els seus fruits anys després. Els inversors durant una ronda de Sèrie B revisaran el vostre balanç de comprovació; els adquiridors en un procés de venda rastrejaran les transaccions fins als assentaments comptables; l'IRS pot comparar el vostre tractament segons els PCGA amb el tractament fiscal d'R+D de la Secció 174, que té les seves pròpies regles. Si els vostres llibres no separen els projectes capitalitzats de les despeses operatives, no poden vincular els càrrecs de temps d'enginyeria a projectes específics o no mantenen quadres d'amortització nets, cada cicle d'auditoria i diligència es torna dolorós.

La solució és conceptualment senzilla: mantingueu una estructura de comptes neta, rastregueu el temps a nivell de projecte i documenteu les decisions darrere de cada assentament de capitalització. Fer-ho des del principi evita neteges costoses més endavant.

Mantingueu la vostra comptabilitat de programari a punt per a auditories

Tant si esteu capitalitzant la vostra primera plataforma interna com si gestioneu quadres d'amortització en desenes de projectes, uns registres financers nets són la base. Beancount.io ofereix comptabilitat en text pla que us proporciona llibres transparents i amb control de versions: cada entrada rastrejable, cada compte auditable, cada informe reproduïble. Per a les empreses de programari que fan un seguiment del desenvolupament capitalitzat en múltiples projectes, tenir llibres que es llegeixen com codi és un avantatge seriós. Comenceu de franc i descobriu per què desenvolupadors i professionals de les finances s'estan passant a la comptabilitat en text pla.