Software interno e patent box: prima si controllano bene immateriale, costi e fascicolo

A cura diAndrea DicantoConsulente tecnico · Pubblicato il 27/07/2026

Il problema concreto: il software esiste, ma il fascicolo non sempre lo sostiene

Quando un’impresa sviluppa software internamente, la domanda sul Patent Box nasce quasi sempre da una situazione pratica: il programma è usato ogni giorno, ha richiesto lavoro tecnico, ha generato costi e magari è diventato centrale per produzione, logistica, pricing, clienti o processi amministrativi. Questo, però, non basta per assumere una posizione fiscale senza una verifica ordinata.

La risposta prudente non è una promessa di accesso al beneficio. Il software interno deve prima essere letto come possibile bene immateriale da analizzare, collegando sviluppo, costi, contratti, contabilità e documentazione tecnica. Se questi elementi non dialogano tra loro, il tema non è solo il calcolo Patent Box, ma la difendibilità della posizione in caso di controllo.

Per un CFO, un amministratore o un responsabile R&S il punto critico è spesso documentale. Le informazioni sono sparse tra repository, ticket, preventivi, fatture, incarichi a sviluppatori, centri di costo, scritture contabili e relazioni tecniche. Una consulenza Patent Box utile parte da qui: non dal desiderio di applicare un beneficio, ma dalla capacità di dimostrare che il bene, le attività e i costi sono ricostruibili in modo coerente.

Un primo approfondimento sul metodo di valutazione dei beni immateriali è disponibile nella guida su governance dei beni immateriali e primo confronto Patent Box.

Quando il software interno merita una verifica patent box

Un software sviluppato in azienda merita una verifica Patent Box quando non è soltanto un insieme generico di strumenti informatici, ma un progetto identificabile, documentato e collegato ad attività tecniche ricostruibili. Questa è una buona pratica di analisi preliminare, non una regola automatica: serve a capire se vale la pena procedere con una valutazione più strutturata.

La prima domanda riguarda il perimetro del bene immateriale. Occorre capire se l’impresa sta parlando di un prodotto software, di un modulo, di una piattaforma, di una personalizzazione, di una semplice configurazione o di attività di manutenzione. La seconda domanda riguarda i costi: chi ha lavorato al progetto, con quali incarichi, per quali attività, con quali evidenze contabili. La terza domanda riguarda la coerenza: ciò che viene descritto sul piano tecnico deve trovare riscontro nei contratti, nelle fatture, nelle scritture contabili e nei prospetti interni.

Il perimetro del sito Patent Box resta fiscale-documentale. Non si tratta di trasformare l’analisi in consulenza brevettuale pura o in una revisione informatica del codice. Il presidio professionale serve a verificare se l’impresa dispone di elementi sufficienti per sostenere una posizione coerente sul bene immateriale, sui costi di ricerca e sviluppo collegabili e sul fascicolo di supporto.

Domande iniziali da porre

• Che cosa è stato sviluppato: piattaforma, modulo, componente, integrazione o semplice adattamento operativo.
• Chi ha svolto le attività: personale interno, consulenti, software house, fornitori infragruppo o combinazione di più soggetti.
• Quali documenti esistono: repository, ticket, piani di progetto, contratti, fatture, timesheet, report tecnici e note contabili.
• Quali costi si vogliono considerare: personale, consulenze, servizi tecnici e altre voci da verificare caso per caso.
• Quali punti sono incerti: titolarità, diritti d’uso, distinzione tra sviluppo e manutenzione, criteri di imputazione e coerenza con il bilancio.

Checklist documentale prima del calcolo

Il calcolo Patent Box dovrebbe arrivare dopo la mappatura, non prima. In assenza di un fascicolo ordinato, anche un progetto tecnicamente rilevante può risultare debole sul piano fiscale. La checklist seguente non è un elenco legale esaustivo, ma uno schema operativo per avviare una verifica professionale senza confondere fatti, ipotesi e documenti mancanti.

Matrice bene-costo-documento

• Bene immateriale: descrizione del software, moduli, versioni, architettura funzionale, finalità d’uso e documentazione tecnica disponibile.
• Attività svolte: sviluppo, evoluzione, test, analisi tecnica, rilascio, manutenzione, assistenza utenti e parametrizzazione da tenere distinti nella lettura documentale.
• Costi collegabili: ore interne, fatture di consulenti, incarichi tecnici, servizi di sviluppo e criteri di imputazione da riconciliare con la contabilità.
• Contratti e diritti: incarichi, licenze, clausole su proprietà intellettuale, consegna dei risultati, rapporti con fornitori e possibili accordi infragruppo.
• Scritture contabili: registrazioni, centri di costo, prospetti di riconciliazione, bilancio e dichiarazioni da confrontare con la ricostruzione tecnica.
• Fascicolo Patent Box: indice dei documenti, assunzioni adottate, limiti della valutazione, documenti non disponibili e punti da approfondire prima di assumere la posizione fiscale.

La buona documentazione non è necessariamente la più voluminosa. È quella che consente a un soggetto terzo di seguire il ragionamento: quale software viene considerato, quali attività sono state svolte, quali costi sono stati selezionati, quali criteri sono stati usati e quali incertezze restano aperte. Per questo la costruzione del fascicolo Patent Box dovrebbe essere impostata prima di arrivare alla fase dichiarativa.

Scenario operativo: piattaforma gestionale sviluppata nel tempo

Un caso tipo riguarda una PMI che ha costruito negli anni una piattaforma gestionale per ordini, magazzino, listini e flussi con clienti o fornitori. All’inizio il progetto nasce come esigenza interna; poi vengono aggiunti moduli, integrazioni e funzioni specifiche. Alcune attività sono svolte da dipendenti, altre da fornitori esterni. La direzione amministrativa vuole capire se il software possa essere considerato nel perimetro Patent Box.

La valutazione prudente parte dalla descrizione del bene: quali moduli esistono, quali versioni sono documentate, quali parti sono state sviluppate su misura e quali derivano da strumenti standard. Poi passa ai costi: ore del personale, fatture dei fornitori, contratti, eventuali criteri di ripartizione e collegamento con i centri di costo. Infine verifica la coerenza tra documentazione tecnica, contratti e scritture contabili.

Il rischio aumenta se l’impresa presenta come sviluppo ciò che nei documenti appare come assistenza, manutenzione ordinaria o parametrizzazione. Un altro punto delicato riguarda i fornitori: se gli incarichi non chiariscono consegne, diritti e attività svolte, diventa più difficile sostenere una lettura ordinata del bene e dei costi. In questo scenario la consulenza non serve a costruire artificialmente il beneficio, ma a capire se la posizione è sostenibile, quali documenti mancano e quale livello di cautela adottare.

Errori da evitare nella valutazione

• Partire dal calcolo: senza mappatura del software, dei costi e dei documenti, il numero finale rischia di poggiare su assunzioni fragili.
• Trattare tutto l’IT come bene immateriale rilevante: licenze standard, canoni, assistenza e manutenzione richiedono una lettura distinta rispetto allo sviluppo documentato.
• Confondere strumenti agevolativi diversi: se lo stesso progetto è stato considerato anche per altre misure fiscali, le carte vanno lette separatamente per evitare sovrapposizioni non motivate.
• Ignorare i contratti: incarichi, licenze e clausole sui diritti possono incidere sulla ricostruzione del bene e dei costi.
• Trascurare la contabilità: una relazione tecnica perde forza se non è riconciliabile con scritture, centri di costo e prospetti utilizzati dall’impresa.
• Riempire il fascicolo con documenti generici: brochure, schermate o descrizioni commerciali possono aiutare, ma non sostituiscono la ricostruzione tecnica e contabile.

In sintesi

• Il software sviluppato internamente deve essere verificato prima di essere considerato nel perimetro Patent Box.
• La valutazione dovrebbe separare bene immateriale, attività tecniche, costi, contratti, scritture contabili e fascicolo documentale.
• La checklist è una buona pratica operativa, non una scorciatoia normativa.
• Il punto decisivo è la coerenza tra ciò che l’impresa racconta, ciò che i documenti provano e ciò che la contabilità registra.
• Quando mancano fonti primarie puntuali o documenti del caso concreto, è preferibile formulare una posizione prudente e indicare le verifiche ancora aperte.

Fonti normative e di prassi

Per questo contenuto non sono stati utilizzati articoli di legge, provvedimenti numerati, importi, percentuali, scadenze o sanzioni, perché nel materiale disponibile non sono presenti fonti primarie puntuali sul singolo requisito del software, sulla documentazione idonea e sul nuovo Patent Box. La verifica professionale dovrebbe quindi confrontare il caso concreto con le fonti ufficiali disponibili, in particolare Agenzia delle Entrate e Normattiva, oltre ai documenti tecnici, contabili e contrattuali dell’impresa.

Questa sezione ha funzione di cautela editoriale: indica le famiglie di fonti da consultare, ma non sostituisce la lettura degli atti applicabili alla data della valutazione. Se un riferimento non è stato verificato sul caso, deve restare fuori dal fascicolo oppure essere indicato come punto da approfondire.

Prossimi passi operativi

Lo studio può presidiare la valutazione con un approccio fiscale-documentale: lettura dei documenti disponibili, mappatura del software, ricostruzione dei costi, controllo di coerenza tra contratti e scritture contabili, individuazione dei punti deboli e delle verifiche da completare. Per rendere utile il primo confronto, prepara una descrizione del software, l’elenco dei moduli, i principali contratti, le fatture rilevanti, i dati contabili disponibili, l’urgenza della decisione e il perimetro del caso. Puoi richiedere una valutazione preliminare Patent Box per capire se il fascicolo è impostabile e quali cautele documentali adottare prima di assumere una posizione fiscale.