La conversación llega casi siempre tarde: el proyecto terminó hace catorce meses, la asesoría plantea deducirlo y alguien tiene que explicar qué tenía de novedoso. El equipo que lo hizo ya está en otra cosa, el canal de Slack donde se discutió la arquitectura tiene el histórico cortado y lo único que queda es un repositorio con 900 commits que dicen “fix” y “wip”.
Se puede reconstruir. Sale caro y convence menos que el material escrito en su momento, porque lo que sostiene una calificación de I+D es la incertidumbre técnica, y la incertidumbre solo se ve en lo que se probó y se descartó.
Estos son los cinco documentos que hay que mantener vivos. Ninguno lleva más de veinte minutos por sprint.
1. El estado del arte de partida
Media página, escrita antes de la primera línea de código: qué existe hoy para resolver este problema, qué se ha mirado y por qué no sirve. Nombres de producto, versiones, enlaces, y la limitación concreta que hace que no valgan.
Es el documento que más pesa y el que casi nunca existe. La ley pide novedad objetiva frente al estado del arte, así que sin una foto de ese estado no hay nada contra lo que comparar el resultado. Escribirlo tiene además un efecto secundario útil: a veces descubres que el problema sí lo resuelve un producto que costaba 200 euros al mes.
2. El registro de lo que falló
Un fichero en el repositorio con las hipótesis que se probaron y no funcionaron. Tres líneas por entrada: qué se intentó, qué se esperaba, qué pasó.
Semana 3. Probado embedding por documento completo para la búsqueda sobre pliegos. Recall del 40% en consultas con referencias cruzadas entre anexos. Descartado: hace falta trocear por sección conservando la jerarquía.
Esa entrada vale más que cualquier adjetivo de una memoria. Demuestra que había un resultado incierto y que se resolvió mediante ensayo, que es exactamente la definición de desarrollo experimental.
3. Las horas separadas por actividad
La base de deducción son los gastos directamente relacionados con la actividad de I+D. Si el mismo equipo hace ingeniería nueva por la mañana y ajustes de interfaz por la tarde, y todo entra en la misma bolsa, la base se vuelve indefendible.
No hace falta un sistema de imputación complicado. Basta con que las tareas del gestor de proyectos lleven una etiqueta de actividad y que el volcado mensual salga separado. Lo importante es que la separación se haga a la vez que el trabajo, no en enero mirando hacia atrás.
4. Las decisiones de arquitectura
Un fichero por decisión relevante, con el formato clásico: contexto, alternativas consideradas, decisión y consecuencias. Los equipos que ya los escriben no tienen que cambiar nada; los que no, ganan de paso una memoria del proyecto que sirve para incorporar a alguien nuevo.
Para la calificación, un registro de decisiones muestra dónde estaba el problema técnico y qué se sacrificó al resolverlo. Es la diferencia entre “se desarrolló un motor de planificación” y una explicación de por qué el enfoque evidente no aguantaba el caso real.
5. La memoria técnica, escrita en paralelo
Un documento vivo que se actualiza al cerrar cada hito: objetivo, punto de partida, qué se ha construido, qué incertidumbre se ha resuelto y qué queda abierto. Al terminar el proyecto está escrito el 80% de lo que pedirá quien certifique.
Lo que no cuenta, por mucho que se documente
El artículo 35.1 de la Ley del Impuesto sobre Sociedades excluye de forma expresa las actividades habituales o rutinarias de mantenimiento del software y sus actualizaciones menores. Documentar bien un mantenimiento no lo convierte en I+D. Tampoco entran la instalación y configuración de producto de terceros ni el rediseño de algo que ya funcionaba.
Entre el mantenimiento y la I+D está la innovación tecnológica, que deduce al 12% y admite mejoras sustanciales de producto o proceso sin exigir novedad científica. Mucho desarrollo a medida serio cae ahí, y también hay que documentarlo.
Cuánto cuesta de verdad
Veinte minutos por sprint y un documento de media página al arrancar. Comparado con el trabajo de reconstruir dos años después, o con la posibilidad de que la deducción no se sostenga ante una comprobación, es barato.
En nuestra página sobre la deducción por I+D en software están los porcentajes vigentes y qué papel juega el informe motivado, que es la vía para que la calificación vincule a la Agencia Tributaria en lugar de depender del criterio de un inspector años más tarde.