¿Añadir accesibilidad a una aplicación convierte su desarrollo en I+D? No por sí solo. La ley contempla una vía específica para software destinado a facilitar a personas con discapacidad el acceso a servicios de la sociedad de la información, cuando se realiza sin fin de lucro. Hay que comprobar esa finalidad y esa condición, además del trabajo ejecutado.
La regla merece estudiarse antes de presupuestar el proyecto. No equivale a una deducción automática por mejorar el contraste, permitir el teclado o adaptar una web que se explota comercialmente.
La ley contempla un supuesto concreto de software accesible
El artículo 35.1 de la Ley del Impuesto sobre Sociedades asimila a I+D el software destinado a facilitar a las personas con discapacidad el acceso a servicios de la sociedad de la información, cuando se realice sin fin de lucro. La AEAT recoge ese supuesto al explicar las actividades de investigación y desarrollo.
Empieza por describir quién necesita el software y qué servicio podrá utilizar gracias a él. Una memoria que solo promete «más accesibilidad» deja sin responder cuál es el destino del desarrollo. Explica la barrera que pretende resolver y cómo funcionará la solución para sus usuarios.
Ese objeto debe ser real. No se obtiene cambiando el nombre comercial de una aplicación ya presupuestada ni añadiendo al final una referencia genérica a la discapacidad.
Sin fin de lucro no se comprueba con una descarga gratuita
Que el usuario no pague en una pantalla no demuestra, por sí solo, que el desarrollo se realice sin fin de lucro. Tampoco la forma jurídica de quien lo presenta resuelve automáticamente el análisis. Hay que revisar el proyecto y su organización efectiva, sin sustituir la condición legal por una etiqueta.
Describe quién encarga el trabajo, quién lo financia, quién conservará el software y cómo se utilizará. Si hay explotación comercial, servicios asociados o cobros previstos, ponlos sobre la mesa. No ocultes esos hechos para intentar encajar en la vía específica.
Este artículo no fija un criterio universal para resolver todas las combinaciones de financiación y explotación. Señala la condición que debe verificarse antes de calcular el incentivo. Si no se puede sostener su cumplimiento, no se da por satisfecha porque el desarrollo tenga utilidad social.
| Pregunta | Qué debe aclarar | Qué no basta |
|---|---|---|
| ¿Qué acceso facilita? | Servicio, usuarios y barrera que aborda | La palabra accesible en el título |
| ¿Se realiza sin fin de lucro? | Finalidad y funcionamiento real del proyecto | Que una descarga sea gratuita |
| ¿Hay otra vía de software avanzado? | Si cumple su definición técnica propia | Ser nuevo para el cliente |
La vía de accesibilidad y la de software avanzado no son intercambiables
La misma norma incluye la creación, combinación y configuración de software avanzado mediante nuevos teoremas y algoritmos, o mediante sistemas operativos, lenguajes, interfaces y aplicaciones destinados a productos, procesos o servicios nuevos o mejorados sustancialmente. Es otra referencia que exige analizar sus propios elementos.
No uses la accesibilidad para dar por probado ese avance técnico. Y si no se cumple la condición del supuesto específico, tampoco concluyas que todo desarrollo queda excluido sin estudiar lo que realmente se ha hecho. La pregunta cambia: habrá que examinar si satisface otra definición legal aplicable.
Las actividades habituales o rutinarias sobre mantenimiento del software y sus actualizaciones menores no se incluyen como I+D en este apartado. La revisión debe separar ese trabajo de un desarrollo que se pretende calificar por sus características propias.
Ejemplo ilustrativo: una mejora comercial y un proyecto de acceso
Una empresa incorpora compatibilidad con lectores de pantalla a su aplicación comercial. Otro proyecto propone desarrollar software para que personas con discapacidad puedan acceder a un servicio digital y plantea realizarlo sin fin de lucro. El ejemplo es ilustrativo y no presupone que ninguno tenga ya una calificación fiscal favorable.
En el primer encargo, añadir una prestación accesible no demuestra la condición de la vía específica. Habrá que estudiar las tareas y cualquier otra definición que se invoque. En el segundo, el destino y la condición planteados permiten abrir ese análisis, pero todavía deben verificarse en el diseño y en la ejecución.
El resultado es elegir qué se necesita comprobar antes de presupuestar: el primer encargo no se presenta como I+D por la accesibilidad aislada; el segundo identifica un supuesto legal concreto y sus condiciones pendientes. No se suma todo el coste como incentivo aprobado en ninguno de los dos.
Alexis puede revisar contigo la finalidad del desarrollo y la vía que tendría sentido estudiar.
Califica la actividad antes de ofrecer una cifra a un financiador
Una vez identificado el supuesto, revisa los gastos. La base de I+D exige que estén directamente relacionados con esas actividades, se apliquen efectivamente a ellas y aparezcan individualizados por proyecto. El presupuesto completo de una aplicación puede contener mantenimiento, implantación o explotación que necesiten otro análisis.
La guía de financiación de I+D+i ayuda a situar esa separación. No promete rentabilidad por el destino social del proyecto ni convierte una aportación de fondos en prueba de elegibilidad.
Fuentes: artículo 35.1 de la Ley del Impuesto sobre Sociedades y actividades de I+D explicadas por la AEAT. Comenta con Alexis qué servicio facilitará tu software y cómo se organizará su desarrollo antes de trasladar una previsión fiscal a terceros.
