Quali attività sul software distinguere dalla manutenzione ordinaria per il patent box?

A cura diAndrea DicantoConsulente tecnico e autore · Pubblicato il 28/10/2026

Per impostare una valutazione Patent Box sul software, la distinzione utile non nasce dal nome assegnato alla commessa, dal reparto che ha lavorato o dalla voce contabile: nasce da ciò che il team ha cercato di risolvere, dalle alternative considerate e dal risultato tecnico effettivamente prodotto. La manutenzione ordinaria tende a riportare il programma a un comportamento già atteso; un’attività di ricerca, invece, parte da un problema tecnico la cui soluzione non è già definita nel materiale di progetto e richiede confronto tra ipotesi, prove e decisioni.

La stessa release può contenere entrambe le componenti. La scelta operativa è quindi scomporre il lavoro in attività omogenee e descrivere, per ciascuna, il punto di partenza, l’incertezza affrontata, le prove svolte e l’output ottenuto. Questo confronto non assegna da solo un trattamento fiscale: rende però riconoscibile quale parte del lavoro merita un approfondimento tecnico, contabile e documentale nel percorso Patent Box.

La distinzione parte dall’effetto del lavoro sul software

Un primo gruppo comprende gli interventi il cui obiettivo è conservare o ripristinare una funzione già individuata. Rientrano in questa area, sul piano descrittivo, la correzione di un errore che impedisce a una funzione esistente di operare come previsto, l’adeguamento di configurazioni ricorrenti, il ripristino dopo un malfunzionamento e l’assistenza ordinaria agli utilizzatori. Il dato decisivo non è che l’intervento sia breve o ripetitivo: è che il risultato atteso fosse già noto prima dell’avvio e che il lavoro riporti il sistema a tale risultato.

Un secondo gruppo riguarda attività in cui il team non dispone inizialmente di una soluzione definita e deve verificare se una nuova architettura, un algoritmo, un modello dati o un’interazione tra componenti sia idonea a raggiungere un obiettivo tecnico. Sono segnali da descrivere, non etichette con effetto automatico, la formulazione di alternative, la realizzazione di prototipi, l’esecuzione di test comparativi, l’analisi di risultati non previsti e una decisione tecnica motivata tra opzioni differenti.

Esiste poi una fascia intermedia: modifiche ampie che possono sembrare sviluppo perché coinvolgono molte ore o più componenti, ma che possono anche consistere nel trasferire un comportamento già definito. In questa fascia conta ricostruire la domanda iniziale. Se il gruppo di lavoro conosceva già il risultato e il percorso da applicare, la dimensione dell’intervento non trasforma da sola il lavoro in ricerca. Se invece il percorso tecnico richiedeva di scegliere tra soluzioni non equivalenti e di dimostrarne il comportamento, la documentazione dovrebbe rendere visibile quella sequenza.

Segnali pratici per separare le attività

La classificazione può partire da una tabella interna di lavorazione, ma la riga non dovrebbe limitarsi a formule come “sviluppo”, “evolutiva” o “bug fixing”. È più utile associare a ogni blocco un verbo tecnico e un risultato osservabile.

• Ripristinare: la segnalazione indica un comportamento difforme rispetto a una funzione già descritta; il lavoro corregge la difformità e la prova finale confronta il comportamento ripristinato con quello atteso.
• Adattare: si modifica un parametro, una regola configurabile o un collegamento per mantenere operativa una funzione nota in un contesto aggiornato. Occorre indicare quale comportamento preesistente resta invariato.
• Esplorare: il team formula più ipotesi per superare un limite tecnico e non sa, all’avvio, quale sia praticabile. Le alternative e i criteri di confronto sono elementi rilevanti della ricostruzione.
• Sperimentare: vengono realizzati prototipi, prove di carico, test di integrazione o altre verifiche per osservare il comportamento di una soluzione non ancora scelta. Il verbale o il risultato del test spiega perché una strada viene proseguita o abbandonata.
• Progettare una nuova capacità: il lavoro definisce componenti, flussi o logiche necessari a ottenere una funzione non precedentemente disponibile nel prodotto. Qui conviene distinguere la fase di ideazione e prova dalla successiva implementazione ripetitiva.

Il passaggio risolutivo consiste nel mettere a confronto il comportamento iniziale e quello finale. Se l’attività porta il software dal comportamento atteso ma difettoso allo stesso comportamento atteso e funzionante, la descrizione è orientata alla manutenzione. Se porta da un problema tecnico aperto a una soluzione scelta dopo prove tra alternative, la descrizione evidenzia una componente di ricerca. Una sola attività può essere spezzata quando i due risultati si susseguono: prima la correzione del difetto, poi la sperimentazione di una soluzione nuova.

Percorso diagnostico: dalla segnalazione tecnica alla decisione

1. Ricostruire il punto di partenza. Per ogni attività, raccogliere ticket, specifica, richiesta interna o documento equivalente e indicare quale funzione esisteva prima del lavoro. Senza questo confronto, una modifica estesa può essere descritta in modo troppo generico.
2. Individuare l’incertezza concreta. Separare un difetto con soluzione già identificabile da un problema per il quale il team ha dovuto decidere tra strade tecniche. È utile annotare la domanda aperta: prestazioni, interoperabilità, affidabilità, modello dati, sicurezza applicativa o altra caratteristica effettivamente discussa nel progetto.
3. Collegare le prove alla scelta. Associare prototipi, test, verbali tecnici, repository, richieste di modifica e versioni alla decisione adottata. Il documento non deve essere lungo: deve permettere di capire quale alternativa è stata provata e quale evidenza ha orientato il lavoro.
4. Separare tempo e costi per blocco di attività. Le ore e i costi diventano leggibili quando seguono la stessa scomposizione tecnica. Un’unica imputazione globale della release non chiarisce quanta parte riguardi ripristino, adattamento, esplorazione o implementazione.

Questo controllo interno è particolarmente utile quando le ore sono registrate con causali generiche. In quel caso non conviene riscrivere a posteriori una causale per renderla più favorevole: è più solido affiancare una ricostruzione coerente con le evidenze tecniche disponibili e lasciare distinta la parte che non si riesce a spiegare con precisione.

Un esempio applicativo senza attribuire effetti fiscali

Si immagini una piattaforma che presenta errori nella validazione di dati già gestiti da una funzione esistente. La correzione del controllo e il test che conferma il ritorno al comportamento previsto costituiscono un blocco autonomo di manutenzione nella ricostruzione interna. Nella stessa release, il team può affrontare un secondo problema: elaborare dati provenienti da formati diversi senza compromettere le prestazioni. Se prova due modalità di elaborazione, registra i risultati e sceglie una soluzione perché l’altra non raggiunge il risultato tecnico cercato, questo secondo blocco mostra una sequenza di ricerca da analizzare separatamente.

La conclusione operativa non è sommare automaticamente le ore della release sotto una sola etichetta. È creare due righe distinte, ciascuna con obiettivo, evidenze, persone coinvolte e periodo di lavoro. La conclusione cambierebbe se i test fossero soltanto controlli finali su una soluzione già integralmente definita: in tal caso verrebbe meno l’elemento di confronto tra alternative che rende riconoscibile il secondo blocco come attività di ricerca sul piano documentale.

Per approfondire la coerenza tra attività, beni immateriali, costi e documenti, può essere utile la guida sui problemi da chiarire prima di impostare un caso Patent Box.

Quando coinvolgere lo studio

È opportuno coinvolgere lo studio quando il progetto contiene insieme correzioni, evoluzioni e sperimentazioni e non è chiaro come raccordare le evidenze tecniche con ore, costi, contratti e dati contabili. Alessio Ferretti STP, studio di commercialisti, può svolgere una prima lettura fiscale-documentale del caso, confrontando la scomposizione delle attività con le versioni software, le rilevazioni dei costi e la documentazione disponibile, così da indicare quali punti richiedono approfondimento prima del calcolo e del fascicolo.

Nel contatto è utile descrivere la situazione, l’urgenza della decisione e l’elenco dei documenti già disponibili, ad esempio tracciati delle attività, versioni, test, registrazioni delle ore e prospetti dei costi. Le modalità di trasmissione possono essere concordate dopo il contatto.

Richiedi una valutazione preliminare per una prima valutazione senza impegno.