Cyprus IP Box: contrato de desarrollo de software y lista práctica

El contrato debe describir la relación de desarrollo real

Un contrato de desarrollo de software es una prueba útil porque explica quién encargó y realizó el trabajo, qué producto se benefició y qué derechos resultaron. No constituye aprobación de la IP Box. Activo admisible, ingresos, gastos y conducta efectiva deben examinarse por separado conforme a las reglas aplicables.

Identifique a las partes jurídicas correctas y su relación. Un empleado, profesional autónomo, estudio independiente y empresa de investigación del grupo desempeñan funciones diferentes. Compruebe entidad registrada, destinatario del pago, país, cadena de subcontratación y posible vinculación. Un nombre comercial en la factura puede ocultar al verdadero contratante y alterar la clasificación del nexo.

Defina el encargo de modo que pueda compararse con el trabajo realizado. La orden de trabajo debe señalar producto, módulo, entregables, hitos, aceptación y cambios importantes. No presente todas las horas técnicas como investigación admisible. Soporte, implantación para clientes y marketing pueden coexistir con desarrollo, pero precisan descripción y tratamiento de costes separados.

Utilice el contrato como puente entre derechos y datos financieros. Acuerdo, registro del proyecto, factura y libro del intangible deben contar una historia coherente. Si el contrato cubre una plataforma completa pero la solicitud IP Box se refiere a un componente, identifique el componente y el criterio de atribución del trabajo. Una declaración genérica sobre «IP cualificada» no basta.

Acuerde una forma práctica de probar la ejecución. No todos los proveedores necesitan partes de trabajo minuto a minuto. Un código de proyecto, ticket, versión o aceptación de hito puede ser más fiable para un precio cerrado. Lo importante es seguir cada cargo hasta el trabajo, su autor, fecha y activo beneficiario.

Distinguir código nuevo, tecnología previa y mejoras posteriores

El código creado para el cliente, la tecnología que el proveedor poseía antes del encargo y las mejoras posteriores son categorías distintas. El contrato debe indicar qué derechos se ceden, cuáles se licencian y cuáles retiene el desarrollador o un tercero. Una cesión genérica de «toda la IP» puede prometer derechos que el proveedor no posee.

Examine los derechos necesarios para el modelo de negocio: uso, reproducción, modificación, mantenimiento, sublicencia, distribución, transferencia y defensa. La Directiva 2009/24/CE protege la expresión de programas originales, no las ideas subyacentes, y regula determinados programas creados por empleados. No transfiere automáticamente al cliente los derechos de todo profesional independiente o proveedor transfronterizo.

Pregunte por bibliotecas reutilizables, componentes de código abierto, interfaces externas y código de subcontratistas. El contrato puede exigir revelación y respeto de licencias, pero el expediente debe mostrar que el proveedor obtuvo los derechos que pretende conceder. Una promesa de una empresa del grupo no subsana un eslabón ausente en la cadena de derechos.

Regule obras derivadas, mejoras y versiones posteriores a la aceptación. Si una vinculada mejora una plataforma compartida, aclare si la sociedad chipriota obtiene propiedad, licencia exclusiva o no exclusiva u otro derecho. Una mejora puede requerir análisis contable, de precios o nexo propio; no queda automáticamente incluida en la cesión inicial.

Considere entrega de código fuente, documentación, accesos y materiales de compilación. Estas obligaciones comerciales no crean por sí mismas elegibilidad fiscal. Pueden demostrar, sin embargo, si la sociedad puede ejercer los derechos invocados y mantener el programa al terminar la relación.

Vincular cada pago con trabajo y activo

Las normas chipriotas exigen registros de ingresos y gastos por intangible. Por eso, la descripción de la factura y el código de proyecto tienen importancia sustantiva. Defina cómo el proveedor describirá resultados, citará la orden de trabajo y separará categorías materiales. Finanzas debe poder relacionar cargo, labor, fecha y libro del activo.

Los encargos mixtos necesitan una distribución respaldada. Una factura mensual puede cubrir un algoritmo nuevo, incorporación de clientes y soporte rutinario. Alcance, hitos, horas u otro criterio defendible pueden justificar la distribución; todo el importe no se convierte en investigación. Las partes deben sumar la factura original sin duplicarse entre activos.

Diferencie desarrollar código nuevo de adquirir una base ya existente, y proveedor independiente de vinculado. El nexo modificado trata estas categorías de forma diferente. Un título «servicios de I+D» no transforma la compra de software terminado en investigación actual ni cambia la relación entre empresas.

Separe precios de transferencia y nexo. Una desarrolladora vinculada puede recibir una remuneración de mercado, pero el pago continúa siendo subcontratación a vinculada para clasificar gastos. Del mismo modo, un coste de un contratista independiente requiere pruebas del trabajo y vínculo con el activo; su independencia sola no hace admisible toda factura.

Para precios cerrados o pagos por fases, conserve plan de hitos, aceptaciones y cambios. La fecha del pago no siempre muestra cuándo se realizó el trabajo. Las reglas chipriotas consideran el gasto admisible cuando se incurre, con independencia del tratamiento contable o fiscal, por lo que debe reconstruirse el historial.

Registrar control operativo, riesgos y responsabilidades

Determine quién fija prioridades técnicas, aprueba presupuesto, cambia el alcance, acepta entregables y decide continuar o detener el proyecto. Son cuestiones comerciales que también pueden importar para DEMPE y precios vinculados. No asigne control a la sociedad chipriota solo en el papel si el equipo extranjero toma realmente las decisiones.

Describa desarrollo fallido, reelaboración, retrasos y sobrecostes. El contrato puede asignar riesgos, pero la entidad que afirma controlarlos necesita capacidad y decisiones efectivas para gestionarlos. Actas y aprobaciones de cambios resultan más convincentes cuando se elaboran durante el trabajo, no al reconstruir los hechos para una inspección.

Para equipos transfronterizos, examine ley aplicable, normas locales laborales y de autónomos, autoría y exigibilidad con asesores de los países correspondientes. El artículo 2 de la Directiva de software aborda programas de empleados en circunstancias concretas y salvo pacto diferente; no es una cesión universal de los derechos de todo profesional independiente.

Haga visible la subcontratación. Indique si se permite, quién la aprueba, cómo fluyen derechos y obligaciones de seguridad y si el proveedor inicial conserva responsabilidad. La identidad y vinculación del prestador efectivo pueden afectar al nexo. La cadena no debe ocultarse tras una etiqueta genérica de proveedor.

Lista de cláusulas y pruebas para un proyecto real

Utilice estas preguntas al informar al abogado o revisar un acuerdo existente. Cada respuesta debe remitir a un documento, responsable o decisión real, no simplemente a una cláusula estándar. Es una agenda de revisión, no una plantilla jurídica lista para firmar.

Empiece por identidad, trabajo y derechos. Confirme partes, vinculación y ley aplicable; identifique software y orden; diferencie código encargado, herramientas previas, componentes de terceros y mejoras; especifique derechos cedidos o licenciados. Compruebe la cadena de derechos de empleados, autónomos y subcontratistas cuando participen.

Después revise operaciones y pruebas de costes. ¿Quién dirige y acepta el trabajo? ¿Cómo se autorizan cambios? ¿Qué entregables, hitos, descripciones de facturas, repartos y registros por activo se conservan? Equipos técnico y financiero deben usar los mismos códigos de proyecto para que una revisión posterior reproduzca la atribución.

Por último, evalúe por separado los aspectos fiscales: si el proveedor está vinculado para el nexo, si se paga desarrollo o adquisición, qué operaciones controladas requieren soporte de precios y qué datos de ingresos y gastos existen por activo admisible. No inserte una conclusión tributaria en el contrato antes de establecer los hechos.

Ejemplo: código nuevo, herramientas previas y mejora

Supongamos que CyprusCo contrata al independiente Studio A para crear un módulo analítico de una aplicación existente. Studio A utiliza una biblioteca propia anterior, desarrolla el código nuevo y más tarde realiza una mejora separada. Un contrato sólido describe las tres categorías en vez de ceder vagamente «todo».

El código nuevo puede cederse a CyprusCo si Studio A posee los derechos necesarios y la cesión es eficaz bajo la ley aplicable. La biblioteca anterior puede seguir siendo de Studio A, mientras CyprusCo recibe una licencia adecuada para usarla con el módulo. La mejora posterior requiere su propio alcance, derechos e historial de costes.

Supongamos una primera factura de 90.000 €: 60.000 € para desarrollo original del módulo, 20.000 € para adquirir código o derechos existentes y 10.000 € para implantación al cliente. Las cifras muestran cómo separar cargos; no fijan automáticamente el tratamiento fiscal. La investigación admisible depende del trabajo y de los hechos jurídicos; adquisición e implantación se examinan aparte.

Si Studio A resulta ser una sociedad vinculada y no independiente, los mismos 60.000 € no pasan a ser desarrollo propio admisible de CyprusCo solo porque se contrataron o se pagaron a precio de mercado. La relación afecta al nexo; precios de transferencia evalúa la remuneración. Cambiar el título por «reembolso salarial» no altera los hechos.

Si la mejora la crea un subcontratista cuyos derechos Studio A nunca obtuvo, CyprusCo puede haber pagado y recibido el código y tener aun así una cadena de titularidad incompleta. Hay que revisar acuerdos reales y adquirir derechos eficaces. Una descripción posterior de factura o informe fiscal general no sustituye el eslabón que falta.

Mantener actualizados contrato y registros

Revise el acuerdo cuando cambien de manera importante partes, alcance, arquitectura del producto, derechos o facturación. Conserve las versiones anteriores firmadas para entender gastos históricos bajo términos y prácticas que regían entonces. Una modificación retroactiva no debe hacer parecer que un modelo nuevo existió desde el principio.

En la revisión anual, compare una muestra de trabajo y facturas reales con el alcance contratado. Examine historial del código y versiones, aceptación de hitos, descripciones de pagos y registro del activo. Pregunte si la misma entidad sigue dirigiendo el desarrollo, si hay nuevos subcontratistas y si la cadena de derechos continúa completa.

Si contrato y conducta difieren, documente la discrepancia y el período antes de reescribirlo. Determine si falta una enmienda, si hay una factura incorrecta, si la operación controlada es distinta o si existe una laguna real de derechos. La corrección fiscal y la jurídica pueden ser diferentes.