Per una consulenza Patent Box riferita a un progetto software, la base utile non è una stima globale del costo del team: è una matrice che collega una versione identificabile del software alle attività svolte, al periodo di lavoro, alle ore rilevate e al costo sostenuto documentato. Questa ricostruzione rende leggibile il rapporto tra sviluppo tecnico e dati amministrativi, ma non certifica il Patent Box né consente, da sola, di esprimere una conclusione fiscale sul caso.
La scelta operativa è quindi partire da una versione concreta e da un compito effettivamente tracciabile, separando ciò che descrive manutenzione da ciò che descrive sviluppo. Le due etichette sono descrizioni iniziali da qualificare nel contesto del progetto: non vanno trasformate automaticamente in un esito fiscale. Il risultato atteso è un dossier di lavoro coerente, sul quale decidere se approfondire il caso, quali dati integrare e quali incongruenze chiarire.
In sintesi
- Una riga della matrice collega una versione, un’attività, un periodo, le ore e un costo supportato da evidenze disponibili.
- Il riferimento alla versione va mantenuto distinto dal nome commerciale del prodotto, se i due elementi non coincidono.
- Le attività di manutenzione e sviluppo vanno descritte con fatti tecnici osservabili, evitando qualificazioni anticipate.
- Le ore senza un collegamento temporale e tecnico restano un dato debole per la ricostruzione.
- Un costo può essere inserito solo se la sua provenienza documentale è riconoscibile e riconciliabile internamente.
La matrice parte dalla versione, non dalla voce di costo
Il punto di partenza è una versione, una release o un altro identificativo adottato dall’impresa per distinguere un insieme di modifiche. Non occorre attribuire alla versione qualità che non risultano dai materiali disponibili: è sufficiente indicare il codice o il nome usato nel ciclo di rilascio e collegarlo a una descrizione circoscritta del lavoro.
Una matrice essenziale può contenere queste colonne: identificativo della versione; componente o area interessata; attività del team; periodo; persona o ruolo coinvolto; ore rilevate; riferimento al documento di costo; importo di costo documentato; fonte tecnica; annotazione sulla descrizione iniziale dell’attività. L’ultima colonna non assegna un trattamento: serve a rendere esplicito se il team ha descritto il lavoro come manutenzione, sviluppo o attività mista e perché.
| Versione | Attività descritta | Periodo | Ore | Costo documentato | Collegamento utile |
|---|---|---|---|---|---|
| Rilascio 3.4 | Adeguamento della logica di elaborazione | Mese indicato nei registri | Ore del registro interno | Documento contabile identificato | Ticket, repository o verbale di rilascio |
| Rilascio 3.5 | Correzione di errore segnalato | Mese indicato nei registri | Ore del registro interno | Documento contabile identificato | Segnalazione, test e nota di chiusura |
| Modulo separato | Nuova funzione prevista nella pianificazione | Periodo di lavoro indicato | Ore del registro interno | Documento contabile identificato | Specifica, attività e rilascio |
La tabella non è un modello rigido. Se il software viene gestito senza release formali, il collegamento può usare altri riferimenti effettivi, quali ticket, richieste di modifica, repository, piani di lavoro o verbali tecnici. Il criterio organizzativo è semplice: chi legge la riga deve poter capire quale lavoro si sta descrivendo, quando è avvenuto e dove trovare il relativo riscontro.
Quando il software è sviluppato internamente, il collegamento fra bene, costi e fascicolo richiede spesso una ricostruzione più ampia. Approfondisci le verifiche sul software sviluppato internamente e sulla coerenza dei documenti.
Percorso diagnostico: dai dati tecnici alla decisione di approfondire
Un controllo interno efficace può seguire un percorso diagnostico in tre passaggi, ciascuno orientato a eliminare ambiguità prima della valutazione professionale.
- Individuare l’oggetto tecnico. Per ciascuna versione, si raccolgono il riferimento di rilascio, la componente interessata e una descrizione breve dell’intervento. Se una stessa attività riguarda più versioni, conviene dividerla secondo il criterio realmente usato dal team, senza forzare ripartizioni retrospettive non supportate.
- Legare il lavoro al tempo. Le ore acquistano utilità quando possono essere ricondotte a periodo, attività e soggetto o ruolo. Se il registro indica soltanto un totale mensile, è opportuno segnalarlo come limite della ricostruzione invece di attribuirlo artificialmente a una singola versione.
- Riconciliare il riferimento di costo. La matrice indica il documento da cui deriva il costo e la relazione con le ore o l’attività. Se il costo copre anche lavori estranei al progetto, la riga dovrebbe evidenziare la porzione non attribuibile con i dati disponibili, anziché assorbirla nel progetto.
Il terzo passaggio non richiede di calcolare un beneficio. Serve a verificare se la catena versione-attività-periodo-ore-costo è leggibile e se i documenti tecnici, contabili e contrattuali raccontano la stessa storia. In presenza di fornitori esterni, il contratto, l’ordine o il documento di avanzamento possono aiutare a chiarire oggetto, periodo e ruolo del fornitore, senza sostituire la descrizione tecnica dell’attività.
Manutenzione e sviluppo: descrivere prima di qualificare
La distinzione più delicata nasce quando la stessa release contiene correzioni, adeguamenti e nuove funzioni. In questa fase è buona pratica usare parole descrittive: “correzione di un errore”, “aggiornamento di compatibilità”, “nuova funzione”, “revisione della logica”, “test su componente modificato”. La matrice può riportare la definizione utilizzata dal team e il materiale che la sostiene, senza concludere che una categoria produca un determinato effetto fiscale.
Un intervento classificato internamente come manutenzione può includere modifiche più articolate; allo stesso modo, una funzione presentata come nuova può dipendere da correzioni preliminari. Per questo conviene evitare una sola etichetta applicata all’intera commessa o all’intero anno. È più utile distinguere le attività riga per riga e conservare l’incertezza quando la documentazione non consente una separazione affidabile.
Un errore frequente consiste nel partire dal costo totale del personale e cercare solo dopo un riferimento tecnico. L’ordine inverso è più difendibile sul piano organizzativo: prima si identifica la versione e il lavoro, poi si cerca la rilevazione delle ore e il costo documentato corrispondente. Un secondo errore è usare date di rilascio come prova del periodo di esecuzione: il rilascio può essere un punto di arrivo, non la durata effettiva delle attività.
Un caso applicativo per decidere la prossima azione
Si immagini un progetto con una release che include una correzione su una funzione esistente e una nuova schermata. Il responsabile tecnico dispone di ticket e di un riferimento al rilascio; le ore del team sono registrate per settimana, mentre il prospetto amministrativo consente di individuare i costi sostenuti nel periodo. La matrice può aprire due righe: una per la correzione e una per la nuova schermata, ciascuna con il proprio collegamento a ticket, ore e documento di costo.
Se le ore registrate distinguono i due interventi, la prossima azione è preparare la matrice con i riferimenti disponibili e sottoporla a lettura fiscale-documentale. Se invece le ore sono aggregate sull’intera release, il risultato non è una conclusione sul Patent Box: emerge la necessità di dichiarare il limite e di ricercare elementi contemporanei, come assegnazioni, note di sviluppo o test. La conclusione cambierebbe se la documentazione mostrasse che entrambe le attività appartengono in realtà a un diverso progetto o se il costo indicato non fosse riconciliabile con il periodo di lavoro.
Quando coinvolgere lo studio
Conviene coinvolgere lo studio quando la matrice presenta attività miste, costi condivisi fra progetti, apporti di soggetti esterni, versioni prive di una cronologia chiara oppure differenze tra quanto riportano i documenti tecnici e quelli amministrativi. In questi casi la raccolta non va estesa in modo indiscriminato: occorre prima decidere quali punti influenzano la valutazione e quali fonti possono chiarirli.
Alessio Ferretti STP, studio di commercialisti, può esaminare e gestire professionalmente il caso concreto nel perimetro del servizio: prima lettura fiscale-documentale, mappatura delle informazioni disponibili e verifica di coerenza fra dati tecnici, contabili e contrattuali. Quando servono valutazioni tecniche o legali sul bene immateriale, il contributo fiscale, contabile ed economico può essere coordinato con professionisti associati competenti.
Nel primo contatto è utile descrivere la situazione del progetto, l’urgenza della decisione e un elenco dei documenti e delle informazioni disponibili, ad esempio riferimenti alle versioni, registri delle ore, prospetti di costo, contratti e materiali tecnici. Non è necessario allegare dati personali o documenti riservati: l’eventuale trasmissione può avvenire solo dopo il contatto, tramite un canale sicuro concordato con lo studio.
Richiedi una consulenza Patent Box sul tuo progetto software.
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