Pregúntele a un gerente de ingeniería de software cuándo "comenzó" un proyecto y obtendrá el número de un sprint. Hágale la misma pregunta a su controller y, según las normas contables que han regido el software de uso interno desde 1998, la respuesta debía surgir de una rígida lista de verificación de tres etapas que supone que nadie escribe código hasta que los requisitos están cerrados. Cualquiera que haya lanzado software en la última década sabe que ya no funciona así, y en septiembre de 2025 FASB finalmente lo admitió también.
La Actualización de las Normas Contables (ASU, por sus siglas en inglés) 2025-06, Intangibles—Goodwill and Other—Internal-Use Software (Subtopic 350-40): Targeted Improvements to the Accounting for Internal-Use Software, elimina por completo la antigua prueba basada en etapas y la sustituye por una única pregunta basada en el juicio profesional: ¿es probable que este software realmente se termine y cumpla la función para la que fue concebido? Para cualquier empresa que desarrolle software internamente —y especialmente para los equipos ágiles para los que la norma anterior nunca fue pensada— esto cambia el momento en que los costos de desarrollo pasan del estado de resultados al balance general, y en qué magnitud.
El problema: un reglamento de 1998 para el desarrollo en cascada
La guía que sustituye la ASU 2025-06, la ASC 350-40 (originalmente SOP 98-1), fue redactada cuando "desarrollo de software" significaba un proceso lineal en cascada. Dividía todo proyecto de software de uso interno en tres etapas secuenciales:
- Etapa preliminar del proyecto — formulación conceptual, evaluación de alternativas, selección de proveedores. Todo lo que ocurre aquí se reconoce como gasto en el momento en que se incurre.
- Etapa de desarrollo de la aplicación — programación real, configuración y pruebas. Los costos de esta etapa se capitalizan.
- Etapa posterior a la implementación — capacitación y mantenimiento. Se reconoce nuevamente como gasto.
Ese marco funciona bien si un equipo pasa tres meses redactando un documento de requisitos, obtiene la aprobación y luego comienza a construir. Se desmorona en el momento en que un equipo trabaja en sprints de dos semanas, publica versiones incrementales y revisa el alcance en cada retrospectiva. En un entorno ágil, "preliminar" y "desarrollo de la aplicación" no son fases secuenciales, sino que se entrelazan, a veces dentro del mismo sprint. Las empresas y sus auditores han pasado años discutiendo a qué etapa pertenece realmente un sprint determinado de dos semanas, y la respuesta honesta solía ser "un poco de ambas, estamos adivinando". La propia consulta de FASB con las partes interesadas encontró que estas señalaban de forma constante que este era uno de los aspectos operativamente más dolorosos de aplicar el GAAP de manera consistente.
La solución: una sola prueba, no tres etapas
La ASU 2025-06 elimina toda referencia a las antiguas etapas del proyecto. En su lugar, establece un único umbral de reconocimiento de "finalización probable". Según la nueva guía, una empresa capitaliza los costos de software de uso interno una vez que ambas condiciones siguientes se cumplen simultáneamente:
- La dirección ha autorizado y se ha comprometido a financiar el proyecto. Este no es un concepto nuevo —también existía en la guía anterior—, pero ahora cumple un papel más relevante al ser una de solo dos condiciones habilitantes, en lugar de quedar enterrado dentro del análisis por etapas.
- Es probable que el proyecto se complete y que el software se utilice para cumplir la función prevista. Este es el elemento genuinamente nuevo, y es donde reside el juicio profesional.
Ese segundo criterio exige evaluar si todavía existe una incertidumbre significativa de desarrollo. FASB señala dos fuentes principales de esa incertidumbre:
- Tecnología no probada o funcionalidad novedosa cuya viabilidad aún no se ha demostrado mediante programación y pruebas reales, no un documento de diseño, no una especificación, sino una prueba funcional.
- Requisitos de funcionamiento indefinidos o todavía cambiantes —la norma los define como "lo que una entidad necesita que el software haga, por ejemplo, funciones o características". Si el equipo todavía está debatiendo de forma sustancial qué debe hacer el producto, esa incertidumbre no se ha resuelto.
En la práctica, esto significa que el momento de capitalización ahora sigue a la evidencia de viabilidad, no a una fase del calendario. Un equipo que dedica dos sprints a explorar (spike) una funcionalidad técnicamente novedosa antes de comprometerse a construirla en serio reconocería esos sprints de exploración como gasto, porque todavía no se ha resuelto la incertidumbre sobre si siquiera se puede construir. Una vez que la exploración demuestra su viabilidad y la dirección compromete presupuesto para la construcción completa, se cumple el umbral de "finalización probable" y los costos de desarrollo posteriores se capitalizan, más allá de las ceremonias ágiles.
Por qué FASB dice que la capitalización no cambiará mucho, salvo para el SaaS
La propia expectativa de FASB es que, para la mayoría del software de uso interno local o basado en licencias, las enmiendas no modificarán drásticamente los resultados de capitalización: las empresas ya capitalizaban una vez que comenzaba la programación real, y la nueva prueba llega a un resultado más o menos similar, solo que sin el ejercicio de etiquetar etapas.
El software desarrollado para entregarse mediante un acuerdo SaaS o en la nube es una historia distinta. FASB espera explícitamente que la capitalización disminuya en estos proyectos. El razonamiento: los productos SaaS, por su propia naturaleza, se construyen y reconstruyen de forma continua, con una incertidumbre técnica y de producto significativa que persiste hasta muy avanzado el cronograma de desarrollo, a veces hasta poco antes de que una funcionalidad esté lista para lanzarse. Bajo la prueba de "finalización probable", esa incertidumbre persistente significa que muchos costos de desarrollo SaaS no superarán el umbral de capitalización hasta mucho más tarde en la construcción de lo que habría implicado el antiguo modelo por etapas. El efecto neto: una mayor parte de la nómina de ingeniería de un producto SaaS se registra como gasto de I+D del período corriente en lugar de como un activo amortizable a varios años. Se trata de un cambio significativo para el EBITDA reportado y la base de activos de cualquier empresa SaaS, incluso antes de que cambie una sola línea de código real.
Un ejemplo concreto: dos equipos, dos resultados
Supongamos que una empresa SaaS de 40 personas decide construir un módulo de pronóstico basado en IA para su producto. Así es como las normas antigua y nueva tratarían de forma distinta esa misma construcción de ocho meses.
Bajo el antiguo modelo por etapas, el equipo financiero intentaría trazar una línea: las primeras seis semanas de recopilación de requisitos y evaluación de proveedores eran "preliminares" (gasto), y todo lo posterior a la reunión de arranque era "desarrollo de la aplicación" (capitalizado), aun cuando el equipo de ingeniería pasara los dos meses siguientes realizando exploraciones (spikes) para determinar si el enfoque de pronóstico elegido podía alcanzar una precisión aceptable con los volúmenes de datos de producción. Según la letra de la antigua norma, una vez que la "etapa" cambiaba, esos sprints de exploración a menudo también se capitalizaban, porque técnicamente ocurrían después de la reunión de arranque.
Bajo la ASU 2025-06, el equipo financiero en cambio se pregunta: ¿cuándo se volvió probable que esta funcionalidad se completara y funcionara como estaba previsto? Si el enfoque de precisión seguía sin estar probado durante los primeros dos meses —el equipo estaba probando tres enfoques de modelado distintos y no sabía si alguno superaría el umbral—, todo ese período de exploración se registra como gasto, sin importar en qué "etapa" del calendario cayera. La capitalización comienza solo una vez que el equipo elige un enfoque validado y la dirección compromete presupuesto para construirlo, lo que en este ejemplo podría ser el tercer mes, no el segundo. El resultado: un activo capitalizado menor, un gasto de I+D del período corriente mayor y —lo más importante— una cifra que el CFO realmente puede defender en una auditoría, porque está vinculada a un punto de decisión específico y documentado, y no a una etiqueta de etapa aplicada después de los hechos.
Este es exactamente el cambio que FASB espera en todo el sector SaaS: menos "lo llamamos desarrollo de la aplicación porque eso fue lo que vino después de la llamada de arranque" y más "podemos señalar el sprint en el que se eliminó el riesgo técnico".
Fechas de vigencia y transición
La ASU 2025-06 entra en vigor para todas las entidades —públicas y privadas— para los períodos de reporte anual que comiencen después del 15 de diciembre de 2027, y los períodos intermedios dentro de esos años. Se permite la adopción anticipada para cualquier entidad, en cualquier período intermedio o anual, una vez emitida la norma.
Las entidades pueden aplicar las enmiendas utilizando uno de tres enfoques de transición: de forma prospectiva solo a los nuevos costos de software incurridos después de la fecha de vigencia, de forma prospectiva a los costos incurridos a partir del inicio del año de adopción, o de forma retrospectiva a todos los períodos presentados. Esa flexibilidad importa: una empresa que esté a mitad de una reescritura importante de su plataforma cuando la norma entre en vigor no tiene que deshacer años de historial de costos capitalizados, a menos que elija la opción retrospectiva.
Qué deben hacer ahora las empresas de software pequeñas y medianas
Diciembre de 2027 suena lejano, pero el trabajo práctico de preparación no es una tarea de último trimestre, en particular para las empresas que operan con equipos financieros reducidos y sin una función dedicada de contabilidad técnica.
Comience a documentar el juicio de "finalización probable" en tiempo real, no en retrospectiva. El antiguo modelo por etapas era mecánico: se podía reconstruir en qué etapa estaba un proyecto meses después a partir de las fechas de los sprints. La nueva prueba pregunta cuándo dejamos de tener incertidumbre técnica, un juicio profesional que se vuelve mucho más difícil de reconstruir después de los hechos. Cree ahora un hábito sencillo: cuando el liderazgo de ingeniería y finanzas coincidan en que una funcionalidad superó su exploración técnica y está comprometida para su construcción, registre esa fecha. Ese registro se convierte en su fecha de inicio de capitalización y en su respaldo de auditoría.
Separe el trabajo de "exploración" del trabajo de "construcción comprometida" en su seguimiento de tiempo o códigos de proyecto, si aún no lo hace. Ya sea mediante una marca de épica en Jira, un código de centro de costos separado o simplemente una etiqueta en su herramienta de seguimiento de tiempo, contar con un rastro de datos claro sobre cuándo una funcionalidad pasó de exploración/prototipo a desarrollo comprometido hará que aplicar la nueva norma sea muchísimo menos doloroso que intentar reconstruirlo de memoria durante una auditoría.
Modele ambas opciones de transición antes de elegir una. Si su empresa ha estado capitalizando de forma agresiva los costos de desarrollo SaaS bajo el antiguo marco por etapas, la aplicación retrospectiva podría producir una baja contable única de los activos previamente capitalizados, a medida que esos costos se reclasifican como si siempre se hubieran reconocido como gasto. Un enfoque prospectivo evita esa reexpresión, pero significa que su estado de resultados no reflejará la nueva metodología hasta que comiencen nuevos proyectos después de la adopción. Calcule las cifras bajo ambos enfoques antes de que su comité de auditoría tenga que hacerlo.
Hable con su auditor con anticipación, especialmente si es una empresa SaaS. Dada la propia expectativa de FASB de una disminución en la capitalización del desarrollo SaaS, es probable que los auditores examinen los juicios de "finalización probable" con más detenimiento del que aplicaban a las clasificaciones por etapas bajo la antigua norma, precisamente porque es más subjetivo. Una empresa que llegue a su auditoría de 2028 con un marco documentado y contemporáneo para tomar esa decisión tendrá una conversación mucho más sencilla que una que intente reconstruirlo después de los hechos.
Unos libros contables limpios facilitan defender los juicios profesionales
Todo juicio contable —y "finalización probable" es claramente un juicio profesional— es tan defendible como los registros que lo respaldan. Si su plan de cuentas ya separa el gasto de I+D por proyecto, y sus asientos contables están versionados y son auditables en lugar de vivir en hojas de cálculo desconectadas, aplicar una norma como la ASU 2025-06 se convierte en una cuestión de etiquetar datos existentes en lugar de reconstruir el historial a partir de hilos de Slack. La contabilidad en texto plano de Beancount.io le ofrece por defecto ese tipo de libro contable transparente y versionado con git: cada asiento es rastreable, cada cambio es revisable, sin dependencia de proveedor. Comience gratis y construya libros contables que se sostengan, ya sea que la pregunta venga de un auditor, un adquirente o la próxima actualización de FASB.