Cyprus IP Box: accordo di sviluppo software e verifica pratica

L’accordo deve descrivere il rapporto di sviluppo reale

Un accordo di sviluppo software è una prova utile perché spiega chi ha commissionato ed eseguito il lavoro, quale prodotto ne ha beneficiato e quali diritti sono sorti. Non costituisce un’approvazione IP Box. Bene ammissibile, reddito, spese e condotta effettiva devono comunque essere esaminati separatamente secondo le norme applicabili.

Identificare correttamente le parti e i loro rapporti. Dipendente, freelance indipendente, studio esterno e società di ricerca del gruppo hanno ruoli diversi. Verificare denominazione legale, destinatario del pagamento, paese, catena dei subappalti e legami societari. Il nome commerciale in fattura può nascondere la vera controparte contrattuale e modificare la classificazione nexus.

Definire il progetto a un livello verificabile rispetto ai lavori. L’ordine di lavoro dovrebbe individuare prodotto, modulo, risultati, fasi, accettazione e modifiche rilevanti. Non fingere che ogni ora tecnica sia ricerca ammissibile. Supporto, implementazione presso clienti e marketing possono accompagnare lo sviluppo, ma richiedono descrizioni e trattamento dei costi distinti.

Collegare attraverso il contratto i diritti alle registrazioni economiche. Accordo, dati di progetto, fattura e registro del bene immateriale devono raccontare la stessa storia. Se il contratto riguarda un’intera piattaforma ma la richiesta IP Box un solo componente, identificare quest’ultimo e il criterio con cui il lavoro gli viene attribuito.

Concordare un modo pratico di documentare il lavoro. Non ogni fornitore necessita di fogli ore al minuto. Codice di progetto, ticket, cronologia delle versioni o approvazione di una fase possono essere più affidabili per un prezzo fisso. Occorre poter risalire dalla spesa al lavoro, a chi lo ha eseguito, alla data e al bene.

Distinguere nuovo codice, tecnologia preesistente e migliorie

Il codice scritto per il cliente, la tecnologia già detenuta dal fornitore e le migliorie successive sono categorie diverse. Il contratto dovrebbe indicare quali diritti vengono ceduti, concessi in licenza o conservati dallo sviluppatore o da terzi. Una formula generica che cede «tutta la IP» può promettere diritti che il fornitore non possiede.

Esaminare i diritti necessari al modello commerciale: uso, riproduzione, modifica, manutenzione, sublicenza, distribuzione, trasferimento e tutela. La direttiva 2009/24/CE protegge l’espressione di programmi originali, non le idee sottostanti, e disciplina alcuni programmi creati da dipendenti. Non trasferisce automaticamente al committente ogni diritto di un freelance o fornitore transfrontaliero.

Chiedere come sono trattate librerie riutilizzabili, componenti open source, interfacce esterne e codice dei subappaltatori. Il contratto può imporre comunicazione e rispetto delle licenze, ma il fascicolo deve mostrare che il fornitore ha acquisito i diritti che promette di concedere. Una promessa di una società del gruppo non sana un anello mancante nella catena.

Disciplinare derivati, migliorie e versioni dopo l’accettazione. Se una consociata migliora una piattaforma condivisa, chiarire se la società cipriota riceve proprietà, licenza esclusiva o non esclusiva, oppure altro diritto. Una miglioria successiva può richiedere una propria analisi contabile, di prezzo o nexus; non rientra automaticamente nella cessione iniziale.

Considerare consegna di codice sorgente, documentazione, accessi e materiale necessario per compilare le versioni. Queste obbligazioni commerciali non creano di per sé un’agevolazione fiscale. Possono però mostrare se la società può esercitare davvero i diritti dichiarati e mantenere il software dopo la fine del rapporto.

Rendere tracciabile ogni pagamento fino al bene

Le norme cipriote richiedono registrazioni di redditi e spese per ciascun immateriale. Descrizione della fattura e codice di progetto sono quindi questioni sostanziali. Stabilire come il fornitore descrive i risultati, richiama l’ordine di lavoro e separa categorie importanti. L’amministrazione deve poter collegare addebito, attività, data e registro del bene.

Gli incarichi misti richiedono una ripartizione sostenibile. Una fattura mensile può coprire un nuovo algoritmo, avvio del cliente e supporto ordinario. Ambito, fasi, tempo o altro criterio difendibile possono giustificare la ripartizione; l’intera fattura non diventa ricerca. Le quote devono tornare al totale originario e non essere contate due volte tra beni.

Distinguere lo sviluppo di nuovo codice dall’acquisto di una base già esistente e il fornitore indipendente da quello correlato. Il nexus modificato tratta diversamente queste categorie. L’intestazione «servizi R&S» non trasforma l’acquisto di software finito in ricerca corrente né modifica i rapporti tra le parti.

Separare transfer pricing e nexus. Uno sviluppatore del gruppo può percepire un corrispettivo di libera concorrenza, ma la spesa rimane esternalizzazione a parte correlata per la classificazione. Analogamente, il costo di un indipendente necessita di prove del lavoro e del legame con il bene; l’indipendenza da sola non qualifica ogni pagamento.

Per prezzi fissi o a stati di avanzamento, conservare calendario delle fasi, accettazioni e modifiche. La data del pagamento non indica sempre quando il lavoro è stato sostenuto. Le norme cipriote considerano le spese ammissibili quando sono sostenute, indipendentemente dal trattamento contabile o fiscale; occorre poter ricostruire lo storico.

Registrare controllo operativo, rischi e responsabilità

Identificare chi decide priorità tecniche, approva budget, cambia ambito, accetta risultati e sceglie se proseguire o fermare il progetto. Sono questioni gestionali che in un gruppo possono influire anche su DEMPE e prezzi di trasferimento. Non attribuire il controllo alla società cipriota solo sulla carta se il team estero decide davvero.

Descrivere sviluppo fallito, correzioni, ritardi e costi aggiuntivi. Il contratto può allocare il rischio, ma la società che afferma di controllarlo deve avere capacità e decisioni reali per gestirlo. Verbali e approvazioni di modifiche sono più convincenti se creati durante il lavoro, non ricostruiti per una verifica fiscale.

Per team transfrontalieri, esaminare legge applicabile, regole locali su lavoro dipendente e autonomo, autorialità ed eseguibilità con professionisti delle giurisdizioni interessate. L’articolo 2 della direttiva software tratta programmi dei dipendenti in condizioni specifiche e salvo diverso accordo; non costituisce una cessione generale dei diritti di tutti i freelance.

Rendere visibili i subappalti. Stabilire se sono ammessi, chi li approva, come si trasmettono diritti e obblighi di sicurezza e se il fornitore principale rimane responsabile. Identità e rapporto dell’esecutore reale possono rilevare ai fini nexus. La catena non va nascosta dietro una denominazione generica del fornitore.

Lista di clausole e prove per un progetto reale

Usare le domande seguenti per informare il legale o esaminare un accordo esistente. Ogni risposta dovrebbe indicare un documento, una persona responsabile o una decisione effettiva, non soltanto una clausola standard. È un’agenda di verifica, non un modello legale pronto per la firma.

Cominciare da identità, lavoro e diritti. Confermare parti, eventuale correlazione e legge applicabile; identificare software e ordine; distinguere nuovo codice, strumenti preesistenti, componenti di terzi e migliorie; precisare cosa viene ceduto o concesso in licenza. Verificare la catena dei diritti di dipendenti, autonomi e subappaltatori, quando coinvolti.

Poi controllare gestione e prove dei costi. Chi dirige e accetta il lavoro? Come vengono approvate le modifiche? Quali risultati, fasi, descrizioni delle fatture, criteri di ripartizione e registri per bene sono conservati? Amministrazione e tecnici dovrebbero usare gli stessi codici di progetto per rendere riproducibile il calcolo.

Infine esaminare separatamente gli aspetti fiscali: se il fornitore è correlato per il nexus, se il pagamento riguarda sviluppo o acquisto, quali operazioni richiedono supporto dei prezzi e quali dati di reddito e spesa esistono per bene qualificato. Non inserire una conclusione fiscale nel contratto prima di accertare i fatti.

Esempio: nuovo codice, strumenti preesistenti e miglioria

Si supponga che CyprusCo incarichi lo Studio A, indipendente, di costruire un nuovo modulo di analisi per un’applicazione esistente. Lo studio usa una propria libreria preesistente, scrive il nuovo codice e successivamente crea una miglioria separata. Un accordo affidabile descrive tutte e tre le categorie, invece di cedere genericamente «tutto».

Il nuovo codice può essere ceduto a CyprusCo se lo Studio A possiede i diritti necessari e la cessione è efficace secondo la legge applicabile. La vecchia libreria può restare allo studio, con una licenza d’uso adeguata per CyprusCo. La miglioria successiva richiede un proprio ambito, propri diritti e un proprio storico dei costi.

La prima fattura è, per ipotesi, di €90.000: €60.000 per sviluppo originale del modulo, €20.000 per acquisire codice o diritti esistenti e €10.000 per implementazione presso un cliente. Sono componenti illustrativi, non una classificazione fiscale automatica. La ricerca ammissibile dipende dall’attività e dai fatti giuridici; acquisto e implementazione richiedono valutazioni distinte.

Se lo Studio A è in realtà una società del gruppo, i medesimi €60.000 di sviluppo non diventano ricerca interna qualificata di CyprusCo solo perché commissionati o pagati a prezzo di mercato. Il rapporto tra le parti incide sul nexus, mentre il transfer pricing verifica il compenso. Cambiare il titolo in «rimborso del personale» non cambia i fatti.

Se un subappaltatore ha creato la miglioria senza trasferire i diritti allo Studio A, CyprusCo può aver pagato e ricevuto il codice ma avere una catena di titolarità incompleta. Occorre esaminare i contratti e acquisire diritti efficaci. Una descrizione successiva in fattura o un memorandum fiscale generale non sostituisce l’anello mancante.

Mantenere aggiornati accordo e registri

Rivedere l’accordo quando cambiano in modo rilevante parti, ambito, architettura, diritti o addebiti. Conservare le precedenti versioni firmate per comprendere spese storiche secondo condizioni e comportamenti dell’epoca. Una modifica retrodatata non deve far apparire che un nuovo modello operativo sia esistito fin dall’inizio.

Durante la revisione annuale confrontare un campione di lavori e fatture con l’ambito pattuito. Verificare cronologia del codice, versioni, accettazione delle fasi, descrizioni dei pagamenti e registro dei beni. Chiedersi se la stessa società dirige ancora il lavoro, se sono comparsi nuovi subappaltatori e se la catena dei diritti resta completa.

Se accordo e condotta divergono, documentare differenza e periodo prima di riscrivere il testo. Si tratta di un emendamento mancante, una fattura errata, una diversa operazione controllata o un vero vuoto nei diritti? Correzione fiscale e correzione giuridica possono essere diverse.