Capitalización de Software bajo ASC 350-40: Una Guía Práctica para la Decisión de Capitalizar vs. Gastar

Una encuesta de Gartner de 2024 encontró que el 63% de los fundadores de SaaS en etapas iniciales clasifican erróneamente los costos de desarrollo de software. El error les cuesta en dos frentes: los inversores descuentan sus estados financieros cuando las clasificaciones parecen descuidadas, y los auditores señalan el problema durante la diligencia debida, lo que puede retrasar las rondas de financiación o los procesos de venta por meses.

La capitalización de software no es solo un tecnicismo contable. Afecta directamente al EBITDA, al balance general y a cómo se ve su negocio ante prestamistas, inversores y compradores. Las reglas bajo la ASC 350-40 —y una actualización importante de 2025— determinan qué costos impactan el estado de resultados de inmediato y cuáles se distribuyen a lo largo de los años.

Esta guía recorre lo que requiere el estándar, la reciente reforma de la ASU 2025-06, los costos que puede capitalizar, los que no puede y las consecuencias en los estados financieros de hacerlo correctamente.

Qué cubre el estándar ASC 350-40

ASC 350-40 es el estándar del FASB para el software de uso interno: software que su empresa construye o compra para sus propias operaciones en lugar de para venderlo a los clientes como producto principal. Los ejemplos incluyen:

• Sistemas internos de CRM, ERP, RR.HH. o contabilidad
• Herramientas de infraestructura en la nube y plataformas DevOps
• Una plataforma SaaS que opera para clientes (el cliente accede a ella como un servicio, no como un software con licencia que instala)
• Canales de datos internos, tableros de control y herramientas de análisis
• Automatización personalizada de flujos de trabajo o de back-office

Si vende software con licencia que los clientes instalan en sus propias máquinas, eso entra bajo la ASC 985-20 (software para venta externa), que tiene reglas diferentes. La mayoría de las empresas modernas de SaaS caen bajo la ASC 350-40 porque los clientes consumen el software como un servicio alojado.

La pregunta principal que responde el estándar es: cuando gasta dinero construyendo software, ¿ese costo debe llevarse a gastos inmediatamente o capitalizarse como un activo intangible y amortizarse en períodos futuros?

El antiguo modelo de tres etapas (previo a ASU 2025-06)

Durante décadas, la ASC 350-40 utilizó un marco basado en etapas. Bajo la guía heredada que sigue vigente para la mayoría de los declarantes hasta 2027, el desarrollo de software se divide en tres etapas distintas.

Etapa 1: Etapa preliminar del proyecto

Esta es la fase exploratoria: definir requisitos, evaluar tecnologías, recibir demostraciones de proveedores y decidir si construir, comprar o pasar. Todos los costos en esta etapa se llevan a gastos conforme se incurren, de manera similar a los gastos de investigación. El razonamiento: hasta que la gerencia se comprometa, aún no tiene un activo probable.

Las actividades aquí incluyen:

• Formulación conceptual y alternativas de diseño
• Demostraciones de proveedores y evaluaciones tecnológicas
• Análisis de costo-beneficio y estudios de viabilidad
• Selección final de un enfoque o proveedor

Etapa 2: Etapa de desarrollo de la aplicación

La capitalización comienza cuando la gerencia autoriza el proyecto, compromete los fondos y la finalización es probable. Esta etapa cubre la construcción real: codificación, pruebas, configuración, integración e instalación.

Los costos capitalizables en esta etapa suelen incluir:

• Salarios y beneficios para desarrolladores, ingenieros de control de calidad (QA) y gerentes de proyecto (solo el tiempo directamente atribuible a la codificación, pruebas y configuración del software)
• Honorarios de consultoría externa para trabajo de desarrollo
• Licencias de software y herramientas utilizadas para construir la aplicación
• Costos directos de materiales y servicios consumidos en el desarrollo
• Costos por intereses (en casos limitados)

La capitalización se detiene cuando el software está sustancialmente completo y listo para su uso previsto, generalmente cuando terminan las pruebas y el sistema se despliega en producción, incluso si el despliegue es gradual.

Etapa 3: Etapa de post-implementación

Después de la puesta en marcha, los costos continuos vuelven al tratamiento de gastos. La capacitación, el mantenimiento, la corrección de errores y el soporte de rutina se llevan a gastos. La excepción: las mejoras que agregan nueva funcionalidad (no solo arreglar o mantener la funcionalidad existente) pueden capitalizarse utilizando los mismos criterios que en la Etapa 2.

La actualización importante de 2025: ASU 2025-06

El 18 de septiembre de 2025, el FASB emitió la ASU 2025-06, que moderniza significativamente la ASC 350-40. La actualización es obligatoria para los períodos anuales que comiencen después del 15 de diciembre de 2027, permitiéndose la adopción anticipada.

El cambio es estructural: el modelo de tres etapas ha desaparecido. El FASB eliminó explícitamente todas las referencias a las etapas del proyecto porque el marco heredado no se ajustaba a las prácticas modernas de desarrollo ágil e iterativo, donde los requisitos evolucionan y las "etapas" se superponen o se ejecutan en paralelo.

El nuevo umbral basado en principios

Bajo el estándar revisado, usted capitaliza los costos de software solo cuando se cumplen ambas condiciones siguientes:

1. Autorización de la gerencia: La gerencia ha autorizado y se ha comprometido a financiar el proyecto.
2. Umbral de probabilidad de finalización: Es probable que el proyecto se complete y que el software realice su función prevista.

Esa segunda prueba es la que realmente importa. El FASB introdujo un concepto llamado incertidumbre significativa en el desarrollo para evaluar si la finalización es probable. Debe evaluar:

• Si el software incluye características novedosas o no probadas que no han sido validadas mediante codificación o pruebas
• Si los requisitos de rendimiento aún no están determinados o están sujetos a revisiones sustanciales

Si existe una incertidumbre significativa, la capitalización debe diferirse hasta que se resuelva la incertidumbre. El FASB ha señalado que espera que la nueva regla resulte en que se lleven a gastos más costos de software, particularmente en empresas SaaS donde los requisitos iteran continuamente.

Qué significa esto en la práctica

Para una startup que construye algo genuinamente nuevo —una plataforma de agentes de IA, un motor de automatización novedoso— la nueva norma puede empujar más gasto hacia los gastos operativos de forma más temprana. Para empresas maduras que mejoran sistemas bien definidos, el impacto práctico será menor. De cualquier manera, el paso de una verificación de etapa mecánica a un umbral basado en el juicio significa que las empresas necesitan una documentación más clara de las decisiones de gestión, la viabilidad técnica y el estado del proyecto.

Qué se puede y qué no se puede capitalizar: Una lista de verificación práctica

Ya sea que esté aplicando el modelo de etapas heredado o la nueva prueba basada en principios, la línea entre los gastos capitalizables y los imputables a gastos es similar en espíritu. Aquí hay una lista de verificación de trabajo.

Generalmente capitalizable

• Costes directos de mano de obra para desarrolladores, diseñadores y QA durante la fase de construcción
• Impuestos sobre la nómina y beneficios asignados para esos empleados
• Honorarios de consultoría externa y contratistas para trabajos de desarrollo
• Costes de software, herramientas e infraestructura en la nube consumidos directamente en el desarrollo
• Costes para desarrollar nuevas funcionalidades tras el lanzamiento (mejoras que amplían materialmente las capacidades)
• Costes para desarrollar software de conversión (el software que migra datos antiguos a nuevos), a diferencia de la actividad de conversión de datos en sí misma

Generalmente imputado a gastos

• Investigación preliminar, selección de proveedores y análisis de viabilidad
• Formación de empleados en el nuevo sistema
• Limpieza de datos, conciliación y migración de registros
• Mantenimiento rutinario, corrección de errores y refactorización menor
• Costes de software incurridos durante periodos de incertidumbre significativa en el desarrollo
• Gastos generales de administración no vinculados directamente al desarrollo
• Actividades de marketing, soporte y éxito del cliente (customer success) tras el lanzamiento

El problema del registro de tiempo

El mayor desafío práctico es la asignación del tiempo de ingeniería. Es poco probable que un ingeniero sénior que dedica 40 horas a la semana realice un trabajo 100% capitalizable; también está depurando producción, asesorando a compañeros, asistiendo a reuniones diarias (standups) y revisando pull requests para sistemas heredados. Sin un método de registro de tiempo defendible (tickets de ingeniería etiquetados por proyecto, software de seguimiento de tiempo o encuestas formales de asignación), las estimaciones de capitalización no superarán el escrutinio de una auditoría.

El impacto en los estados financieros

Capitalizar frente a imputar como gasto el mismo dólar produce estados financieros drásticamente diferentes.

Efecto en el estado de resultados

Un coste capitalizado no afecta al estado de resultados en el periodo en que se gasta. En su lugar, se amortiza, normalmente de forma lineal durante tres a cinco años para el software de uso interno. Por lo tanto, 1 millón de dólares de gasto en ingeniería capitalizado en el Año 1 podría generar solo entre 200.000 y 333.000 dólares de gasto de amortización cada año, lo que deja el beneficio operativo del Año 1 materialmente más alto.

Este es el motivo por el cual el EBITDA recibe un impulso de la capitalización. La amortización está, por definición, excluida del EBITDA; por lo tanto, capitalizar más costes de desarrollo traslada dólares del gasto operativo (que reduce el EBITDA) a la amortización (que no lo hace). Los inversores que analizan las métricas de SaaS a menudo observan el "EBITDA antes de I+D capitalizado" o los cálculos de la "regla del 40" utilizando I+D en efectivo para ver a través de esta dinámica.

Efecto en el balance de situación

El software capitalizado aparece como un activo intangible a largo plazo, a menudo etiquetado como "Costes de desarrollo de software capitalizados" o similar. Esto:

• Aumenta los activos totales y el patrimonio neto
• Mejora la rentabilidad sobre los activos (ROA) solo si los beneficios aumentan más rápido que la base de activos
• Crea un activo que debe someterse a pruebas de deterioro si el proyecto se abandona o si su valor disminuye

Si un proyecto se abandona a mitad del desarrollo, los costes previamente capitalizados deben darse de baja, lo que produce una pérdida repentina y a menudo material. Esta es una de las razones por las que la nueva ASU 2025-06 enfatiza tan fuertemente el umbral de "probabilidad de finalización".

Efecto en el estado de flujos de efectivo

Los costes de desarrollo capitalizados se clasifican normalmente como actividades de inversión (no operativas), lo que hace que el flujo de caja operativo parezca más sólido. Los inversores sofisticados ajustan esto al comparar empresas, pero la cifra principal sigue beneficiándose.

Errores comunes que meten a las empresas en problemas

Los auditores y adquirentes ven los mismos errores una y otra vez.

Capitalización de costes previos a la autorización

El error clásico es capitalizar el tiempo de ingeniería dedicado antes de que la dirección aprobara formalmente el proyecto. Sin una autorización documentada y un compromiso de financiación, esos costes deberían haberse imputado a gastos. Asegúrese de tener actas de reuniones, aprobaciones de la junta o autorizaciones firmadas por escrito que establezcan cuándo se comprometió la dirección.

Ausencia de documentación a nivel de proyecto

Si un regulador o auditor pregunta "muéstreme los proyectos que capitalizó" y usted solo puede señalar el gasto general de ingeniería, perderá. Necesita registros proyecto por proyecto: alcance, fecha de autorización, presupuesto, estado y tiempo cargado.

Tratar todo el tiempo de ingeniería como capitalizable

Los ingenieros sénior corrigen errores, revisan código, asisten a reuniones y responden a incidentes. Nada de eso es capitalizable. Las empresas que simplemente multiplican la nómina del equipo de ingeniería por algún porcentaje rara vez sobreviven a una auditoría.

Seguir capitalizando después del lanzamiento

En el momento en que el software está listo para su uso previsto, la capitalización se detiene. Las correcciones de errores, el ajuste del rendimiento y las mejoras menores después de ese punto son gastos operativos. Las nuevas funciones con un alcance independiente pueden iniciar un nuevo periodo de capitalización, pero el trabajo rutinario posterior al lanzamiento no puede hacerlo.

Olvidar las pruebas de deterioro

El software capitalizado es un activo, y los activos deben someterse a pruebas de deterioro si su valor disminuye. Si se archiva un producto, se retira una funcionalidad o se reescribe fundamentalmente el sistema, se debe reevaluar y, probablemente, dar de baja el saldo anterior.

Cómo establecer un proceso defendible

Si decide que la capitalización es adecuada para su empresa, el proceso es tan importante como la política.

1. Redacte una política de capitalización de software. Defina qué proyectos califican, su proceso de autorización, su estimación de vida útil y cómo asignará el tiempo. Obtenga la aprobación de su CFO o del comité de auditoría.

2. Realice un seguimiento del tiempo de ingeniería a nivel de proyecto. Este es el dato fundamental. Ya sea que utilice etiquetas de Jira, etiquetas personalizadas en un gestor de proyectos o registros de horas formales, debe poder defender que "el ingeniero X dedicó el Y% de su tiempo al trabajo capitalizable en el proyecto Z".

3. Documente la aprobación de la dirección. Cada proyecto capitalizable necesita evidencia de autorización: aprobación por escrito fechada, actas de la junta directiva o una carta constitutiva del proyecto firmada por el liderazgo.

4. Reevalúe regularmente la incertidumbre significativa. Según la nueva normativa, debe supervisar si las funcionalidades siguen siendo novedosas o no probadas, y si los requisitos se están estabilizando. Las revisiones trimestrales con el liderazgo de ingeniería son razonables.

5. Cree calendarios de amortización por proyecto. Cada proyecto capitalizado comienza a amortizarse cuando está listo para su uso, y debe realizar un seguimiento de la base de costo de ese activo, la amortización acumulada y la vida útil restante.

6. Realice pruebas de deterioro cuando los proyectos cambien. Cada vez que abandone, reescriba sustancialmente o retire un trabajo capitalizado, realice un análisis de deterioro y registre las desvalorizaciones según sea necesario.

Por qué esto es importante para la contabilidad

La capitalización de software es una de esas áreas donde la disciplina contable desde el primer día da sus frutos años después. Los inversores durante una ronda de Serie B revisarán su balance de comprobación; los adquirentes en un proceso de venta rastrearán las transacciones hasta los asientos contables; el IRS puede comparar su tratamiento bajo los GAAP con su tratamiento fiscal de I+D de la Sección 174, que tiene sus propias reglas. Si sus libros no separan los proyectos capitalizados de los gastos operativos, no pueden vincular los cargos de tiempo de ingeniería a proyectos específicos o no mantienen calendarios de amortización limpios, cada ciclo de auditoría y diligencia debida se vuelve doloroso.

La solución es conceptualmente sencilla: mantenga una estructura de cuentas limpia, realice un seguimiento del tiempo a nivel de proyecto y documente las decisiones detrás de cada asiento de capitalización. Hacer esto desde el principio evita limpiezas costosas más adelante.

Mantenga su contabilidad de software lista para auditorías

Ya sea que esté capitalizando su primera plataforma interna o gestionando calendarios de amortización en docenas de proyectos, los registros financieros limpios son la base. Beancount.io ofrece contabilidad en texto plano que le brinda libros transparentes y con control de versiones: cada entrada es rastreable, cada cuenta es auditable y cada informe es reproducible. Para las empresas de software que rastrean el desarrollo capitalizado en múltiples proyectos, tener libros que se leen como código es una ventaja seria. Comience gratis y descubra por qué los desarrolladores y profesionales de las finanzas se están pasando a la contabilidad en texto plano.