Quando un progetto software è davvero ricerca e sviluppo (e quasi sempre non lo è)

Capita a ogni preventivo un po' importante. Si arriva alla cifra, cala il silenzio, e poi qualcuno — a volte il commercialista, più spesso un conoscente che l'ha sentito dire — pronuncia la frase che sblocca la firma: «tanto è ricerca e sviluppo, una parte la recuperi».

Quella frase, nella grande maggioranza dei casi, è falsa. E il momento peggiore per scoprirlo è tre anni dopo, quando arriva una verifica e il credito compensato va restituito con sanzioni e interessi.

Vale la pena capire come stanno le cose, perché la differenza fra un progetto agevolabile e uno che non lo è non sta nel budget e nemmeno nella difficoltà tecnica. Sta in cinque criteri precisi, che quasi nessuno legge prima di firmare.

Cosa è ancora in piedi nel 2026

Prima dei criteri, il perimetro. Il credito d'imposta introdotto dalla legge di bilancio 2020 (legge 160/2019, commi 198-209) non è una misura sola: sono quattro misure diverse sotto lo stesso nome, e nel 2026 non sono più tutte vive.

Secondo la scheda del Ministero delle Imprese e del Made in Italy, oggi resta in vigore la ricerca e sviluppo in senso stretto — ricerca fondamentale, ricerca industriale, sviluppo sperimentale — con aliquota del 10% e massimale annuo di 5 milioni di euro, prevista fino al periodo d'imposta 2031.

Le altre tre porte si sono chiuse prima. Innovazione tecnologica, innovazione tecnologica 4.0 e green e design e ideazione estetica erano previste fino al periodo d'imposta 2025.

Questo dettaglio, che sembra burocratico, per chi sviluppa software è il punto centrale di tutta la storia. L'innovazione tecnologica era la porta larga: chiedeva un prodotto o un processo nuovo o sostanzialmente migliorato rispetto a quelli dell'impresa, un'asticella che un gestionale fatto bene poteva anche superare. La ricerca e sviluppo chiede molto di più, e chiede di dimostrarlo. Dal 2026 resta solo la porta stretta.

I cinque criteri, e cosa vogliono dire per chi scrive codice

I criteri applicativi sono stati fissati con il decreto ministeriale del 4 luglio 2024, che a sua volta rimanda ai principi del Manuale di Frascati dell'OCSE — un rimando previsto dalla legge stessa, al comma 200. Le linee guida individuano cinque criteri, e vanno soddisfatti tutti insieme: non è un punteggio, è una catena.

Novità. L'attività deve puntare a «nuove scoperte o al raggiungimento di nuovi risultati e conoscenze applicabili a prodotti e processi non già diffusi nel settore di riferimento». Attenzione al metro: non nuovo per la vostra azienda, nuovo per il settore. Un gestionale che dentro l'azienda cambia la vita a venti persone, se fuori esiste già in commercio, non è nuovo in questo senso.

Creatività. L'obiettivo deve essere «la creazione/individuazione di concetti o idee che migliorino lo stato dell'arte». Lo stato dell'arte è quello pubblico e documentabile, non quello del vostro reparto IT.

Incertezza. È il criterio che taglia di più, ed è anche il più onesto: le linee guida dicono che nella R&S «sin dall'inizio di un progetto, il tipo di risultato e/o i costi da sostenere per lo stesso non possono essere determinati con certezza». Detto in modo brutale: se noi vi abbiamo dato un preventivo a corpo con una data di consegna, abbiamo appena dichiarato per iscritto che l'incertezza non c'era. Un fornitore serio vi consegna un progetto prevedibile — ed è esattamente il motivo per cui quel progetto non è ricerca.

Sistematicità. Le attività devono essere «condotte in modo pianificato, con una formalizzazione dell'obiettivo perseguito». Qui la palla torna a voi e a noi: senza un obiettivo scritto prima e un tracciamento del lavoro durante, il criterio non è dimostrabile nemmeno quando è vero.

Trasferibilità e riproducibilità. Il progetto «dovrebbe comportare un potenziale trasferimento delle nuove conoscenze» e consentire ad altri di riprodurne i risultati. Un know-how che resta nella testa di due sviluppatori non è trasferibile per definizione.

Le linee guida non contengono un capitolo dedicato al software, e questo è di per sé un'informazione: lo sviluppo software segue la disciplina generale. Restano escluse le «modifiche ordinarie o periodiche apportate a prodotti, linee di produzione, processi di fabbricazione, servizi esistenti», e resta esclusa l'attività routinaria, che le linee guida descrivono per «l'assenza di creatività, di idee originali e di incertezza».

La lista che nessuno vi legge prima di firmare

Traduciamo i cinque criteri in cose che facciamo tutti i giorni. Non sono ricerca e sviluppo, di norma:

• un gestionale su misura, per quanto complesso e per quanto sostituisca vent'anni di Excel;
• un portale o un'area riservata per clienti e fornitori;
• un e-commerce, anche con logiche di prezzo complicate;
• l'integrazione fra un software nuovo e un ERP esistente, SAP compreso: è lavoro difficile, ma la difficoltà non è incertezza sul risultato;
• una app mobile che porta sul telefono un servizio che già esiste;
• l'adozione di un modello di intelligenza artificiale esistente tramite API, o la messa in produzione di un modello open source con i vostri dati. Configurare bene una tecnologia disponibile è competenza, non ricerca;
• la migrazione di un sistema in cloud;
• gli aggiornamenti, la manutenzione evolutiva, il rifacimento dell'interfaccia.

Può essere ricerca e sviluppo, se i cinque criteri reggono e sono documentati:

• lo sviluppo di un algoritmo nuovo per un problema che allo stato dell'arte non ha una soluzione affermata, dove all'inizio non sapete se funzionerà;
• l'addestramento di un modello su un dominio dove i modelli esistenti falliscono in modo documentabile, con un percorso sperimentale e ipotesi che possono essere smentite;
• la sperimentazione di un'architettura per un vincolo fisico che le soluzioni note non soddisfano — latenza, consumo, banda, funzionamento senza connessione.

La differenza non è quanto è difficile. È se, la mattina in cui si comincia, qualcuno può onestamente dire che non sa se si arriverà in fondo.

Un numero che ridimensiona le aspettative

C'è un dato che vale più di qualunque ragionamento. Nel sistema di certificazione preventiva del MIMIT, su 17.037 progetti presentati risultavano 2.281 progetti software certificati — dato al 12 marzo 2026, riportato da EC News.

Poco più di uno su otto, e parliamo di progetti presentati da imprese che avevano già deciso di provarci, spesso assistite da consulenti specializzati. È il ritratto di una misura molto più selettiva di come viene raccontata nelle riunioni commerciali.

La certificazione: come si compra tranquillità

Dal 2022 esiste uno strumento che riduce il rischio, ed è probabilmente la cosa più utile di questo articolo. L'articolo 23 del decreto legge 73/2022 ha introdotto la certificazione delle attività di ricerca e sviluppo: un certificatore iscritto a un albo tenuto dal MIMIT attesta la corretta qualificazione delle attività rispetto ai criteri di legge.

Il punto non è il pezzo di carta: è che la certificazione si può chiedere prima, in via preventiva. Si scopre che il progetto non è agevolabile mentre si può ancora decidere cosa fare, invece che dopo aver compensato il credito in F24.

Un chiarimento importante, perché è fonte di equivoci: la certificazione riguarda la qualificazione tecnica dell'attività. L'amministrazione finanziaria mantiene il controllo sulla documentazione dei costi e sulla loro congruità. Certificare il progetto non mette al riparo da una contestazione sulle spese.

Il pezzo che riguarda noi: la documentazione si scrive durante, non dopo

Qui arriva la parte in cui un fornitore di software o vi aiuta, o vi complica la vita.

I criteri di sistematicità e trasferibilità non si possono ricostruire a posteriori in modo credibile. Una relazione tecnica scritta a progetto chiuso, con il senno di poi, si riconosce a occhio: descrive un percorso lineare verso un risultato che si sapeva già, cioè esattamente il contrario di quello che deve dimostrare.

Quello che regge una verifica si costruisce mentre si lavora:

• l'obiettivo e le ipotesi scritti prima di cominciare, con l'incertezza dichiarata in modo esplicito — cosa non sapevamo, cosa poteva andare storto;
• lo stato dell'arte al momento di partire: cosa esisteva già, perché non bastava. Con le fonti, non a memoria;
• il registro dei tentativi, compresi quelli falliti. I fallimenti sono la prova migliore che l'incertezza c'era davvero, e sono la prima cosa che sparisce da una relazione scritta dopo;
• la tracciatura delle ore per persona e per attività, separando la parte sperimentale da quella ordinaria dello stesso progetto — perché quasi sempre convivono, e la ripartizione va motivata;
• i risultati in forma trasferibile: documentazione tecnica, specifiche, test riproducibili.

Non è burocrazia aggiuntiva: gran parte è documentazione che un progetto fatto bene produce comunque. Va solo tenuta in una forma che sopravviva a chi la legge tre anni dopo.

Il resto del quadro si è mosso, e va verificato

Fuori dal credito R&S, gli incentivi sui beni strumentali sono stati riscritti. Il piano Transizione 5.0 non è più operativo dal 1° gennaio 2026 e, secondo le ricostruzioni delle testate specializzate, è stato sostituito da un meccanismo di iperammortamento introdotto con la legge 199/2025, che cambia logica: non più credito d'imposta, ma maggiorazione del costo deducibile, con trattamenti differenziati anche per il software.

Volutamente non pubblichiamo qui percentuali e massimali di questa misura. Sono cambiati due volte in due anni, i decreti attuativi si depositano nel tempo, e un numero sbagliato letto su un sito di un fornitore IT è il modo più veloce per prendere una decisione sbagliata. Fatevi dare lo stato aggiornato dal vostro commercialista.

Cosa chiedere a chi vi sviluppa il software

Tre domande, e si capisce con chi si ha a che fare.

«Questo progetto secondo voi è ricerca e sviluppo?» Se la risposta è sì senza esitazione e senza avervi chiesto nulla sullo stato dell'arte, la risposta vale zero. Un fornitore serio in genere dice di no, perché di norma è no.

«Se in una parte del progetto c'è incertezza vera, la sapete isolare e documentare?» Capita che dentro un progetto ordinario ci sia un modulo genuinamente sperimentale. Va separato, tracciato e motivato — e questa è competenza tecnica, non fiscale.

«La relazione tecnica la scrivete voi, e la scrivete mentre lavorate?» È la domanda che separa chi vi accompagna da chi vi lascia soli davanti a una verifica.

Noi la relazione tecnica la scriviamo, perché il progetto lo abbiamo in mano noi e la memoria di cosa non ha funzionato ce l'abbiamo solo noi. La valutazione fiscale — se il credito spetta, in che misura, come si indica in dichiarazione — è del vostro commercialista. Non siamo consulenti fiscali e non promettiamo crediti d'imposta a nessuno: chi lo fa, in un preventivo di software, vi sta vendendo un rischio insieme al prodotto.

Nota sulle fonti

Le aliquote, i massimali e i periodi di vigenza vengono dalla scheda del Ministero delle Imprese e del Made in Italy sul credito d'imposta ricerca, sviluppo, innovazione e design, che rimanda alla legge 160/2019, commi 198-209.

I cinque criteri e le citazioni testuali vengono dal decreto ministeriale del 4 luglio 2024 recante le linee guida, che rinvia al Manuale di Frascati dell'OCSE come previsto dal comma 200.

Il dato sui progetti software certificati (2.281 su 17.037 al 12 marzo 2026) è riportato da EC News sulla base dei dati del sistema di certificazione MIMIT: è una fonte secondaria e come tale va trattata.

Lo stato di Transizione 5.0 e il passaggio all'iperammortamento della legge 199/2025 sono ricostruiti da fonti specializzate concordanti, non da un testo normativo che abbiamo verificato direttamente: è il motivo per cui in questo articolo non trovate cifre su quella misura.

Questo articolo descrive un quadro tecnico e normativo aggiornato ad agosto 2026 e non costituisce consulenza fiscale. Le decisioni sull'accesso a un'agevolazione vanno prese con un professionista abilitato.