ASC 350-40 — el tema de codificación que los buscadores suelen escribir como 350/40 — es la regla del FASB para software de uso interno: cuándo el costo de desarrollo se gasta ahora versus cuándo se capitaliza como un activo intangible y se amortiza más tarde. Bajo el modelo de tres etapas heredado (que aún aplican la mayoría de los declarantes hasta la fecha obligatoria de ASU 2025-06), la respuesta cabe en una tabla:
| Etapa | Qué sucede | ¿Capitalizar o gastar? |
|---|---|---|
| Proyecto preliminar | Requisitos, demostraciones de proveedores, viabilidad, decisión de construir vs comprar | Gastar a medida que se incurre |
| Desarrollo de la aplicación | Codificación, configuración, pruebas, integración después de que la gerencia se compromete | Capitalizar costos directos de construcción |
| Post-implementación | Capacitación, mantenimiento, corrección de errores después del lanzamiento | Gastar (la nueva funcionalidad puede reiniciar la capitalización) |
ASU 2025-06 (emitida el 18 de septiembre de 2025; obligatoria para períodos anuales que comiencen después del 15 de diciembre de 2027) retira esas etiquetas de etapas por un umbral de probable-completar y señala que más costos se gastarán. Las secciones a continuación cubren qué incluye ASC 350-40, el detalle de las etapas, la actualización de 2025, la lista de verificación de capitalizar/gastar, y cómo la elección afecta el EBITDA y el balance general.
Qué Cubre ASC 350-40
ASC 350-40 es el estándar del FASB para software de uso interno — software que tu empresa construye o compra para sus propias operaciones en lugar de venderlo a clientes como producto principal. Ejemplos incluyen:
- Sistemas internos de CRM, ERP, RRHH o contabilidad
- Herramientas de infraestructura en la nube y plataformas DevOps
- Una plataforma SaaS que operas para clientes (el cliente la accede como servicio, no como software con licencia que instala)
- Tuberías de datos internas, paneles de control y herramientas de análisis
- Automatización de flujos de trabajo personalizados o back-office
Si vendes software con licencia que los clientes instalan en sus propias máquinas, eso cae bajo ASC 985-20 (software para venta externa), que tiene reglas diferentes. La mayoría de las empresas SaaS modernas caen bajo ASC 350-40 porque los clientes consumen el software como un servicio alojado.
La pregunta central que responde el estándar: cuando gastas dinero construyendo software, ¿debe ese costo gastarse inmediatamente o capitalizarse como un activo intangible y amortizarse en períodos futuros?
El Antiguo Modelo de Tres Etapas (Pre-ASU 2025-06)
Durante décadas, ASC 350-40 usó un marco basado en etapas. Bajo la guía heredada que sigue en efecto para la mayoría de los declarantes hasta 2027, el desarrollo de software se divide en tres fases discretas.
Etapa 1: Etapa Preliminar del Proyecto
Esta es la fase exploratoria — definir requisitos, evaluar tecnologías, obtener demostraciones de proveedores y decidir si construir, comprar o pasar. Todos los costos en esta etapa se gastan a medida que se incurren, similar a los gastos de investigación. El razonamiento: hasta que la gerencia se compromete, aún no tienes un activo probable.
Las actividades aquí incluyen:
- Formulación conceptual y alternativas de diseño
- Demostraciones de proveedores y evaluaciones de tecnología
- 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 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 típicamente incluyen:
- Salarios y beneficios para desarrolladores, ingenieros de control de calidad y gerentes de proyecto (solo el tiempo directamente atribuible a codificar, probar y configurar el 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 de intereses (en casos limitados)
La capitalización se detiene cuando el software está sustancialmente completo y listo para su uso previsto — generalmente cuando las pruebas están terminadas y el sistema se despliega a producción, incluso si el lanzamiento es gradual.
Etapa 3: Etapa Post-Implementación
Después del lanzamiento, los costos continuos vuelven al tratamiento de gasto. La capacitación, el mantenimiento, la corrección de errores y el soporte rutinario se gastan. La excepción: las mejoras que agregan nueva funcionalidad (no solo corregir o mantener funcionalidad existente) pueden capitalizarse usando los mismos criterios que la Etapa 2.
La Gran Actualización de 2025: ASU 2025-06
El 18 de septiembre de 2025, el FASB emitió ASU 2025-06, que moderniza significativamente ASC 350-40. La actualización es obligatoria para períodos anuales que comiencen después del 15 de diciembre de 2027, con adopción anticipada permitida.
El cambio es estructural: el modelo de tres etapas ha desaparecido. El FASB eliminó explícitamente todas las referencias a etapas de proyecto porque el marco heredado no encajaba con las prácticas modernas de desarrollo ágil e iterativo, donde los requisitos evolucionan y las "etapas" se superponen o corren en paralelo.
El Nuevo Umbral Basado en Principios
Bajo el estándar revisado, capitalizas costos de software solo cuando ambas condiciones se cumplen:
- Autorización de la gerencia: La gerencia ha autorizado y comprometido fondos para el proyecto.
- Umbral de probable-completar: Es probable que el proyecto se complete y que el software realice su función prevista.
Esa segunda prueba está haciendo trabajo real. El FASB introdujo un concepto llamado incertidumbre significativa de desarrollo para evaluar si la finalización es probable. Debes 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 están indeterminados o sujetos a revisión sustancial
Si existe incertidumbre significativa, la capitalización debe diferirse hasta que la incertidumbre se resuelva. El FASB ha señalado que espera que la nueva regla resulte en más costos de software siendo gastados, particularmente en empresas SaaS donde los requisitos iteran continuamente.
Qué Significa Esto en la Práctica
Para una startup construyendo algo genuinamente nuevo — una plataforma de agentes de IA, un motor de automatización novedoso — la nueva regla puede empujar más gasto a gastos operativos antes. Para empresas maduras que mejoran sistemas bien definidos, el impacto práctico será menor. De cualquier manera, el movimiento de una verificación mecánica de etapas a un umbral basado en juicio significa que las empresas necesitan documentación más clara de las decisiones de gestión, viabilidad técnica y estado del proyecto.
Qué Puedes y Qué No Puedes Capitalizar: Una Lista de Verificación Práctica
Ya sea que apliques el modelo de etapas heredado o la nueva prueba basada en principios, la línea entre gasto capitalizable y gastable es similar en espíritu. Aquí hay una lista de verificación práctica.
Generalmente Capitalizable
- Costos laborales directos para desarrolladores, diseñadores y control de calidad durante la fase de construcción
- Impuestos sobre nómina y beneficios asignados para esos empleados
- Honorarios de consultoría externa y contratistas para trabajo de desarrollo
- Software, herramientas y costos de infraestructura en la nube directamente consumidos en el desarrollo
- Costos para desarrollar nueva funcionalidad post-lanzamiento (mejoras que expanden materialmente las capacidades)
- Costos para desarrollar software de conversión (el software que migra datos antiguos a nuevos), en oposición a la actividad de conversión de datos en sí
Generalmente Gastado
- Investigación preliminar, selección de proveedores y análisis de viabilidad
- Capacitació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
- Costos de software incurridos durante períodos de incertidumbre significativa de desarrollo
- Gastos generales administrativos no directamente vinculados al desarrollo
- Marketing, soporte y actividades de éxito del cliente post-lanzamiento
El Problema del Seguimiento del Tiempo
El mayor desafío práctico es asignar el tiempo de ingeniería. Un ingeniero senior que pasa 40 horas por semana es poco probable que esté haciendo 100% de trabajo capitalizable — también está depurando producción, mentorizando compañeros, asistiendo a reuniones diarias y revisando solicitudes de extracción para sistemas heredados. Sin un método defendible de seguimiento del tiempo (tickets de ingeniería etiquetados por proyecto, software de seguimiento del tiempo o encuestas formales de asignación), las estimaciones de capitalización fallarán el escrutinio de auditoría.
El Impacto en los Estados Financieros
Capitalizar versus gastar el mismo dólar produce estados financieros dramáticamente diferentes.
Efecto en el Estado de Resultados
Un costo capitalizado no afecta el estado de resultados en el período en que se gastó. En cambio, se amortiza — típicamente en línea recta durante tres a cinco años para software de uso interno. Así, $1M de gasto de ingeniería capitalizado en el Año 1 podría crear solo $200K a $333K de gasto de amortización cada año, dejando el ingreso operativo del Año 1 materialmente más alto.
Esta es la razón por la que el EBITDA recibe un impulso de la capitalización. La amortización está, por definición, excluida del EBITDA — así que capitalizar más costo de desarrollo desplaza dólares del gasto operativo (que reduce el EBITDA) a la amortización (que no lo reduce). Los inversores que examinan métricas SaaS a menudo miran "EBITDA antes de I+D capitalizado" o cálculos de regla-de-40 usando I+D en efectivo para ver a través de esta dinámica.
Efecto en el Balance General
El software capitalizado aparece como un activo intangible a largo plazo, a menudo etiquetado como "Costos de Desarrollo de Software Capitalizados" o similar. Esto:
- Aumenta los activos totales y el patrimonio
- Mejora el rendimiento sobre activos (ROA) solo si las ganancias crecen más rápido que la base de activos
- Crea un activo que debe probarse por deterioro si el proyecto se abandona o su valor disminuye
Si un proyecto se abandona a mitad del desarrollo, los costos previamente capitalizados deben cancelarse — lo que produce una pérdida repentina, a menudo material. Esta es una razón por la que la nueva ASU 2025-06 enfatiza tanto el umbral de probable-completar.
Efecto en el Estado de Flujo de Efectivo
Los costos de desarrollo capitalizados se clasifican típicamente como actividades de inversión (no operativas), lo que hace que el flujo de efectivo operativo se vea más fuerte. Los inversores sofisticados ajustan esto al comparar empresas — pero el número del titular aún se beneficia.
Errores Comunes que Meten a las Empresas en Problemas
Los auditores y adquirentes ven los mismos errores una y otra vez.
Capitalizar Costos Pre-Autorización
El error clásico es capitalizar tiempo de ingeniería gastado antes de que la gerencia aprobara formalmente el proyecto. Sin una autorización documentada y compromiso de fondos, esos costos deberían haberse gastado. Asegúrate de tener actas de reuniones, aprobaciones de la junta o firmas escritas que establezcan cuándo se comprometió la gerencia.
Sin Documentación a Nivel de Proyecto
Si un regulador o auditor pregunta "muéstrame los proyectos que capitalizaste" y solo puedes señalar gasto general de ingeniería, perderás. Necesitas 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 senior 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 la auditoría.
Continuar Capitalizando Después del Lanzamiento
En el momento en que el software está listo para su uso previsto, la capitalización se detiene. La corrección de errores, el ajuste de rendimiento y las mejoras menores después de ese punto son gastos operativos. Las características nuevas y separadamente definidas pueden comenzar un nuevo período de capitalización — pero el trabajo rutinario post-lanzamiento no puede.
Olvidar la Prueba de Deterioro
El software capitalizado es un activo, y los activos deben deteriorarse si su valor cae. Si enfrías un producto, retiras una característica o reescribes fundamentalmente el sistema, debes reevaluar y probablemente cancelar el saldo previo.
Cómo Configurar un Proceso Defendible
Si decides que la capitalización es adecuada para tu empresa, el proceso importa tanto como la política.
-
Escribe una política de capitalización de software. Define qué proyectos califican, tu proceso de autorización, tu estimación de vida útil y cómo asignarás el tiempo. Obtén la aprobación de tu CFO o comité de auditoría.
-
Rastrea el tiempo de ingeniería a nivel de proyecto. Esta es la entrada fundamental. Ya sea que uses etiquetas de Jira, etiquetas personalizadas en un rastreador de proyectos o hojas de tiempo formales, necesitas defender "el ingeniero X gastó el Y% de su tiempo en trabajo capitalizable en el proyecto Z".
-
Documenta la aprobación de la gerencia. Cada proyecto capitalizable necesita evidencia de autorización — aprobación escrita fechada, actas de la junta o una carta de proyecto firmada por el liderazgo.
-
Reevalúa la incertidumbre significativa regularmente. Bajo la nueva regla, necesitas monitorear si las características siguen siendo novedosas o no probadas y si los requisitos se están estabilizando. Revisiones trimestrales con el liderazgo de ingeniería son razonables.
-
Construye cronogramas de amortización por proyecto. Cada proyecto capitalizado comienza a amortizarse cuando está listo para su uso, y necesitas rastrear la base del costo de ese activo, la amortización acumulada y la vida restante.
-
Prueba el deterioro cuando los proyectos cambien. Cada vez que abandones, reescribas materialmente o retires trabajo capitalizado, ejecuta un análisis de deterioro y registra las cancelaciones según sea necesario.
Por Qué Esto Importa para la Contabilidad
La capitalización de software es una de esas áreas donde la disciplina contable del día uno da frutos años después. Los inversores durante una ronda Serie B extraerán tu balance de comprobación; los adquirentes en un proceso de venta rastrearán transacciones hasta los asientos de diario; el IRS puede comparar tu tratamiento GAAP con tu tratamiento fiscal de I+D de la Sección 174, que tiene sus propias reglas. Si tus libros no separan proyectos capitalizados de gastos operativos, no pueden vincular los cargos de tiempo de ingeniería a proyectos específicos, o no mantienen cronogramas de amortización limpios, cada ciclo de auditoría y diligencia se vuelve doloroso.
La solución es simple en concepto: mantén una estructura de cuentas limpia, rastrea el tiempo a nivel de proyecto y documenta las decisiones detrás de cada entrada de capitalización. Hacer esto desde el principio evita limpiezas costosas más adelante.
Mantén Tu Contabilidad de Software Lista para Auditoría
Ya sea que estés capitalizando tu primera plataforma interna o ejecutando cronogramas de amortización en docenas de proyectos, los registros financieros limpios son la base. Beancount.io proporciona contabilidad de texto plano que te da libros transparentes y controlados por versiones — cada entrada trazable, cada cuenta auditable, cada informe reproducible. Para empresas de software que rastrean desarrollo capitalizado en múltiples proyectos, tener libros que se lean como código es una ventaja seria. Comienza gratis y descubre por qué los desarrolladores y profesionales de finanzas están cambiando a la contabilidad de texto plano.
