Software sviluppato internamente e prove dell'ammissibilità al patent box

A cura diAndrea DicantoConsulente tecnico · Pubblicato il 14/10/2026

Il software sviluppato internamente può essere esaminato ai fini del Patent Box quando l’impresa riesce a descrivere con precisione quale bene immateriale sta considerando, come è stato sviluppato, quali attività gli sono riferibili e quali documenti sostengono questo racconto. La presenza del codice, dei costi del personale o dell’uso quotidiano del programma non costituisce, da sola, una risposta conclusiva: il passaggio utile è verificare se dati tecnici, contabili e contrattuali parlano dello stesso software e dello stesso perimetro temporale.

Le prove dell’ammissibilità non coincidono quindi con un unico documento da reperire. Sono un insieme di evidenze da mettere in relazione, distinguendo ciò che descrive il bene, ciò che rende ricostruibili le attività di sviluppo e ciò che collega le registrazioni economiche al progetto. Questa impostazione aiuta prima di avviare calcoli o assumere una posizione fiscale, perché rende visibili sia gli elementi già utilizzabili sia gli scarti che potrebbero cambiare la lettura del caso.

Quale prova serve quando il software è interno

La domanda iniziale non è soltanto «il software è stato creato in azienda?», ma «quale software, in quale versione e per quale funzione aziendale?». Una denominazione generica come “gestionale” o “piattaforma” può raccogliere moduli diversi, evoluzioni successive e componenti acquistati. Conviene quindi partire da una descrizione concreta: funzioni svolte, utenti interni o esterni, componenti sviluppati, integrazioni con strumenti di terzi e periodo in cui le principali evoluzioni sono state realizzate.

Una prima famiglia di prove è tecnica. Possono risultare utili piani di progetto, specifiche funzionali, ticket di sviluppo, repository, verbali di avanzamento, note di rilascio e documentazione che distingua una personalizzazione dall’attività sul nucleo del programma. Non serve trasformare questa raccolta in una semplice sequenza di file: ciascun elemento dovrebbe aiutare a rispondere a una domanda precisa. Per esempio, le note di rilascio possono chiarire se una funzione era già disponibile in un prodotto acquisito oppure se è stata progettata e sviluppata internamente.

La seconda famiglia è economico-contabile. Qui il punto non è cercare una sola voce con il nome del software, ma ricostruire come il lavoro tecnico è stato registrato e attribuito: personale coinvolto, consulenze, acquisti collegati allo sviluppo, centri di costo, commesse o altri criteri interni di tracciamento. Se il dato tecnico individua il modulo “ottimizzazione logistica” e il dato contabile aggrega costi di più progetti, emerge uno scarto da spiegare; non è utile attribuirlo automaticamente al software in esame.

La terza famiglia riguarda contratti e rapporti con terzi. Incarichi a sviluppatori, accordi con fornitori, licenze di componenti, documenti di consegna e condizioni di utilizzo possono chiarire chi ha svolto una parte delle attività e quale componente è stata acquisita. Il loro confronto con la documentazione tecnica serve a evitare che l’etichetta “interno” copra indistintamente lavoro svolto dall’impresa, apporti esterni e software standard adattato ai processi aziendali.

Come leggere gli scarti senza confondere prova e conclusione

La documentazione è più utile quando viene letta per relazioni, non per quantità. Un repository senza una descrizione del progetto può non rendere immediato il collegamento con le scritture; una fattura di consulenza senza attività dettagliate può non spiegare quale modulo sia stato realizzato; un costo interno senza riferimenti tecnici può restare troppo ampio. Lo scarto non prova un esito fiscale sfavorevole, ma indica esattamente quale ricostruzione occorre completare prima di procedere.

Un passaggio risolutivo consiste nel costruire una mappa a quattro colonne: componente software, attività descritta, evidenza disponibile e collegamento economico. Se una componente compare nelle specifiche e nelle note di rilascio ma non trova un corrispondente criterio di attribuzione nei dati contabili, la decisione operativa è separarla dalle componenti già ricostruibili, anziché estendere per analogia il loro trattamento. Se, al contrario, un costo è documentato ma non si collega a una funzione o a un’attività identificabile, la domanda da sciogliere riguarda il suo rapporto con il progetto, non la sola presenza del documento.

Questa distinzione evita anche un errore ricorrente: confondere la completezza del fascicolo con l’ammissibilità. Un fascicolo ordinato rende il ragionamento controllabile; non sostituisce l’analisi del bene immateriale, delle attività e dei costi che il caso concreto richiede. Per approfondire il modo in cui strutturare questo confronto tra bene, costi e documentazione, può essere utile la guida sul presidio documentale per Patent Box e beni immateriali.

Caso tipo: dal software usato ogni giorno al perimetro ricostruibile

Si consideri una società che utilizza una piattaforma interna per coordinare ordini, produzione e assistenza. Il caso è ipotetico: non descrive un risultato reale né determina un esito fiscale. La società dispone di un elenco di rilasci, di registrazioni delle ore di un team interno e di un contratto con un fornitore che ha sviluppato alcune integrazioni.

1. Primo elemento: identificare il bene. L’impresa separa il nucleo della piattaforma dalle integrazioni con sistemi di terzi. Le specifiche indicano che alcune funzioni sono state progettate dal team interno, mentre altre riguardano collegamenti realizzati dal fornitore.
2. Secondo elemento: allineare attività e costi. Le registrazioni delle ore citano sia la piattaforma sia attività di assistenza ordinaria. Il confronto con ticket e rilasci consente di distinguere, nel materiale disponibile, le attività riferibili a nuove funzioni da quelle che non descrivono uno sviluppo del modulo esaminato.
3. Terzo elemento: chiarire il ruolo del terzo. Il contratto esterno e i documenti di consegna vengono confrontati con l’architettura tecnica. Se l’integrazione è un componente separato, la sua relazione con il bene considerato va descritta senza assimilarla automaticamente al lavoro interno.
4. Esito operativo. Alla fine del confronto l’impresa non ottiene una scorciatoia, ma un perimetro più leggibile: componenti documentate, costi con collegamento da approfondire e documenti da completare. La conclusione cambierebbe se le specifiche dimostrassero che una funzione attribuita al team interno era invece già compresa in una licenza acquisita, oppure se le registrazioni interne consentissero di collegare con maggiore precisione attività e componenti.

Il valore del caso tipo sta nella decisione che permette di prendere: non sommare indistintamente tutti i costi informatici, ma proseguire solo sulle parti per cui bene, attività ed evidenze possono essere messi in relazione in modo comprensibile.

Quando coinvolgere lo studio nella valutazione del caso

È opportuno coinvolgere lo studio quando il software esiste e viene utilizzato, ma non è chiaro se la sua descrizione tecnica, le registrazioni dei costi e i contratti delimitino lo stesso oggetto; oppure quando l’impresa deve decidere quali informazioni ordinare prima di impostare il fascicolo e il calcolo. Alessio Ferretti STP, studio di commercialisti, può svolgere una prima lettura fiscale-documentale del caso, mappando il bene immateriale considerato, i costi e le evidenze disponibili e mettendo in evidenza i punti che richiedono approfondimento.

Per orientare il primo confronto è utile descrivere la situazione del software, l’urgenza della decisione e un elenco dei documenti disponibili, come documentazione tecnica, dati contabili e contratti pertinenti, senza inviare allegati riservati nel primo messaggio. Dopo il contatto si possono concordare le modalità di trasmissione più adatte.

Richiedi una valutazione preliminare per una prima valutazione senza impegno.