Los costes de desarrollo de software son el dinero que se dedica a personas, contratistas, herramientas e infraestructura para diseñar, desarrollar y probar software — y en 2026 la pregunta difícil ya no es solo cuánto suman, sino dónde se reflejan en sus estados financieros. Los mismos $500,000 pueden ser un golpe de un año al resultado operativo o un activo que se reparte a lo largo de tres a cinco años, según en qué se gastó el dinero, cuándo y con arreglo a qué norma contable.
La contabilidad de los costes de desarrollo de software suele volverse urgente en un momento previsible: la primera auditoría, una ronda de financiación o la primera factura importante de un equipo externo. Las empresas que contratan servicios de ingeniería de producto para empresas de software suelen toparse con la cuestión cuando el auditor les pide desglosar las facturas mensuales de un proveedor en investigación, nueva funcionalidad y mantenimiento — y nadie previó ese desglose al firmar el contrato.
Dos cambios hacen de 2026 un buen año para revisar su política. En EE. UU., la ASU 2025-06 del FASB reescribe las reglas del software de uso interno por primera vez en décadas, y la One Big Beautiful Bill Act restableció la deducción fiscal inmediata de los gastos nacionales de investigación y experimentación a través de la nueva Section 174A. Esta guía explica ambos cambios, junto con las reglas IFRS que siguen muchas empresas europeas. Se trata de información general, no de asesoramiento fiscal ni de auditoría: confirme su política con su auditor y su asesor fiscal.
¿Qué son los costes de desarrollo de software?
Los costes de desarrollo de software son todos los costes directamente atribuibles a la creación de software: nóminas del personal propio, honorarios de contratistas y agencias, licencias y herramientas, entornos cloud y trabajo con datos utilizados durante el desarrollo. Los costes indirectos, como el alquiler de oficinas o la dirección general, forman parte del coste de funcionamiento de la empresa, pero las normas contables rara vez permiten tratarlos como parte del activo de software.
A efectos contables, conviene clasificar los costes primero por naturaleza y después por actividad. La naturaleza indica qué se pagó; la actividad, que se trata en la sección siguiente, indica si puede capitalizarse. La tabla resume los componentes habituales y su tratamiento típico según US GAAP para el software de uso interno.
| Componente de coste | Qué incluye | Tratamiento contable habitual |
|---|---|---|
| Nóminas del personal propio | Salarios, cotizaciones sociales y beneficios de ingenieros, QA, diseñadores y product managers que trabajan en el desarrollo | Capitalizable por el tiempo dedicado a diseño, codificación y pruebas tras alcanzar el umbral; en caso contrario, gasto |
| Contratistas y outsourcing | Honorarios de agencias de desarrollo, freelancers y equipos dedicados | Capitalizable como coste directo externo cuando el trabajo es de desarrollo; gasto si es investigación, soporte o formación |
| Licencias de software y herramientas | IDE, herramientas de pruebas, componentes de terceros adquiridos para el producto | Los componentes integrados en el software pueden capitalizarse; las herramientas generales del equipo suelen llevarse a gasto |
| Cloud y entornos | Entornos de desarrollo, pruebas y staging durante el desarrollo | Capitalizable solo si se usa directamente para desarrollar el software; el alojamiento en producción es un gasto operativo |
| Conversión y migración de datos | Limpieza, mapeo y carga de datos heredados | Gasto, salvo el software desarrollado específicamente para convertir datos |
| Formación y gestión del cambio | Formación de usuarios, documentación para el personal, soporte en el despliegue | Siempre gasto |
| Gastos generales y G&A | Alquiler, RR. HH., finanzas, dirección general | Gasto; no se imputa al software de uso interno |
Este artículo se centra en cómo se registran esos costes, no en cuánto deberían ser. Si necesita rangos de precios por tipo de proyecto, tamaño de equipo y región, consulte nuestros benchmarks de costes de desarrollo de software para 2026.
¿Los costes de desarrollo de software deben capitalizarse o llevarse a gasto?
Los costes de desarrollo de software se capitalizan cuando crean o añaden funcionalidad a un software que generará beneficios futuros y se ha alcanzado el umbral contable correspondiente; todo lo demás se lleva a gasto a medida que se incurre. En la práctica, la investigación, la planificación, el mantenimiento, la formación y los gastos generales van a la cuenta de resultados, mientras que el diseño, la codificación y las pruebas de nueva funcionalidad pueden convertirse en un activo.
La decisión se toma actividad por actividad, no factura por factura. Un mismo sprint puede contener trabajo capitalizable en un módulo nuevo, corrección de errores en uno antiguo que se lleva a gasto y spikes de investigación que también son gasto. La tabla muestra el resultado típico para el software de uso interno según US GAAP; IFRS llega a resultados similares en la mayoría de las filas, pero mediante una prueba distinta que se explica más adelante.
| Actividad | Tratamiento habitual | Motivo |
|---|---|---|
| Estudios de viabilidad, estudios de mercado, pruebas de concepto (spikes) | Gasto | Se produce antes de que el proyecto se apruebe y su finalización sea probable |
| Recopilación de requisitos y selección de proveedor o tecnología | Gasto | Se evalúan alternativas, no se desarrolla la solución elegida |
| Diseño de software y arquitectura de la solución elegida | Capitalizar (una vez superado el umbral) | Crea directamente el activo |
| Programación, configuración e integración | Capitalizar (una vez superado el umbral) | Actividad central de desarrollo |
| Pruebas, incluido el procesamiento en paralelo antes de la puesta en producción | Capitalizar (una vez superado el umbral) | Necesarias para que el software esté listo para su uso |
| Conversión de datos | Gasto | Salvo el software desarrollado para convertir los datos |
| Formación | Gasto | No crea el activo de software |
| Mantenimiento, corrección de errores y pequeños ajustes tras el lanzamiento | Gasto | Mantiene en funcionamiento la funcionalidad existente |
| Actualizaciones y mejoras que añaden funcionalidad | Capitalizar | Crea una capacidad nueva y se trata como un desarrollo nuevo |
| Gastos generales y de administración | Gasto | No son directamente atribuibles al software |
La prueba decisiva para el trabajo posterior al lanzamiento es fácil de formular y difícil de aplicar: ¿aporta al software una capacidad que antes no tenía? Un nuevo módulo de informes la supera; refactorizar para mejorar el rendimiento o corregir defectos normalmente no. Ponga la regla por escrito, incluya ejemplos y aplíquela de la misma forma cada mes.
¿Cómo funciona hoy la ASC 350-40 para el software de uso interno?
Con la ASC 350-40 vigente, el software de uso interno sigue un modelo de tres etapas: los costes de la etapa preliminar del proyecto se registran como gasto, los de la etapa de desarrollo de la aplicación se capitalizan y los de la etapa posterior a la implantación y de operación se registran como gasto. Hasta que una empresa adopte la ASU 2025-06, esta sigue siendo la regla para quienes informan bajo US GAAP.
El software de uso interno es el que se adquiere, desarrolla o modifica únicamente para cubrir las necesidades internas de la empresa, sin un plan sustantivo de comercializarlo externamente. Eso incluye las personalizaciones de ERP, las herramientas internas, los portales de clientes y, lo que es importante, la mayoría de las plataformas SaaS, que se tratan más abajo.
Las tres etapas
- Etapa preliminar del proyecto — formulación conceptual, evaluación de alternativas, determinación de la tecnología necesaria y selección final. Todos los costes se registran como gasto.
- Etapa de desarrollo de la aplicación — diseño de la opción elegida, programación, instalación del hardware y pruebas, incluido el procesamiento en paralelo. La capitalización comienza cuando ha concluido la etapa preliminar, la dirección autoriza el proyecto y se compromete a financiarlo, y es probable que el proyecto se complete y el software se utilice según lo previsto.
- Etapa posterior a la implantación y de operación — formación y mantenimiento. La capitalización se detiene cuando el software está sustancialmente terminado y listo para el uso previsto, lo que en general significa una vez finalizadas todas las pruebas sustanciales.
Qué se puede capitalizar y qué no
Son capitalizables los costes directos externos de materiales y servicios consumidos en el desarrollo del software, los costes de nómina y asociados a la nómina de los empleados vinculados directamente al proyecto en la medida del tiempo que le dedican, y los costes por intereses incurridos durante el desarrollo según la ASC 835-20. Los gastos generales y de administración, los costes indirectos, la formación y la conversión de datos se registran como gasto aunque se produzcan durante la etapa de desarrollo de la aplicación.
Acuerdos de computación en la nube: costes de implantación del SaaS que usted contrata
Cuando su empresa es cliente de un producto SaaS alojado, los costes de implantación siguen las mismas reglas por etapas de la ASC 350-40 en virtud de la ASU 2018-15, aunque nunca llegue a ser propietaria del software. Los costes de configurar, integrar y probar la solución alojada durante la etapa de desarrollo de la aplicación se capitalizan, se amortizan a lo largo del plazo del acuerdo de alojamiento, incluidas las renovaciones razonablemente seguras, y se presentan en la misma línea de la cuenta de resultados que las cuotas de suscripción. La propia cuota de suscripción sigue siendo un gasto operativo.
Para las empresas que operan varios sistemas a la vez, estas reglas se aplican a cada proyecto de integración. Nuestros equipos de desarrollo de software a medida documentan el trabajo de configuración e integración por separado del soporte precisamente por este motivo.
¿Qué cambia la ASU 2025-06?
La ASU 2025-06, emitida por el FASB el 18 de septiembre de 2025, elimina las tres etapas del proyecto de la ASC 350-40 y las sustituye por un único umbral de reconocimiento: se capitaliza una vez que la dirección ha autorizado el proyecto y se ha comprometido a financiarlo, y es probable que el proyecto se complete y el software se utilice para cumplir la función prevista. Asesores como RSM la describen como la mayor revisión de la contabilidad del software de uso interno desde 1998, impulsada en gran medida por el desarrollo ágil.
El modelo por etapas presuponía un proyecto lineal en cascada, en el que la planificación terminaba antes de empezar a programar. Los equipos ágiles planifican, diseñan, desarrollan y prueban en cada sprint, por lo que las etapas nunca encajaron bien con su trabajo. La nueva norma abandona esa premisa y plantea una pregunta más práctica sobre la incertidumbre.
El umbral de finalización probable y la incertidumbre significativa en el desarrollo
Al valorar si la finalización es probable, la empresa debe considerar si existe una incertidumbre significativa en el desarrollo. La norma ofrece dos indicadores:
- el software tiene funciones o características novedosas, únicas o no probadas, y la incertidumbre sobre ellas aún no se ha resuelto mediante la programación y las pruebas;
- los requisitos de rendimiento significativos no se han identificado o todavía se están revisando de forma significativa.
Mientras esté presente cualquiera de los dos indicadores, no se alcanza el umbral y los costes se registran como gasto. Esto puede retrasar la capitalización en productos experimentales — por ejemplo, una nueva funcionalidad de aprendizaje automático — y, a la vez, hacer que la capitalización empiece antes y de forma más previsible en desarrollos rutinarios, como un portal de clientes sobre tecnología probada.
Modelo anterior de tres etapas frente a la ASU 2025-06
| Tema | ASC 350-40 vigente | ASC 350-40 tras la ASU 2025-06 |
|---|---|---|
| Inicio de la capitalización | Entrada en la etapa de desarrollo de la aplicación, más autorización, financiación y finalización probable | Autorización y compromiso de financiación más el umbral de finalización probable; sin etapas |
| Encaje con el desarrollo ágil | Deficiente; las etapas deben asignarse a los sprints a criterio | Mejor; se centra en la incertidumbre y no en la fase del proyecto |
| Incertidumbre en el desarrollo | No se trata de forma explícita | Debe considerarse la incertidumbre significativa en el desarrollo, con dos indicadores |
| Costes de desarrollo de sitios web | Orientaciones propias en la ASC 350-50 | La ASC 350-50 queda derogada; los costes de sitios web siguen la ASC 350-40 |
| Información a revelar | Información general sobre activos intangibles | El software de uso interno capitalizado sigue la información a revelar sobre inmovilizado material de la ASC 360-10 |
| Software vendido o licenciado (ASC 985-20) | Modelo independiente | Sin cambios |
| Fecha de entrada en vigor | — | Ejercicios anuales que comiencen después del 15 de diciembre de 2027; se permite la adopción anticipada |
Fecha de entrada en vigor y opciones de transición
La ASU 2025-06 entra en vigor para los ejercicios anuales que comiencen después del 15 de diciembre de 2027 y los periodos intermedios dentro de ellos, es decir, el ejercicio fiscal 2028 para las empresas cuyo ejercicio coincide con el año natural. Se permite la adopción anticipada al inicio de un ejercicio anual. Las empresas pueden adoptarla de una de estas tres formas:
- De forma prospectiva — aplicar las nuevas reglas a los costes incurridos tras la adopción;
- Transición modificada — aplicarlas a los proyectos aún en curso en el momento de la adopción, con un ajuste por efecto acumulado en las reservas (resultados acumulados) de apertura;
- De forma retroactiva — reexpresar los periodos anteriores presentados.
¿Conviene adoptarla de forma anticipada en 2026?
La adopción anticipada tiene sentido para empresas cuyo desarrollo es mayoritariamente ágil y rutinario, y menos para las que tienen mucho trabajo experimental o inversores que comparan periodos con detalle. Valore estos puntos con su auditor:
- A favor: menos asignación manual de sprints a etapas y menos decisiones de criterio que documentar cada trimestre.
- A favor: una política que refleja cómo trabajan realmente los equipos ágiles y de producto, más fácil de explicar a nuevos auditores e inversores.
- A favor: los costes de desarrollo de sitios web pasan al mismo modelo, de modo que una sola política cubre el producto y el sitio de marketing.
- En contra: las políticas, los controles y la configuración de los sistemas deben reescribirse antes de que comience el ejercicio de adopción.
- En contra: los proyectos con funcionalidades novedosas pueden empezar a capitalizar más tarde que hoy, lo que reduce a corto plazo los activos y el beneficio operativo declarados.
- En contra: con el método prospectivo se resiente la comparabilidad con periodos anteriores, y la reexpresión completa exige esfuerzo.
- En cualquier caso: la nueva información a revelar al estilo de la ASC 360-10 requiere datos — conciliaciones de movimientos de activos, vidas útiles y deterioros — que muchas empresas hoy no recopilan.
¿Cómo se contabiliza el software que usted vende o licencia (ASC 985-20)?
El software destinado a venderse, arrendarse o comercializarse de otro modo sigue la ASC 985-20: todos los costes se registran como gasto de investigación y desarrollo hasta que se establece la viabilidad tecnológica, y solo se capitalizan los costes incurridos a partir de ese momento y antes del lanzamiento general. Como la viabilidad suele alcanzarse tarde en el proyecto, la mayoría de las empresas sujetas a la ASC 985-20 capitalizan muy poco.
La viabilidad tecnológica se establece cuando la empresa ha completado un diseño detallado del programa o, a falta de este, un modelo operativo del producto. Los equipos que no elaboran de antemano un diseño detallado del programa — lo habitual en el desarrollo ágil — llegan a un modelo operativo cerca del final del desarrollo, por lo que el periodo capitalizable puede reducirse a unas pocas semanas de pruebas finales y producción de las versiones maestras del producto.
Los costes capitalizados se amortizan producto por producto, utilizando el mayor de dos importes: la proporción entre los ingresos brutos del periodo y el total de ingresos actuales y futuros previstos, o la amortización lineal durante la vida económica estimada restante del producto. En cada fecha de balance, el saldo pendiente de amortizar se compara con el valor neto realizable y se reduce si es superior. La ASU 2025-06 no cambia nada de esto.
¿Dónde encajan los productos SaaS?
La mayoría de los productos SaaS se rigen por la ASC 350-40 como software de uso interno, no por la ASC 985-20. Si los clientes solo acceden al software mediante un acuerdo de alojamiento y no tienen derecho contractual a tomar posesión de él y ejecutarlo por su cuenta, el proveedor está utilizando el software internamente para prestar un servicio. Los fundadores suelen suponer que «vendemos software» implica la ASC 985-20, lo que lleva a registrar como gasto un desarrollo que podría haberse capitalizado — o a políticas incoherentes cuando se añade una versión on-premise. Si está planificando o escalando una plataforma SaaS, nuestra guía de desarrollo de software SaaS aborda la parte de producto de estas mismas decisiones.
¿Cómo se tratan los costes de desarrollo de software según las IFRS (IAS 38)?
Según las NIIF (IFRS), la IAS 38 Activos intangibles divide todo proyecto interno en una fase de investigación, que siempre se registra como gasto, y una fase de desarrollo, que debe capitalizarse en cuanto la empresa pueda demostrar los seis criterios del párrafo 57. A diferencia de US GAAP, las IFRS aplican el mismo modelo tanto si el software se usa internamente como si se vende.
Los seis criterios de la IAS 38 exigen que la empresa demuestre:
- la viabilidad técnica de completar el software de modo que esté disponible para su uso o venta;
- su intención de completar el software y usarlo o venderlo;
- su capacidad para utilizar o vender el software;
- la forma en que el software generará probables beneficios económicos futuros, por ejemplo, la existencia de un mercado para él o su utilidad interna;
- la disponibilidad de los recursos técnicos, financieros y de otro tipo adecuados para completar el desarrollo y utilizar o vender el software;
- su capacidad para medir de forma fiable el desembolso atribuible al software durante su desarrollo.
Cuando se cumplen los seis, la capitalización es obligatoria, no opcional. Si una empresa no puede distinguir la fase de investigación de la fase de desarrollo, la IAS 38 trata todo el proyecto como investigación y lo registra como gasto. El software capitalizado se amortiza a lo largo de su vida útil y se somete a pruebas de deterioro según la IAS 36; el software que aún no está disponible para su uso debe someterse a la prueba al menos una vez al año. El modelo de revalorización solo se permite cuando existe un mercado activo, algo que en la práctica casi nunca ocurre con el software a medida.
En el caso del SaaS que una empresa compra en lugar de desarrollar, las IFRS difieren de la ASU 2018-15. A raíz de las decisiones de agenda del Comité de Interpretaciones de las IFRS de 2019 y 2021, los costes de configuración y personalización de un servicio en la nube que el cliente no controla suelen registrarse como gasto, salvo que generen un activo separado que el cliente controle, como código a medida.
US GAAP frente a IFRS de un vistazo
| Tema | US GAAP | IFRS (IAS 38) |
|---|---|---|
| Modelos | Dos: uso interno (ASC 350-40) y software vendido o licenciado (ASC 985-20) | Un único modelo para todos los intangibles generados internamente |
| Inicio de la capitalización | Financiación y finalización probable (350-40); viabilidad tecnológica (985-20) | Demostración de los seis criterios del párrafo 57 |
| Costes de investigación | Se registran como gasto | Se registran como gasto |
| ¿La capitalización es opcional? | No, es obligatoria una vez alcanzado el umbral | No, es obligatoria una vez cumplidos todos los criterios |
| Revalorización | No permitida | Permitida solo si existe un mercado activo; poco habitual en software |
| Deterioro | Enfoque de ASC 360-10 para el uso interno; prueba del valor neto realizable según 985-20 | IAS 36; prueba anual para los activos aún no en uso |
| Costes de implementación en la nube (cliente) | Se capitalizan según la ASU 2018-15 | Normalmente se registran como gasto, según las decisiones de agenda del IFRIC |
Los grupos que informan con ambos marcos — por ejemplo, una matriz europea con una filial estadounidense — deben registrar los costes con el nivel de detalle que exige el marco más estricto y obtener ambos resultados a partir de los mismos datos.
¿Cómo debe amortizarse el software capitalizado?
La amortización del software de uso interno comienza cuando el software está listo para el uso previsto y suele seguir el método lineal a lo largo de la vida útil estimada. Muchas empresas utilizan de tres a cinco años, pero se trata de una práctica habitual, no de una regla: el periodo debe reflejar cuánto tiempo aportará valor realmente el software antes de ser sustituido o reconstruido.
- Fecha de inicio — cuando el software, o un módulo utilizable por separado, está sustancialmente terminado y listo para su uso, aunque todavía no se haya desplegado a todos los usuarios.
- Método — lineal, salvo que otro patrón refleje mejor cómo se consumen los beneficios; el software de ASC 985-20 utiliza el mayor entre el importe basado en ingresos y el importe lineal.
- Vida útil — tenga en cuenta su historial de versiones, el ritmo de cambio de la tecnología subyacente y cualquier plan para sustituir la plataforma.
- Revisiones — revise las vidas útiles al menos una vez al año y ajústelas de forma prospectiva si cambian las expectativas.
- Indicios de deterioro — el abandono del proyecto, un cambio importante en el uso del software, sobrecostes muy superiores a lo previsto o la decisión de sustituirlo anticipadamente.
- Proyectos abandonados — cuando la finalización deja de ser probable, deje de capitalizar y reduzca el valor del activo; no lo siga manteniendo en libros.
¿Cómo tributan los costes de desarrollo de software en 2026 (sección 174A)?
En el impuesto federal de EE. UU., la One Big Beautiful Bill Act de julio de 2025 añadió la sección 174A, que permite a las empresas deducir los gastos de investigación y experimentación nacionales — incluido expresamente el desarrollo de software — en el ejercicio en que se incurren, para los ejercicios fiscales que comiencen después del 31 de diciembre de 2024. La investigación realizada fuera de Estados Unidos debe seguir capitalizándose y amortizándose en 15 años según la sección 174.
La norma sobre el extranjero afecta a cualquiera que desarrolle software con un equipo offshore o nearshore. El desarrollo realizado en EE. UU. ahora es deducible de inmediato, mientras que el mismo trabajo hecho en el extranjero se reparte en 15 años. Esa diferencia debería formar parte de cualquier comparación de coste total entre el desarrollo interno, onshore y offshore.
- Las pequeñas empresas con ingresos brutos anuales medios de $31 millones o menos pueden aplicar la deducción inmediata de los gastos nacionales con carácter retroactivo a los ejercicios fiscales que comiencen después del 31 de diciembre de 2021, modificando sus declaraciones de 2022–2024.
- Los demás contribuyentes pueden deducir íntegramente en 2025 el saldo nacional pendiente de amortizar de la sección 174 de 2022–2024, o repartirlo a partes iguales entre 2025 y 2026.
- Procedimiento — el IRS estableció las opciones y los cambios de método contable en la Rev. Proc. 2025-28.
- Contabilidad frente a fiscalidad — la información fiscal y la financiera ya no avanzan a la par: un activo capitalizado en libros con una deducción fiscal inmediata genera un pasivo por impuesto diferido que hay que controlar.
La sección 174A regula la deducción; el crédito por investigación de la sección 41 es un beneficio independiente con su propia prueba de cuatro requisitos. Nuestra guía sobre el crédito fiscal por I+D para el desarrollo de software explica en detalle los requisitos de elegibilidad y la documentación.
¿Cómo se controlan los costes capitalizables en un equipo ágil?
Para controlar los costes capitalizables en un equipo ágil, etiquete el trabajo a nivel de épica y de ticket como nueva funcionalidad, mantenimiento o investigación, registre el tiempo por persona y épica, y exija a los proveedores externos que facturen con la misma estructura. Así, la capitalización se convierte en un informe mensual en lugar de una reconstrucción al cierre del trimestre.
- Redacte una política de capitalización. Defina qué actividades se capitalizan, el umbral que aplica (basado en fases o ASU 2025-06), un tamaño mínimo de proyecto, las vidas útiles por defecto y quién aprueba las excepciones.
- Etiquete épicas y tickets. Cada épica recibe una categoría — nueva funcionalidad, mejora, mantenimiento, investigación o infraestructura — y los tickets la heredan. Los product owners asignan la etiqueta; finanzas la revisa.
- Registre el tiempo por persona y épica. Basta con una asignación semanal sencilla del tiempo por épica; no se necesitan partes de horas al minuto, pero las estimaciones deben ser razonables y coherentes.
- Fije reglas para los contratistas. Pida a los proveedores de desarrollo que facturen por épica o funcionalidad con las horas por rol, para que los costes externos puedan clasificarse igual que la nómina.
- Cierre cada mes. Haga el corte a final de mes, calcule los costes capitalizables de nómina y de proveedores, registre los asientos y ponga en servicio los módulos terminados para que la amortización empiece a tiempo.
- Conserve la evidencia. Guarde las aprobaciones de financiación, las hojas de ruta, las notas de versión y el razonamiento de los juicios sobre la finalización probable; los auditores los pedirán.
- Revise cada trimestre. Compruebe la calidad del etiquetado, vuelva a evaluar las vidas útiles y busque proyectos abandonados o estancados que requieran deterioro.
¿Cuáles son los errores más comunes en la contabilidad del desarrollo de software?
Los errores más comunes en la contabilidad del desarrollo de software son capitalizar trabajo que todavía es investigación, capitalizar el mantenimiento, elegir la norma equivocada para el SaaS y no documentar los juicios. Cada uno suele salir a la luz en la primera auditoría seria, cuando corregirlo resulta más caro.
- Capitalizar investigación y prototipos — los spikes de prueba de concepto y los experimentos previos a la aprobación de la financiación deben registrarse como gasto.
- Capitalizar el mantenimiento — la corrección de errores, la refactorización y los pequeños ajustes de la interfaz no añaden funcionalidad, aunque ocupen un sprint entero.
- Tratar el SaaS como ASC 985-20 — los productos alojados en los que el cliente no tiene derecho a tomar posesión del software son software de uso interno.
- Cargar gastos generales en el activo — el alquiler, RR. HH. y la dirección general se registran como gasto en el software de uso interno.
- Sin evidencia de la finalización probable — sin aprobaciones de financiación ni hojas de ruta, los auditores pueden retrasar el inicio de la capitalización.
- Olvidar el deterioro — un módulo abandonado que sigue en el balance sobrevalora los activos.
- Tratar el desarrollo en el extranjero como nacional a efectos fiscales — el trabajo realizado fuera de EE. UU. se amortiza en 15 años y no se deduce según la sección 174A.
Ejemplo práctico: un desarrollo de $600k, dos resultados contables
El mismo desarrollo de $600,000 puede generar un activo de $480,000 o de $40,000 según el modelo de US GAAP que se aplique. El ejemplo siguiente es hipotético, utiliza cifras redondas y supone que el proyecto cumple las condiciones de financiación y finalización probable tras la fase de descubrimiento; ilustra la mecánica, no el caso de ninguna empresa real.
El resultado A trata el producto como software de uso interno o plataforma SaaS según ASC 350-40. El resultado B lo trata como software licenciado que se vende para que los clientes lo instalen, según ASC 985-20, con la viabilidad tecnológica establecida mediante un modelo operativo al final de las pruebas.
| Actividad | Coste | A: ASC 350-40 (uso interno / SaaS) | B: ASC 985-20 (producto licenciado) |
|---|---|---|---|
| Descubrimiento, viabilidad y selección de proveedor | $45,000 | Gasto $45,000 | Gasto $45,000 |
| Diseño y arquitectura de la solución elegida | $55,000 | Capitalizar $55,000 | Gasto $55,000 |
| Programación e integración | $330,000 | Capitalizar $330,000 | Gasto $330,000 |
| Pruebas | $70,000 | Capitalizar $70,000 | Gasto $30,000; capitalizar $40,000 tras el modelo operativo |
| Gestión de proyecto directamente vinculada al desarrollo | $25,000 | Capitalizar $25,000 | Gasto $25,000 |
| Conversión de datos | $30,000 | Gasto $30,000 | Gasto $30,000 |
| Formación | $20,000 | Gasto $20,000 | Gasto $20,000 |
| Gastos generales y de administración | $25,000 | Gasto $25,000 | Gasto $25,000 |
| Total | $600,000 | Capitalizado $480,000 / gasto $120,000 | Capitalizado $40,000 / gasto $560,000 |
En el resultado A, amortizar $480,000 de forma lineal en cuatro años añade $120,000 de amortización al año. Si el software entra en producción a principios de año, el cargo en la cuenta de resultados del primer año es de $240,000 ($120,000 de gasto más $120,000 de amortización) en lugar de $600,000. En el resultado B, casi todo el desarrollo reduce el beneficio operativo en el año en que se gasta.
La ASU 2025-06 añade una tercera posibilidad al resultado A. Si $150,000 de la programación corresponden a una funcionalidad novedosa cuya incertidumbre solo se resolvió al final del desarrollo, ese importe se registra como gasto con las nuevas reglas. El activo capitalizado baja a $330,000 y la amortización anual en cuatro años, a $82,500. La aritmética es sencilla; lo que hay que documentar es el juicio sobre la incertidumbre.
Preguntas frecuentes
¿Qué son los costes de desarrollo de software?
Los costes de desarrollo de software son los costes directos e indirectos de crear software: salarios, cotizaciones sociales y prestaciones de ingenieros, QA, diseñadores y product managers, honorarios pagados a contratistas de desarrollo, licencias y herramientas, entornos en la nube utilizados durante el desarrollo y migración de datos. En contabilidad, la pregunta clave es cuáles de estos costes se convierten en un activo del balance y cuáles se registran como gasto en el momento en que se incurren.
¿Los costes de desarrollo de software se capitalizan o se registran como gasto?
Ambas cosas, según la actividad y la norma. La investigación, la planificación, la conversión de datos, la formación, el mantenimiento y los gastos generales se registran como gasto. Según US GAAP ASC 350-40, el diseño, la codificación y las pruebas del software de uso interno se capitalizan una vez alcanzado el umbral de capitalización y hasta que el software esté listo para su uso. El software que se vende o se licencia en virtud de ASC 985-20 solo se capitaliza una vez alcanzada la viabilidad tecnológica. Según IFRS IAS 38, los costes de desarrollo se capitalizan cuando se cumplen los seis criterios del párrafo 57.
¿Qué es ASU 2025-06 y cuándo entra en vigor?
ASU 2025-06, publicada por el FASB el 18 de septiembre de 2025, modifica ASC 350-40 para el software de uso interno. Elimina el modelo por fases del proyecto y exige que la capitalización comience cuando la dirección haya autorizado el proyecto y se haya comprometido a financiarlo, y sea probable que el proyecto se complete y el software se utilice según lo previsto, teniendo en cuenta cualquier incertidumbre significativa del desarrollo. Entra en vigor para los ejercicios anuales que comiencen después del 15 de diciembre de 2027, y se permite su adopción anticipada.
¿En qué se diferencia la contabilidad de los costes de desarrollo de software en las empresas SaaS?
Un proveedor SaaS cuyos clientes solo acceden al software y no pueden tomar posesión de él suele contabilizar su plataforma como software de uso interno según ASC 350-40, y no según ASC 985-20 para software vendido o licenciado. Esto significa que los costes de diseño, codificación y pruebas pueden capitalizarse una vez alcanzado el umbral de ASC 350-40, lo que a menudo da lugar a un activo capitalizado mayor que en el caso del software licenciado.
¿Durante cuánto tiempo debe amortizarse el software capitalizado?
El software capitalizado se amortiza a lo largo de su vida útil estimada, a partir del momento en que está listo para el uso previsto. El método lineal es el más habitual para el software de uso interno, y muchas empresas utilizan de tres a cinco años, aunque el periodo debe reflejar durante cuánto tiempo se espera que el software aporte beneficios. El software vendido o licenciado según ASC 985-20 utiliza el mayor entre un ratio basado en ingresos y la amortización lineal.
¿Pueden deducirse de inmediato en el impuesto de EE. UU. los costes de desarrollo de software realizado en el extranjero?
No. En virtud de la One Big Beautiful Bill Act de julio de 2025, la nueva Section 174A permite a los contribuyentes de EE. UU. deducir los gastos nacionales de investigación y experimentación, incluido el desarrollo de software, en el ejercicio en que se incurren, para los ejercicios fiscales que comiencen después del 31 de diciembre de 2024. La investigación realizada fuera de Estados Unidos sigue teniendo que capitalizarse y amortizarse en 15 años según la Section 174.
¿Tratan IFRS y US GAAP de la misma forma la contabilidad del desarrollo de software?
No. IFRS IAS 38 aplica un único modelo a todo el desarrollo: la investigación se registra como gasto y el desarrollo debe capitalizarse una vez que se cumplen seis criterios. US GAAP divide el software en software de uso interno según ASC 350-40 y software vendido o licenciado según ASC 985-20, cada uno con su propio desencadenante de capitalización y sus propias reglas de amortización. Por tanto, un mismo proyecto puede dar lugar a valores de activo distintos en ambos marcos.
Publicado el 26 de octubre de 2026. Fuentes: texto completo de FASB ASU 2025-06 en PwC Viewpoint (en inglés); Deloitte DART Heads Up (2025) (en inglés); comentarios de AICPA & CIMA, RSM US y Grant Thornton sobre ASU 2025-06; IFRS Foundation, IAS 38 Intangible Assets; Baker Newman Noyes y Kaufman Rossin sobre la Section 174A y Rev. Proc. 2025-28; The Tax Adviser (AICPA) sobre la definición de los costes de desarrollo de software. Este artículo es información general y no constituye asesoramiento contable, de auditoría ni fiscal.