La deducción por investigación y desarrollo (I+D) e innovación tecnológica (IT) del Impuesto sobre Sociedades es uno de los incentivos fiscales más potentes para las empresas que invierten en tecnología. Permite deducir de la cuota entre el 12 % y el 25 % de los gastos elegibles, con porcentajes superiores en determinados casos. Sin embargo, cuando la inversión se concentra en desarrollo de software o inteligencia artificial, aplicarla correctamente es más difícil de lo que parece.

El motivo es que el software forma parte de casi cualquier proyecto empresarial. Una plataforma SaaS, un motor de recomendación o un asistente basado en IA pueden suponer meses de trabajo de un equipo cualificado y, aun así, no constituir I+D a efectos fiscales. A la inversa, una mejora concreta en un algoritmo puede calificar aunque el producto final parezca sencillo.

La clave no está en el lenguaje de programación, en el tamaño del equipo ni en que el producto sea nuevo para el mercado. Está en si el proyecto ha tenido que resolver una incertidumbre tecnológica que un profesional competente no sabría superar con el conocimiento y las herramientas disponibles. Esa es la frontera entre la novedad tecnológica y el desarrollo rutinario.

En este artículo explicamos qué dice el artículo 35 de la Ley del Impuesto sobre Sociedades sobre el software, cómo aplicar los criterios internacionales a proyectos de software e inteligencia artificial, cuándo puede encajar la innovación tecnológica y qué evidencias conviene generar durante el desarrollo. Nos centramos en la normativa de territorio común.

Qué dice el artículo 35 LIS sobre el software

El artículo 35 de la Ley 27/2014, del Impuesto sobre Sociedades, incluye una mención expresa al software dentro del concepto de investigación y desarrollo:

«También se considerará actividad de investigación y desarrollo la creación, combinación y configuración de software avanzado, mediante nuevos teoremas y algoritmos o sistemas operativos, lenguajes, interfaces y aplicaciones destinados a la elaboración de productos, procesos o servicios nuevos o mejorados sustancialmente.»

La misma norma asimila a este concepto el software destinado a facilitar el acceso de las personas con discapacidad a los servicios de la sociedad de la información. Y excluye de forma expresa las actividades habituales o rutinarias relacionadas con el mantenimiento del software o sus actualizaciones menores.

De esta redacción se desprenden dos ideas prácticas. La primera: el software puede ser I+D tanto si es el producto final como si forma parte de un producto, proceso o servicio. La segunda: lo que se califica es el avance tecnológico, no la actividad de programar. La redacción actual es más amplia que la del antiguo texto refundido, que exigía un progreso científico o tecnológico significativo mediante nuevos teoremas, algoritmos, sistemas operativos o lenguajes, pero mantiene la exigencia de que el resultado sea nuevo o sustancialmente mejorado.

Novedad tecnológica frente a desarrollo rutinario

Para delimitar qué es I+D, la referencia internacional es el Manual de Frascati de la OCDE. Según este manual, una actividad de I+D debe ser novedosa, creativa, incierta en su resultado, sistemática y transferible o reproducible. Es un manual estadístico y no una norma fiscal, pero sus criterios son una referencia habitual en la calificación técnica de proyectos.

Aplicado al software, el manual indica que un proyecto puede considerarse I+D cuando su finalización depende de un avance científico o tecnológico y su objetivo es resolver de forma sistemática una incertidumbre. Y añade un matiz importante: utilizar software para una aplicación o una finalidad nueva no constituye, por sí solo, un avance.

Una pregunta útil para revisar cada línea de trabajo es: ¿sabíamos cómo hacerlo al empezar? Si el equipo conocía la solución y el reto era ejecutarla con calidad y en plazo, estamos ante ingeniería de software, por valiosa que sea para el negocio. Si fue necesario formular hipótesis, probar alternativas y asumir que alguna podía fallar, el trabajo merece un análisis específico.

Ejemplos orientativos según el Manual de Frascati

La depuración de errores solo forma parte del I+D cuando se realiza antes de que termine el desarrollo experimental. Una vez el sistema está en producción, corregir incidencias es mantenimiento.

Si no es I+D, ¿puede ser innovación tecnológica?

Cuando el proyecto no alcanza el umbral de I+D, puede analizarse como innovación tecnológica (IT), que da derecho a una deducción del 12 %. La IT exige obtener productos o procesos nuevos o con mejoras sustanciales desde el punto de vista tecnológico. La Dirección General de Tributos lo ha aplicado, por ejemplo, a la programación de videojuegos: puede ser IT si da lugar a un producto nuevo o a una mejora sustancial de uno existente, pero nunca las actualizaciones menores o rutinarias (consulta vinculante V3312-17).

Hay una diferencia clave con el I+D. En innovación tecnológica solo se computan los gastos que encajan en los conceptos tasados del artículo 35.2.b) LIS: diagnóstico tecnológico, diseño industrial e ingeniería de procesos, adquisición de tecnología avanzada y determinadas certificaciones. Como explicamos en el artículo sobre el paso del prototipo a la producción, calificar un proyecto como IT no permite aplicar el 12 % sobre todo su presupuesto.

En proyectos de software, este punto ha generado una notable litigiosidad. En 2022 la Audiencia Nacional restringió la inclusión de los gastos de desarrollo de software en el concepto de ingeniería de procesos. En 2024 el Tribunal Supremo anuló esas sentencias y confirmó que, para ejercicios regidos por el antiguo texto refundido, el informe motivado del Ministerio vincula a la Administración tanto en la calificación como en los gastos. Para los ejercicios sujetos a la ley actual, la cuantificación de la base puede seguir siendo objeto de revisión.

Por eso, en proyectos de software con importes relevantes, solicitar un informe motivado vinculante (IMV) al Ministerio de Ciencia, Innovación y Universidades aporta una seguridad jurídica difícil de conseguir por otra vía.

Proyectos de inteligencia artificial: dónde está la frontera

La inteligencia artificial no es I+D por definición. Muchas empresas incorporan hoy modelos de lenguaje, visión artificial o analítica predictiva en sus productos, y la mayoría de esas integraciones son desarrollo de software convencional. Los criterios son los mismos que para cualquier otro proyecto: novedad, incertidumbre y método.

Lo que normalmente no supera el umbral

• Conectar un modelo comercial a través de su API para crear un chatbot o un asistente, aunque las instrucciones (prompts) se trabajen con detalle.
• Entrenar modelos con librerías y procedimientos estándar sobre datos propios cuando el resultado es previsible.
• Construir paneles o automatizaciones que consumen predicciones de servicios existentes.
• Ajustar hiperparámetros siguiendo prácticas documentadas, sin un objetivo técnico que vaya más allá del estado del arte.

Lo que puede justificar un análisis como I+D o IT

• Diseñar arquitecturas, métodos de entrenamiento o técnicas de generación de datos sintéticos para alcanzar prestaciones que las soluciones disponibles no logran en ese ámbito, por ejemplo con muy pocos datos etiquetados.
• Ejecutar modelos en dispositivos con restricciones severas de memoria, energía o latencia cuando las técnicas conocidas no son suficientes.
• Desarrollar mecanismos nuevos para verificar, explicar o acotar las respuestas de un modelo cuando el caso de uso exige una fiabilidad que hoy no se alcanza.
• Integrar modelos con sistemas físicos o industriales en condiciones que los métodos estándar no resuelven.

En todos los casos, la incertidumbre debe ser tecnológica. No saber si los clientes adoptarán la herramienta o si el proyecto será rentable es una incertidumbre de negocio, no de I+D.

Qué evidencias generar durante el desarrollo

Los equipos de software tienen una ventaja: buena parte de la evidencia ya se genera en sus herramientas de trabajo. El problema es que rara vez se organiza pensando en una revisión técnica o en una comprobación de la AEAT. Recomendamos preparar desde el inicio:

• Estado del arte y objetivo técnico medible. Qué soluciones existían, qué resultados alcanzaban y qué valor se quería lograr: precisión, latencia, consumo o escalabilidad.
• Hipótesis y registro de experimentos. Alternativas probadas, configuraciones, resultados y versiones descartadas. En proyectos de IA, una herramienta de seguimiento de experimentos facilita mucho este trabajo.
• Trazabilidad en el repositorio. Ramas, commits e incidencias vinculados al proyecto, y registros de decisiones de arquitectura que expliquen por qué se eligió cada enfoque.
• Imputación de horas por proyecto y tarea. Separar el desarrollo experimental del evolutivo, del soporte y del mantenimiento.
• Costes individualizados. Infraestructura en la nube, licencias, subcontrataciones y colaboraciones externas asignadas al proyecto, por ejemplo mediante etiquetas de coste.
• Hitos de cierre. El momento en que la solución se valida y pasa a producción, a partir del cual el trabajo deja de ser experimental.

Ampliamos estas prácticas en nuestra guía para documentar proyectos de I+D+i y en el artículo sobre los modelos de innovación ágil Triple-A, que explica cómo encajar sprints y entregas continuas con la trazabilidad que exige la deducción.

Ejemplo práctico: un año de un equipo de desarrollo

Supongamos una empresa con un equipo de seis personas que destina 420.000 euros de costes de personal a su plataforma y 20.000 euros a computación en la nube para entrenar modelos. Tras la revisión técnica se identifica un proyecto de I+D: un nuevo método de detección de anomalías en datos de sensores capaz de ejecutarse en el propio dispositivo con una latencia que las técnicas disponibles no alcanzaban.

Al tipo general del 25 %, la deducción generada sería de 37.500 euros. Es un ejemplo ilustrativo, no la calificación de un caso real: se supone que el gasto en I+D no supera la media de los dos ejercicios anteriores (sobre el exceso se aplicaría el 42 %), que no hay subvenciones que minoren la base y que los costes están correctamente individualizados. Si alguna persona del equipo es investigador cualificado adscrito en exclusiva a I+D, cabe además una deducción adicional del 17 % sobre sus gastos de personal.

Para ese mismo personal también puede valorarse la bonificación del 40 % en las cotizaciones a la Seguridad Social por personal investigador. Con carácter general, ambos incentivos no se acumulan sobre la misma persona, salvo excepciones como las pymes con sello de pyme innovadora, por lo que conviene analizar qué opción compensa antes del cierre.

Errores frecuentes en proyectos de software

• Presentar toda la plataforma como I+D, sin separar paquetes de trabajo.
• Confundir novedad para el mercado con novedad tecnológica: ser los primeros en ofrecer un servicio no implica haber resuelto un reto técnico.
• Reconstruir la justificación a final de año, cuando los experimentos fallidos ya no están documentados.
• Aplicar el 12 % de innovación tecnológica sobre todo el presupuesto sin comprobar los conceptos de gasto admitidos.
• Mezclar en una misma imputación de horas el desarrollo experimental, el evolutivo y el mantenimiento.

Revisa tus proyectos de software antes del cierre

El último trimestre es un buen momento para reunir al CTO y al responsable financiero y repasar qué proyectos han tenido una incertidumbre tecnológica real, qué evidencias existen y qué falta por documentar. Esa revisión también sirve para planificar los proyectos de 2027 de forma que la trazabilidad se genere desde el primer sprint.

En Matical combinamos la consultoría de incentivos con experiencia técnica en desarrollo de software e inteligencia artificial para analizar el encaje de cada proyecto y preparar la documentación de sus deducciones por I+D+i. Si tu empresa desarrolla software o soluciones de IA, contacta con nuestro equipo y revisaremos contigo qué parte de esa inversión puede generar incentivos.