Sueldos de desarrolladores y gastos admisibles del IP Box de Chipre

Un puesto técnico no convierte todas sus horas en I+D

La normativa incluye expresamente salarios y sueldos entre los gastos admisibles, pero exige una relación directa con el activo intangible admisible. Por eso la nómina suele ser fundamental en el cálculo nexus de una empresa de software. Incorporar toda la nómina del equipo técnico sin analizarla puede, sin embargo, inflar el numerador.

En una misma semana, un desarrollador puede crear una nueva función, investigar un problema técnico, responder a consultas de clientes y preparar una demostración comercial. Estas actividades no reciben el mismo tratamiento fiscal simplemente porque las realiza la misma persona. Describa el trabajo real, identifique el activo y después evalúe el gasto correspondiente.

Las descripciones de puestos ayudan a definir responsabilidades, pero rara vez explican cómo se empleó un periodo concreto. Combine registros de proyectos y tareas, documentación de versiones y pruebas de la dirección. Un porcentaje que se repite sin cambios cada mes debe poder contrastarse con el trabajo efectivamente realizado.

Ejemplo de distribución salarial con funciones mixtas

Supongamos que el coste salarial de un empleado en un periodo es de 8.000 €. Los registros acreditados atribuyen la mitad al desarrollo del Producto A, una cuarta parte al Producto B y otra cuarta parte al soporte operativo. Si el desarrollo cumple los requisitos, la asignación salarial potencialmente admisible es de 4.000 € a A y 2.000 € a B. Los 2.000 € restantes requieren su propio análisis y no entran automáticamente en QE.

Este ejemplo no establece un porcentaje legal ni un método oficial de registro de horas. Ilustra cómo dividir una misma partida salarial utilizando pruebas. Las cotizaciones empresariales, bonificaciones, prestaciones y demás importes laborales necesitan una clasificación propia: no añada todas las cuentas de personal a QE sin comprobar qué representan.

Concilie los importes distribuidos con la nómina y evite duplicidades. Si el desarrollador está contratado por otra sociedad del grupo que factura a la empresa chipriota, el coste no es simplemente una nómina propia de esta última. Deben aplicarse las reglas de externalización y partes vinculadas a la relación efectiva.

Conectar nómina, trabajo y activo

Una cadena probatoria útil conecta el asiento salarial con la persona, la persona con el trabajo documentado y ese trabajo con el activo admisible. Cada vínculo cumple una función diferente. Una nómina acredita la remuneración, no la naturaleza del desarrollo. Un commit de código muestra un cambio, no su coste completo.

Establezca identificadores estables para proyectos y activos que entiendan tanto finanzas como el equipo técnico. Guarde una breve explicación de las asignaciones importantes, incluido el trabajo en plataformas compartidas. Si se benefician varios productos, utilice una distribución fundamentada en lugar de contar todo el mismo esfuerzo en el numerador nexus de cada producto.

Revise periódicamente la diferencia entre desarrollo y operación ordinaria. Las funciones de un equipo pueden cambiar tras el lanzamiento, y un fundador puede pasar de programar a dirigir o vender. No mantenga la distribución del año anterior únicamente porque produjo un resultado favorable.

• Periodo de nómina y referencia del empleado.
• Descripción de la tarea de desarrollo y su vínculo con el activo.
• Registros de proyectos, versiones o trabajos que la respalden.
• Método de distribución de funciones mixtas y trabajo compartido.
• Conciliación de los importes asignados con la nómina original.
• Prueba del empleador y de cualquier refacturación intragrupo.

El tiempo del fundador y el trabajo no remunerado exigen cautela

El valioso esfuerzo de un fundador no equivale a un gasto incurrido por el contribuyente que solicita la deducción. No introduzca un salario hipotético a valor de mercado por trabajo histórico no remunerado para elevar el cociente nexus. Determine el gasto real y la relación jurídica antes de incluir cantidades en el cálculo.

El desarrollo anterior a la constitución plantea cuestiones adicionales de titularidad y gasto. La posterior transferencia de código a una sociedad no convierte automáticamente el esfuerzo previo del fundador en I+D propia de aquella. Examine por separado la transferencia, su contraprestación, la documentación y el desarrollo posterior.

Cuando falten registros, identifique la carencia y recupere pruebas originales auténticas cuando existan. Una explicación retrospectiva puede aclarar los hechos, pero no debe presentarse como un registro de horas elaborado en aquel momento. El objetivo es un cálculo trazable y defendible, no solamente una hoja de cálculo con todas sus celdas rellenas.