It happens at every quote of any size. You get to the figure, the room goes quiet, and then somebody — sometimes the accountant, more often a friend who heard it somewhere — says the sentence that unblocks the signature: "it's R&D anyway, you'll get part of it back."
In the great majority of cases that sentence is wrong. And the worst moment to find out is three years later, when an audit lands and the offset credit has to be paid back with penalties and interest.
It is worth understanding how this actually works, because the line between a claimable project and one that isn't has nothing to do with the budget, and not much to do with technical difficulty either. It sits in five precise criteria that almost nobody reads before signing.
What is still standing in 2026
Before the criteria, the perimeter. The tax credit introduced by Italy's 2020 budget law (law 160/2019, paragraphs 198-209) is not one measure: it is four different measures under one name, and in 2026 they are not all still alive.
According to the Ministry of Enterprise and Made in Italy, what remains in force is research and development in the strict sense — fundamental research, industrial research, experimental development — at a rate of 10% with an annual cap of 5 million euro, running through the 2031 tax period.
The other three doors closed earlier. Technological innovation, 4.0 and green technological innovation, and design and aesthetic ideation were available through the 2025 tax period.
That detail looks bureaucratic, but for anyone building software it is the heart of the story. Technological innovation was the wide door: it asked for a product or process that was new or substantially improved relative to the company's own, a bar a well-built management system could plausibly clear. Research and development asks for much more, and asks you to prove it. From 2026 only the narrow door is left.
The five criteria, and what they mean for people who write code
The application criteria were set by the ministerial decree of 4 July 2024, which in turn points to the principles of the OECD Frascati Manual — a reference written into the law itself, at paragraph 200. The guidelines set out five criteria, and they have to hold all at once: it is not a score, it is a chain.
Novelty. The activity must aim at new discoveries or new results and knowledge applicable to products and processes "not already widespread in the sector of reference". Watch the yardstick: not new to your company, new to the sector. A management system that changes the working life of twenty people inside your building is not novel in this sense if something equivalent is already on the market outside it.
Creativity. The objective must be the creation of concepts or ideas that improve "the state of the art representing existing knowledge". The state of the art is the public, documentable one — not the one inside your IT department.
Uncertainty. This is the criterion that cuts deepest, and the most honest one: the guidelines state that in R&D, from the very start of a project, the type of result and the costs "cannot be determined with certainty". Put bluntly: if we gave you a fixed-price quote with a delivery date, we have just certified in writing that the uncertainty was not there. A serious supplier delivers you a predictable project — which is precisely why that project is not research.
Systematicity. The work must be conducted "in a planned way, with a formalisation of the objective pursued". Here the ball comes back to both of us: without an objective written down beforehand and the work tracked as it happens, the criterion cannot be demonstrated even when it is true.
Transferability and reproducibility. The project should involve a potential transfer of the new knowledge and allow others to reproduce the results. Know-how that lives in the heads of two developers is by definition not transferable.
The guidelines contain no chapter dedicated to software, and that in itself is informative: software development follows the general rules. "Ordinary or periodic changes" to existing products, production lines, manufacturing processes and services stay excluded, and so does routine activity, which the guidelines describe by "the absence of creativity, of original ideas and of uncertainty".
The list nobody reads to you before you sign
Translating the five criteria into things we all do every day. These are not research and development, as a rule:
- a custom management system, however complex, and however many years of spreadsheets it replaces;
- a portal or a customer and supplier area;
- an e-commerce site, even with complicated pricing logic;
- integrating new software with an existing ERP, SAP included: hard work, but difficulty is not uncertainty about the outcome;
- a mobile app that brings an existing service onto a phone;
- adopting an existing AI model through an API, or putting an open-source model into production with your data. Configuring an available technology well is competence, not research;
- migrating a system to the cloud;
- updates, evolutionary maintenance, redesigning the interface.
These can be research and development, if the five criteria hold and are documented:
- developing a new algorithm for a problem with no established solution in the state of the art, where at the outset you do not know whether it will work;
- training a model on a domain where existing models demonstrably fail, along an experimental path with hypotheses that can be disproved;
- experimenting with an architecture for a physical constraint that known solutions do not meet — latency, power draw, bandwidth, operating without connectivity.
The difference is not how hard it is. It is whether, on the morning you start, someone can honestly say they do not know if you will get there.
A number that puts expectations back in place
There is one figure worth more than any amount of reasoning. In the ministry's advance certification system, out of 17,037 projects submitted, 2,281 software projects had been certified — data as at 12 March 2026, reported by EC News.
Barely more than one in eight, and these are projects submitted by companies that had already decided to try, often with specialist advisers alongside them. It is the portrait of a measure far more selective than the way it gets described in sales meetings.
Certification: how you buy some peace of mind
Since 2022 there has been an instrument that reduces the risk, and it is probably the most useful thing in this article. Article 23 of decree-law 73/2022 introduced certification of research and development activities: a certifier on a register held by the ministry attests that the activities have been correctly qualified against the statutory criteria.
The point is not the piece of paper: it is that certification can be requested in advance. You find out that the project does not qualify while you can still decide what to do, rather than after offsetting the credit against your tax bill.
One clarification, because it causes confusion: certification concerns the technical qualification of the activity. The tax administration keeps its control over cost documentation and whether those costs are reasonable. Certifying the project does not shield you from a challenge on the expenses.
The part that is on us: documentation is written during, not after
This is where a software supplier either helps you or makes your life harder.
Systematicity and transferability cannot be credibly reconstructed after the fact. A technical report written once the project has closed, with hindsight, is recognisable at a glance: it describes a straight line towards a result that was known all along — the exact opposite of what it is supposed to demonstrate.
What survives an audit is built while the work happens:
- the objective and the hypotheses written down before starting, with the uncertainty stated explicitly — what we did not know, what could go wrong;
- the state of the art at the moment of starting: what already existed, why it was not enough. With sources, not from memory;
- the log of attempts, including the failed ones. Failures are the best evidence that the uncertainty was real, and they are the first thing that disappears from a report written afterwards;
- hours tracked by person and by activity, separating the experimental part from the ordinary part of the same project — because they almost always coexist, and the split has to be justified;
- results in transferable form: technical documentation, specifications, reproducible tests.
None of this is extra bureaucracy: most of it is documentation a well-run project produces anyway. It just has to be kept in a form that survives being read by a stranger three years later.
The rest of the picture has moved, and needs checking
Outside the R&D credit, incentives on capital goods have been rewritten. The Transizione 5.0 plan has not been operational since 1 January 2026 and, according to consistent reporting in the specialist press, has been replaced by a super-depreciation mechanism introduced by law 199/2025, which changes the logic: no longer a tax credit but an uplift to the deductible cost, with different treatment for software among other categories.
We deliberately do not publish rates and caps for that measure here. They have changed twice in two years, implementing decrees settle over time, and a wrong number read on an IT supplier's website is the fastest route to a bad decision. Get the current position from your accountant.
What to ask the people building your software
Three questions, and you will know who you are dealing with.
"Do you think this project is R&D?" If the answer is yes without hesitation and without anyone asking you about the state of the art, the answer is worth nothing. A serious supplier usually says no, because usually it is no.
"If part of the project does carry real uncertainty, can you isolate and document it?" It happens that an ordinary project contains a genuinely experimental module. It has to be separated, tracked and justified — and that is technical competence, not tax advice.
"Do you write the technical report, and do you write it as you work?" That is the question that separates the supplier who stands next to you from the one who leaves you alone in front of an audit.
We write the technical report, because we are the ones holding the project and we are the only ones who remember what did not work. The tax assessment — whether the credit is due, at what level, how it goes into the return — belongs to your accountant. We are not tax advisers and we promise tax credits to nobody: anyone who does that inside a software quote is selling you a risk along with the product.
A note on sources
Rates, caps and periods come from the Ministry of Enterprise and Made in Italy's page on the research, development, innovation and design tax credit, which refers back to law 160/2019, paragraphs 198-209.
The five criteria and the quoted passages come from the ministerial decree of 4 July 2024 setting out the guidelines, which refers to the OECD Frascati Manual as required by paragraph 200.
The figure on certified software projects (2,281 out of 17,037 as at 12 March 2026) is reported by EC News on the basis of data from the ministry's certification system: it is a secondary source and should be treated as one.
The status of Transizione 5.0 and the shift to the super-depreciation regime under law 199/2025 are reconstructed from consistent specialist sources, not from a statutory text we verified directly — which is why you will find no figures for that measure in this article.
This article describes a technical and regulatory picture current as at August 2026 and does not constitute tax advice. Decisions about claiming an incentive should be taken with a qualified professional.