Una licenza software non consente, da sola, di capire quale posizione l’impresa possa sostenere nel proprio percorso Patent Box. La domanda utile è più precisa: chi dispone del software, quali facoltà di sfruttamento risultano dal contratto, per quale versione e in quale rapporto con le attività e i costi che l’impresa intende esaminare? Se queste risposte non coincidono, il primo risultato operativo non è un calcolo: è l’individuazione dello scarto da correggere o da approfondire.
Per una valutazione fiscale-documentale, conviene separare tre piani che spesso vengono confusi: la disponibilità pratica del programma, la titolarità o l’attribuzione contrattuale dei diritti e la possibilità di collegare una specifica versione software a informazioni tecniche, contabili e contrattuali. Una licenza ampia nell’uso quotidiano può non descrivere, con lo stesso dettaglio, sviluppo, modifiche, distribuzione o sfruttamento economico. Il contratto non va quindi letto come un allegato isolato: va confrontato con ciò che l’impresa afferma di avere sviluppato, acquisito o utilizzato.
Il punto da chiarire: uso del software e diritti non sono la stessa cosa
Il primo errore nasce quando la disponibilità del software viene trattata come prova sufficiente della posizione dell’impresa sul bene immateriale. Un’impresa può utilizzare una piattaforma, finanziare interventi evolutivi, coordinare fornitori e sostenere costi collegati al progetto. Questi elementi descrivono un contesto rilevante da ricostruire, ma non risolvono da soli la domanda sulla licenza e sui diritti di sfruttamento.
La lettura pratica del contratto parte dall’oggetto identificato. Il nome commerciale del programma può essere troppo generico se, nel tempo, sono state introdotte versioni, moduli, integrazioni o componenti sviluppati per l’impresa. È utile verificare se l’accordo indica il software o i moduli interessati, se rinvia a specifiche tecniche, se distingue il prodotto originario dalle evoluzioni e se permette di collegare tali riferimenti alla documentazione disponibile. Quando il contratto usa definizioni ampie, una cronologia di release, ordini, verbali tecnici o corrispondenza di progetto può aiutare a delimitare ciò che si sta effettivamente analizzando.
Chi può utilizzare, modificare o mettere a disposizione il programma?
La seconda lettura riguarda le facoltà descritte, non l’etichetta attribuita al contratto. Una licenza può indicare un perimetro di utilizzo interno; può contemplare personalizzazioni, manutenzione, accesso al codice o interventi di terzi; può invece lasciare tali aspetti poco espliciti. Il punto non è assegnare autonomamente un significato giuridico definitivo a una clausola, ma individuare quali azioni dell’impresa trovano un riscontro testuale e quali restano da chiarire.
Per esempio, se il team interno dichiara di aver sviluppato funzionalità su una base software ricevuta in licenza, il confronto utile riguarda almeno quattro elementi: la parte di programma interessata, il soggetto che ha svolto l’attività, il periodo, e la facoltà contrattuale che rende coerente quell’intervento con l’assetto dei diritti. Se il contratto parla soltanto di uso della piattaforma, mentre le evidenze tecniche descrivono evoluzioni autonome, lo scarto non va nascosto in una descrizione generica del progetto. Va reso visibile e classificato: chiarimento contrattuale, delimitazione della componente sviluppata o approfondimento specialistico da coordinare.
Questo punto è distinto dalla ricostruzione dei costi. I costi possono essere ordinati per progetto, periodo e attività, ma non trasformano da soli una facoltà di fatto in un diritto contrattualmente ricostruibile. Per la parte relativa a versioni, attività e dati amministrativi, può essere utile l’approfondimento su software interno, bene immateriale, costi e fascicolo.
Errore da correggere: una licenza generica associata a un progetto troppo ampio
Un segnale di urgenza organizzativa emerge quando una stessa licenza viene usata per descrivere software originario, personalizzazioni, servizi del fornitore e sviluppo interno senza separare le componenti. In quel caso il rischio operativo non consiste nell’avere pochi documenti, ma nel costruire una narrazione che non consente di capire quale componente sia oggetto della valutazione e quale relazione esista con i diritti disponibili.
Percorso di correzione
- Ricostruire l’oggetto contrattuale. Si parte dalla versione o dal modulo realmente coinvolto, confrontando denominazioni contrattuali, allegati tecnici, ordini e documenti di progetto. Se una componente non è identificabile, conviene segnalarla come perimetro da delimitare, senza attribuirla automaticamente al software in licenza.
- Separare le funzioni svolte. È buona pratica distinguere l’uso del programma, la manutenzione ordinaria, le configurazioni e le attività che il team descrive come sviluppo o evoluzione. Questa separazione non qualifica fiscalmente le attività, ma evita che una descrizione unica faccia perdere il collegamento tra componente, attività e documento.
- Confrontare soggetti e facoltà. Per ciascuna componente, il controllo interno può mettere a confronto chi ha operato, chi risulta parte del contratto, quali soggetti intervengono come fornitori e quali facoltà risultano espresse. Una differenza tra questi elementi è un risultato utile: indica il punto su cui cercare chiarimenti o documenti integrativi.
- Decidere il prossimo passaggio. Se il perimetro è ricostruibile, la mappa può essere usata per collegare dati tecnici, contabili e contrattuali. Se manca il collegamento tra la componente sviluppata e la posizione sui diritti, conviene fermare l’estensione del ragionamento e definire quale chiarimento contrattuale o tecnico serve prima di proseguire.
Il danno evitabile è soprattutto metodologico: attribuire a un solo documento una funzione che non svolge, oppure sommare componenti diverse in un unico bene descritto in modo indistinto. Correggere lo scarto prima del calcolo rende più leggibile la decisione successiva; non anticipa né garantisce il trattamento del caso.
Quali clausole e documenti aiutano a decidere?
Una lettura utile non richiede di trasformare l’impresa in un archivio contrattuale. Conviene però disporre di una scheda sintetica per ogni componente rilevante: identificativo della versione o del modulo, contratto di riferimento, parti coinvolte, datazione interna dei documenti, attività dichiarate e relazione con costi o evidenze tecniche. La scheda serve a mettere a confronto informazioni già disponibili, non a sostituire interpretazioni legali o valutazioni tecniche specialistiche.
Le domande naturali sono: il contratto rinvia a un allegato che manca? La licenza copre una componente diversa da quella riportata nei documenti del progetto? Le evoluzioni sono descritte in un ordine o in una specifica separata? Il soggetto che ha sviluppato una funzione coincide con il soggetto contrattualmente coinvolto? La risposta a queste domande cambia il percorso: talvolta basta circoscrivere il perimetro al software chiaramente ricostruibile; in altri casi occorre acquisire un chiarimento prima di associare la componente ai dati di progetto.
Non è utile forzare una soluzione quando contratto e realtà operativa raccontano cose diverse. Un esito prudente e concreto può essere: «la componente A è documentata fino al suo utilizzo, mentre la componente B richiede una ricostruzione dei diritti e delle evoluzioni». Questa distinzione consente di non estendere il ragionamento da una parte chiara a una parte ancora incerta.
Quando coinvolgere lo studio nella valutazione del caso
Conviene coinvolgere lo studio quando la licenza è generica rispetto alle componenti oggetto di analisi, quando sviluppo interno e attività di fornitori si sovrappongono, oppure quando contratti, dati tecnici e contabilità non conducono allo stesso perimetro. Alessio Ferretti STP, studio di commercialisti, può svolgere una prima lettura fiscale-documentale del caso, confrontando contratti, informazioni tecniche e dati contabili per definire quali elementi possono essere organizzati per il fascicolo e quali richiedono approfondimenti ulteriori nel perimetro del servizio.
Nel primo contatto è utile descrivere la situazione, il livello di urgenza e un elenco dei documenti disponibili: ad esempio il tipo di licenza, le versioni o i moduli interessati e l’eventuale presenza di accordi con sviluppatori o fornitori. Non è necessario inviare subito materiale riservato: le modalità di trasmissione possono essere concordate dopo il contatto, per una prima valutazione senza impegno.
Commenti
Commenti e domande dei lettori
Puoi leggere gli interventi pubblicati. Se vuoi aggiungere una domanda pertinente, apri il modulo: sarà visibile solo dopo moderazione.
Lascia un commento