ASC 350-40 — el tema de codificació que els cercadors sovint escriuen com a 350/40 — és la norma FASB per al programari d'ús intern: quan el cost de desenvolupament es despesa ara versus es capitalitza com a actiu intangible i s'amortitza més tard. Sota el model heretat de tres etapes (encara el que apliquen la majoria de declarants fins a la data obligatòria d'ASU 2025-06), la resposta encaixa en una taula:
| Etapa | Què passa | Capitalitzar o despesar? |
|---|---|---|
| Projecte preliminar | Requisits, demos de proveïdors, viabilitat, construir-vs-comprar | Despesa tal com es produeixi |
| Desenvolupament d'aplicacions | Codificació, configuració, proves, integració després del compromís de gestió | Capitalitza costos directes de construcció |
| Post-implementació | Formació, manteniment, correccions d'errors després de la posada en funcionament | Despesa (la nova funcionalitat pot reiniciar la capitalització) |
ASU 2025-06 (emès el 18 de setembre de 2025; obligatori per a períodes anuals que comencin després del 15 de desembre de 2027) retira aquestes etiquetes d'etapa per un llindar de probable-a-completar i indica que més costos es despesaran. Les seccions següents cobreixen què inclou ASC 350-40, el detall de les etapes, l'actualització de 2025, la llista de verificació capitalitzar/despesar, i com l'elecció afecta l'EBITDA i el balanç de situació.
Què cobreix ASC 350-40
ASC 350-40 és l'estàndard 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 a clients com a producte principal. Els exemples inclouen:
- Sistemes interns de CRM, ERP, RRHH o comptabilitat
- Eines d'infraestructura al núvol i plataformes DevOps
- Una plataforma SaaS que opereu per a clients (el client hi accedeix com a servei, no com a programari llicenciat que instal·len)
- Canonades de dades internes, quadres de comandament i eines d'anàlisi
- Automatització personalitzada de fluxos de treball o de back-office
Si veneu programari llicenciat que els clients instal·len a les seves pròpies màquines, això cau sota ASC 985-20 (programari per a venda externa), que té regles diferents. La majoria d'empreses SaaS modernes cauen sota ASC 350-40 perquè els clients consumeixen el programari com a servei allotjat.
La pregunta central que respon l'estàndard: quan gasteu diners construint programari, aquest cost s'ha de despesar immediatament o capitalitzar-se com a actiu intangible i amortitzar-se durant períodes futurs?
El Model Antic de Tres Etapes (Pre-ASU 2025-06)
Durant dècades, ASC 350-40 va utilitzar un marc basat en etapes. Sota la guia heretada encara en vigor per a la majoria de declarants fins al 2027, el desenvolupament de programari es divideix en tres fases discretes.
Etapa 1: Etapa de Projecte Preliminar
Aquesta és la fase exploratòria — definir requisits, avaluar tecnologies, obtenir demos de proveïdors i decidir si construir, comprar o passar. Tots els costos en aquesta etapa es despesen tal com es produeixin, similar a les despeses de recerca. El raonament: fins que la gestió es compromet, encara no teniu un actiu probable.
Les activitats aquí inclouen:
- Formulació conceptual i alternatives de disseny
- Demos de proveïdors i avaluacions de tecnologia
- Anàlisis de cost-benefici i estudis de viabilitat
- Selecció final d'un enfocament o proveïdor
Etapa 2: Etapa de Desenvolupament d'Aplicacions
La capitalització comença quan la gestió autoritza el projecte, compromet finançament i la finalització és probable. Aquesta etapa cobreix la construcció real — codificació, proves, configuració, integració i instal·lació.
Els costos capitalitzables en aquesta etapa típicament inclouen:
- Salaris i beneficis per a desenvolupadors, enginyers de QA i gestors de projectes (només el temps directament atribuïble a codificació, proves i configuració del programari)
- Honoraris de consultoria externa per a treball de desenvolupament
- Llicències de programari i eines utilitzades per construir l'aplicació
- Costos directes de materials i serveis consumits en el desenvolupament
- Costos d'interessos (en casos limitats)
La capitalització s'atura quan el programari està substancialment complet i llest per al seu ús previst — generalment quan les proves s'han acabat i el sistema s'ha desplegat a producció, fins i tot si el desplegament és gradual.
Etapa 3: Etapa Post-Implementació
Després de la posada en funcionament, els costos recurrents tornen al tractament de despesa. La formació, el manteniment, les correccions d'errors i el suport rutinari es despesen. L'excepció: les millores que afegeixen nova funcionalitat (no només corregeixen o mantenen la funcionalitat existent) es poden capitalitzar utilitzant els mateixos criteris que l'Etapa 2.
La Gran Actualització de 2025: ASU 2025-06
El 18 de setembre de 2025, el FASB va emetre ASU 2025-06, que modernitza significativament ASC 350-40. L'actualització és obligatòria per a períodes anuals que comencin després del 15 de desembre de 2027, amb adopció anticipada permesa.
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 heretat no s'ajustava a les pràctiques modernes de desenvolupament àgil i iteratiu, on els requisits evolucionen i les "etapes" se superposen o s'executen en paral·lel.
El Nou Llindar Basat en Principis
Sota l'estàndard revisat, capitalitzeu costos de programari només quan ambdues condicions es compleixen:
- Autorització de gestió: La gestió ha autoritzat i compromès finançament per al projecte.
- Llindar de probable-a-completar: És probable que el projecte es completi i que el programari compleixi la seva funció prevista.
Aquesta segona prova fa feina real. El FASB va introduir un concepte anomenat incertesa significativa de desenvolupament per avaluar si la finalització és probable. Heu d'avaluar:
- Si el programari inclou funcions noves o no provades que no s'han validat mitjançant codificació o proves
- Si els requisits de rendiment encara estan indeterminats o subjectes a revisió substancial
Si existeix incertesa significativa, la capitalització s'ha de diferir fins que la incertesa es resolgui. El FASB ha indicat que espera que la nova norma resulti en més costos de programari que es despesin, particularment a empreses SaaS on els requisits iteran contínuament.
Què Significa això a la Pràctica
Per a una startup que construeix alguna cosa genuïnament nova — una plataforma d'agents d'IA, un motor d'automatització novel·la — la nova norma pot empènyer més despesa cap a despeses operatives abans. Per a empreses madures que milloren sistemes ben definits, l'impacte pràctic serà menor. En qualsevol cas, el moviment d'un control mecànic d'etapes a un llindar basat en judici significa que les empreses necessiten documentació més clara de decisions de gestió, viabilitat tècnica i estat del projecte.
Què Podeu i Què No Podeu Capitalitzar: 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 despesa capitalitzable i despesable és similar en esperit. Aquí teniu una llista de verificació pràctica.
Generalment Capitalitzable
- Costos laborals directes per a desenvolupadors, dissenyadors i QA durant la fase de construcció
- Impostos sobre nòmina i beneficis assignats per a aquests empleats
- Honoraris de consultoria externa i contractistes per a treball de desenvolupament
- Costos de programari, eines i infraestructura al núvol directament consumits en el desenvolupament
- Costos per desenvolupar nova funcionalitat després del llançament (millores que expandeixen materialment les capacitats)
- Costos per desenvolupar programari de conversió (el programari que migra dades antigues a les noves), en oposició a l'activitat de conversió de dades en si
Generalment Despesat
- Recerca preliminar, selecció de proveïdors i anàlisi de viabilitat
- Formació d'empleats en el nou sistema
- Neteja de dades, conciliació i migració de registres
- Manteniment rutinari, correccions d'errors i refactorització menor
- Costos de programari incorreguts durant períodes d'incertesa significativa de desenvolupament
- Despeses generals administratives no directament lligades al desenvolupament
- Activitats de màrqueting, suport i èxit del client posteriors al llançament
El Problema del Seguiment del Temps
El repte pràctic més gran és l'assignació del temps d'enginyeria. Un enginyer sènior que treballa 40 hores setmanals és improbable que faci un 100% de treball capitalitzable — també depura producció, fa de mentor a companys, assisteix a standups i revisa pull requests per a sistemes heretats. Sense un mètode de seguiment del temps defensable (etiquetes d'enginyeria per projecte, programari de seguiment del temps o enquestes d'assignació formals), les estimacions de capitalització fallaran l'escrutini d'auditoria.
L'Impacte en els Estats Financers
Capitalitzar versus despesar el mateix dòlar produeix estats financers dràsticament diferents.
Efecte al Compte de Resultats
Un cost capitalitzat no afecta el compte de resultats en el període en què es gasta. En canvi, s'amortitza — típicament en línia recta durant tres a cinc anys per a programari d'ús intern. Així, $1M de despesa d'enginyeria capitalitzada a l'Any 1 podria crear només $200K a $333K de despesa d'amortització cada any, deixant l'ingrés operatiu de l'Any 1 materialment més alt.
Per això l'EBITDA rep un impuls de la capitalització. L'amortització és, per definició, exclosa de l'EBITDA — així que capitalitzar més cost de desenvolupament desplaça dòlars de despesa operativa (que redueix l'EBITDA) a amortització (que no ho fa). Els inversors que escruten mètriques SaaS sovint miren "EBITDA abans de R+D capitalitzada" o càlculs de regla-40 utilitzant R+D en efectiu per veure a través d'aquesta dinàmica.
Efecte al Balanç de Situació
El programari capitalitzat apareix com a 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 el retorn sobre actius (ROA) només si els guanys pugen més ràpid que la base d'actius
- Crea un actiu que s'ha de provar per deteriorament si el projecte s'abandona o el seu valor disminueix
Si un projecte s'abandona a mig desenvolupament, els costos prèviament capitalitzats s'han de cancel·lar — que produeix una pèrdua sobtada, sovint material. Aquesta és una de les raons per les quals el nou ASU 2025-06 emfatitza tan fortament el llindar de probable-a-completar.
Efecte a l'Estat de Fluxos de Caixa
Els costos de desenvolupament capitalitzats es classifiquen típicament com a activitats d'inversió (no operatives), cosa que fa que el flux de caixa operatiu sembli més fort. Els inversors sofisticats ajusten per això quan comparen empreses — però el nombre titular encara es beneficia.
Errors Comuns que Posen en Problemes les Empreses
Els auditors i compradors veuen els mateixos errors una vegada i una altra.
Capitalitzar Costos Pre-Autorització
L'error clàssic és capitalitzar temps d'enginyeria gastat abans que la gestió aprovés formalment el projecte. Sense una autorització documentada i un compromís de finançament, aquests costos s'haurien d'haver despesat. Assegureu-vos de tenir actes de reunions, aprovacions del consell o signats escrits que estableixin quan la gestió es va comprometre.
Sense Documentació a Nivell de Projecte
Si un regulador o auditor pregunta "mostreu-me els projectes que heu capitalitzat", i només podeu apuntar a despesa general d'enginyeria, perdreu. Necessiteu registres projecte per projecte: abast, data d'autorització, pressupost, estat i temps carregat.
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 rarament sobreviuen a una auditoria.
Continuar Capitalitzant Després del Llançament
El moment en què el programari està llest per al seu ús previst, la capitalització s'atura. Correccions d'errors, ajustament de rendiment i millores menors després d'aquest punt són despeses operatives. Noves funcions separades i amb abast propi poden començar un nou període de capitalització — però el treball rutinari posterior al llançament no pot.
Oblidar la Prova de Deteriorament
El programari capitalitzat és un actiu, i els actius s'han de deteriorar si el seu valor cau. Si emmagatzemeu un producte, deixeu de banda una funció o reescriviu fonamentalment el sistema, heu de reassessar i probablement cancel·lar el saldo anterior.
Com Configurar un Procés Defensable
Si decidiu que la capitalització és adequada per a la vostra empresa, el procés importa tant com la política.
-
Escriviu una política de capitalització de programari. Definiu quins projectes qualifiquen, el vostre procés d'autorització, la vostra estimació de vida útil i com assignareu el temps. Obteniu l'aprovació del vostre CFO o comitè d'auditoria.
-
Feu el seguiment del temps d'enginyeria a nivell de projecte. Aquest és l'input fonamental. Tant si utilitzeu etiquetes de Jira, etiquetes personalitzades en un gestor de projectes o fulls de temps formals, necessiteu defensar "l'enginyer X va dedicar el Y% del seu temps a treball capitalitzable al projecte Z".
-
Documenteu l'aprovació de la gestió. Cada projecte capitalitzable necessita evidència d'autorització — aprovació escrita datada, actes de reunió del consell o una carta de projecte signada pel lideratge.
-
Reavaleu la incertesa significativa regularment. Sota la nova norma, necessiteu monitorar si les funcions encara són noves o no provades i si els requisits s'estabilitzen. Revisions trimestrals amb el lideratge d'enginyeria són raonables.
-
Construïu calendaris d'amortització per projecte. Cada projecte capitalitzat comença a amortitzar-se quan està llest per a l'ús, i necessiteu fer el seguiment de la base de costos, l'amortització acumulada i la vida restant d'aquest actiu.
-
Proveu el deteriorament quan els projectes canviïn. Cada vegada que abandoneu, reescriviu materialment o deixeu de banda treball capitalitzat, feu una anàlisi de deteriorament i comptabilitzeu les cancel·lacions necessàries.
Per Què Això Importa per a la Comptabilitat
La capitalització de programari és una d'aquestes àrees on la disciplina comptable del primer dia dóna fruits anys després. Els inversors durant una ronda de Sèrie B estiraran el balanç de comprovació; els compradors en un procés de venda rastrejaran les transaccions fins als assentaments de diari; l'IRS pot comparar el vostre tractament GAAP amb el vostre tractament fiscal de 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 lligar els càrrecs de temps d'enginyeria a projectes específics, o no mantenen calendaris d'amortització nets, cada cicle d'auditoria i diligència deguda esdevé dolorós.
La solució és simple en concepte: mantenir una estructura de comptes neta, fer el seguiment del temps a nivell de projecte i documentar les decisions darrere de cada entrada de capitalització. Fer-ho des del principi evita neteges costoses més tard.
Mantingueu la Vostra Comptabilitat de Programari Llesta per a l'Auditoria
Tant si esteu capitalitzant la vostra primera plataforma interna com si executeu calendaris d'amortització a través de dotzenes de projectes, els registres financers nets són la base. Beancount.io proporciona comptabilitat en text pla que us dóna llibres transparents i versionats — cada entrada traçable, cada compte auditable, cada informe reproduïble. Per a empreses de programari que fan el seguiment del desenvolupament capitalitzat a través de múltiples projectes, tenir llibres que es llegeixen com a codi és un avantatge seriós. Comenceu gratuïtament i vegeu per què desenvolupadors i professionals de finances estan canviant a la comptabilitat en text pla.
