La amortización del software no es un detalle contable menor: cambia cómo se presenta el negocio, cómo se reparte el gasto entre ejercicios y cuánto impacto fiscal acaba teniendo una inversión tecnológica. En la práctica, la diferencia entre llevar una aplicación a gasto o activarla como inmovilizado intangible suele depender de dos preguntas muy concretas: si la empresa controla el activo y cuánto tiempo va a generar beneficios. Aquí explico ese criterio con enfoque práctico, la forma correcta de calcular la cuota y los errores que más se repiten con licencias, desarrollos y mantenimiento.
Lo esencial que conviene tener claro antes de contabilizar software
- El software puede activarse como inmovilizado intangible si la empresa lo controla y genera beneficios durante varios ejercicios.
- La amortización debe reflejar su vida útil real; si no puede estimarse con fiabilidad, la referencia general son 10 años.
- El mantenimiento ordinario suele ir a gasto, no a activo; las mejoras relevantes exigen más análisis.
- En fiscalidad, contabilidad e impuestos no siempre coinciden: en España hay reglas distintas según seas sociedad o autónomo.
- Las suscripciones SaaS normalmente no se amortizan porque no existe un activo controlado por la empresa.
Qué se amortiza realmente cuando hablamos de software
Yo separo siempre tres cosas: el activo, el servicio y el gasto de soporte. Esa distinción evita muchos errores. Si la empresa compra o desarrolla un programa que va a usar durante más de un ejercicio y sobre el que tiene control, estamos ante un inmovilizado intangible que debe amortizarse de forma sistemática. Si, en cambio, solo paga por usar una plataforma en la nube, normalmente hay un servicio recurrente y no un activo amortizable.
En el PGC, los programas de ordenador que cumplen los criterios de reconocimiento se incorporan al activo, tanto si se adquieren a terceros como si los desarrolla la propia empresa. Lo que no puede capitalizarse es el mantenimiento ordinario de la aplicación, porque no crea por sí mismo un beneficio económico nuevo ni alarga de forma clara la vida del activo.
| Situación | Tratamiento habitual | Comentario práctico |
|---|---|---|
| Licencia perpetua comprada | Activo intangible amortizable | Lo normal es activarla si la empresa controla el derecho y su uso no se agota en el ejercicio. |
| Desarrollo propio | Puede activarse si cumple requisitos | Los costes directamente atribuibles al desarrollo pueden capitalizarse; hay que separar bien las fases del proyecto. |
| Suscripción SaaS | Gasto del período | No hay un software que la empresa posea; hay derecho de uso temporal y un servicio prestado por el proveedor. |
| Mantenimiento y soporte | Gasto | Suele ser el error más frecuente: no se amortiza porque no crea un activo nuevo. |
| Actualización mayor o nueva versión | Depende del efecto económico | Si solo corrige fallos, normalmente va a gasto; si amplía funciones de forma relevante, conviene analizar si se activa. |
La lectura práctica es simple: no todo lo que rodea al software se amortiza, solo aquello que reúne la condición de activo y va a generar rendimiento durante un tiempo medible. Con esa base clara, el siguiente paso es decidir durante cuántos años se reparte su coste y con qué método.
Cómo fijar la vida útil y el método de amortización
La regla contable es que los intangibles con vida útil definida se amortizan durante el periodo en el que se espera que aporten beneficios económicos. Si no puede estimarse con fiabilidad, la referencia general es un plazo de 10 años. En software, esto obliga a pensar con criterio, no a aplicar una cifra por inercia.
En la práctica, la vida útil del software suele depender de factores muy concretos:
- la velocidad de obsolescencia tecnológica del sector;
- si el proveedor controla las actualizaciones o el código queda en manos de la empresa;
- si el programa está muy vinculado a procesos internos estables o a una actividad que cambia rápido;
- si existe una fecha contractual de fin de uso o de renovación;
- si el software necesita sustitución frecuente por cambios normativos, operativos o de seguridad;
- la experiencia histórica de la empresa con herramientas similares.
Yo suelo ver vidas útiles de 3 a 5 años en aplicaciones estándar de negocio, pero esa horquilla no es una ley. En soluciones muy estables y muy integradas, la vida útil puede ser mayor; en software muy dependiente de cambios rápidos, puede ser menor. Lo importante es que el criterio quede documentado y sea coherente con el uso real.
El método que más se utiliza es el lineal: se reparte el coste de forma uniforme durante la vida útil. Es el más fácil de defender, el más transparente y el que mejor encaja cuando no hay un patrón de consumo claramente distinto por ejercicios. Si el programa empieza a generar valor desde una fecha concreta, la amortización debe arrancar cuando esté en condiciones de funcionamiento, no cuando se firma el contrato.
Ejemplo simple: si una aplicación activable cuesta 30.000 euros y la empresa estima una vida útil de 5 años, la cuota anual será de 6.000 euros. Si entra en funcionamiento a mitad de ejercicio, el primer año solo se amortiza la parte proporcional. Esa prorrata es importante, porque el gasto debe reflejar el uso real del activo y no una fecha administrativa cualquiera.
Con la vida útil ya encajada, la siguiente pregunta es clave: qué se permite deducir contablemente y qué admite la fiscalidad española sin ajustes innecesarios.
Qué cambia entre contabilidad y fiscalidad en España
Aquí es donde muchas empresas se complican sin necesidad. La contabilidad busca representar la realidad económica; la fiscalidad, en cambio, aplica sus propios límites. Las dos pueden ir de la mano, pero no siempre coinciden de forma automática.
En el ámbito del Impuesto sobre Sociedades, el inmovilizado intangible se amortiza atendiendo a su vida útil. Cuando esa vida útil no puede estimarse de manera fiable, la normativa fiscal admite un límite anual máximo del 5% de su importe, mientras que contablemente la referencia general es el 10% anual. En otras palabras: si no puedes justificar bien la vida útil, contabilidad e impuestos pueden separarse y obligarte a llevar diferencias temporarias.
Si trabajas como autónomo en estimación directa simplificada, la tabla de amortización de la AEAT recoge para los sistemas y programas informáticos un coeficiente lineal máximo del 26% y un período máximo de 10 años. Esa tabla no sustituye al criterio contable, pero sí condiciona la deducibilidad fiscal en ese régimen.
| Ámbito | Criterio principal | Consecuencia |
|---|---|---|
| Contabilidad | Amortización sistemática según vida útil | Hay que reflejar el consumo económico del software. |
| Impuesto sobre Sociedades | Vida útil fiable o límite fiscal cuando no lo sea | Puede haber diferencias con el resultado contable si la estimación no está bien soportada. |
| Autónomos en estimación directa simplificada | Tabla de amortización específica | Para programas informáticos, la referencia fiscal es más concreta y puede ser más rápida que la contable. |
La conclusión práctica es muy útil: no conviene improvisar. Si la empresa usa un criterio contable sólido, bien documentado y coherente con la fiscalidad aplicable, la amortización deja de ser una fuente de ajustes cada cierre. Y una vez resuelto eso, ya sí merece la pena mirar cómo se contabiliza de verdad en el día a día.
Cómo lo contabilizo en la práctica sin perderme en el asiento
Cuando reviso cierres, casi siempre separo el problema en dos momentos: alta del activo y amortización periódica. En el alta, la empresa activa el coste que realmente forma parte del software; después, va reconociendo la depreciación año a año con cargo a la cuenta de pérdidas y ganancias y abono a la amortización acumulada.
Un caso típico: una empresa compra una licencia de software por 18.000 euros y paga 4.000 euros adicionales por implantación técnica necesaria para dejarla operativa. Si esos costes son directamente atribuibles y forman parte del activo, el importe activable puede ser 22.000 euros. Con una vida útil de 4 años, la cuota anual sería de 5.500 euros. Si el software empieza a usarse el 1 de julio, el primer ejercicio reflejaría solo media cuota, 2.750 euros.
En un desarrollo interno, la lógica es parecida pero el control documental importa más. Hay que distinguir entre:
- fases iniciales de estudio o prueba, que suelen ir a gasto si no cumplen requisitos de activación;
- costes de desarrollo que sí pueden activarse cuando el proyecto es viable y la empresa demuestra que generará beneficios futuros;
- mantenimiento ordinario, soporte o corrección menor, que normalmente se lleva a gasto.
Yo siempre recomiendo revisar también el valor residual. En software, lo normal es presumirlo nulo, salvo que exista un compromiso de compra al final de la vida útil o un mercado activo muy claro. En la práctica, eso significa que casi toda la base amortizable suele ser el coste activado menos, en su caso, los importes que no deban formar parte del activo.
Si el cierre se hace con orden, este ciclo se vuelve bastante estable: alta correcta, vida útil defendible, amortización lineal y revisión de deterioro cuando existan indicios. Y precisamente ahí aparecen los fallos más comunes, que conviene prevenir antes de que impacten en el balance.
Los errores que más distorsionan el cierre
El error más repetido es tratar una suscripción SaaS como si fuera una compra de software. No lo es. Si la empresa paga una cuota mensual para usar una plataforma, lo normal es que esté contratando un servicio y no adquiriendo un activo controlable. El tratamiento contable cambia por completo.
También veo con frecuencia estos fallos:
- capitalizar el mantenimiento ordinario como si ampliara la vida útil del programa;
- amortizar antes de que el software esté realmente en condiciones de funcionamiento;
- usar una vida útil “de plantilla” sin justificarla con el uso real;
- olvidar que una mejora importante no siempre es mantenimiento y puede requerir análisis propio;
- no revisar indicios de deterioro cuando una aplicación queda obsoleta por cambios regulatorios o por migraciones tecnológicas.
El problema de fondo no es solo técnico: un criterio mal aplicado altera el resultado, distorsiona márgenes y puede complicar la revisión fiscal. Por eso yo prefiero una política interna simple pero bien escrita, antes que una solución improvisada y difícil de defender. Con ese terreno despejado, queda la parte más útil para cerrar bien el ejercicio: qué revisar justo antes de contabilizar la cuota final.
Lo que yo revisaría antes de cerrar el ejercicio
Si tuviera que dejar una regla corta, sería esta: antes de amortizar, comprueba si el gasto pertenece al activo, si la empresa controla el derecho y si la vida útil elegida refleja el uso real. Parece básico, pero ahí se gana o se pierde la calidad del cierre.
Mi checklist práctico sería este:
- ¿El programa está ya en uso o sigue en fase de implantación?
- ¿Existe un derecho controlado por la empresa o solo una suscripción temporal?
- ¿La vida útil está documentada con criterios razonables?
- ¿Mantenimiento, soporte y mejoras están separados con claridad?
- ¿Hay indicios de deterioro por obsolescencia, sustitución o pérdida de valor?
- ¿La parte fiscal encaja con el tratamiento contable o requiere ajuste?
Cuando estas seis preguntas están bien resueltas, la amortización deja de ser una zona gris y pasa a ser una herramienta útil para reflejar mejor la realidad del negocio. Y en software, esa precisión importa más de lo que parece: no solo ordena las cuentas, también ayuda a decidir con más criterio cuándo conviene comprar, desarrollar o simplemente contratar un servicio.
