Here is the thing that breaks, and you can see it: a client sends me an invoice line that reads "sviluppo software su misura — €48.000". That's it. One line. Then they ask whether it qualifies under Transizione 5.0. And the honest answer is that nobody can tell — not their accountant, not the certifying engineer, not the auditor who will open that file in three years. The invoice is a <div> with an onClick. It might do the right thing, but nothing about it declares what it is.
I write frontend for a living, mostly for small manufacturers in Sicily and Campania who make real objects in real sheds with patchy fibre. Over the last two years I've ended up inside a lot of Transizione 5.0 files, not because I wanted to become a tax person, but because the custom software is the project and the developer is the only one who can describe what it does. So: what's actually eligible, and how do you write it down so it survives an audit.
Transizione 5.0 is not Industria 4.0 with a new number on it. The mechanism is different in one decisive way: the tax credit is tied to a measured reduction in energy consumption produced by an innovation project. You don't get credit for buying a connected machine. You get credit for buying a connected machine that demonstrably burns less energy than the baseline, measured either on the affected process or on the whole production unit.
That distinction is the whole article. It's why custom software behaves so differently here than it did under 4.0, and it's why the way you scope and document a software build matters more than the stack you build it in. The official framing lives on the MIMIT page for the Piano Transizione 5.0, and the 2026 evolution — with the shift toward hyper-amortisation mechanics — is tracked reasonably well in this overview of the 2026 changes.
Two tiers of eligible spend matter for us:
Custom software can qualify in both a supporting and a leading role. What it cannot do is float free of the energy story.
Under Industria 4.0 the intangible-asset annex was a list. If your software matched an item on it, you were broadly fine. Under Transizione 5.0 the logic is relational: software is eligible when it is functionally connected to the innovation project and contributes to the energy reduction being claimed.
In practice this splits custom development into three buckets.
You wrote the control layer for a new line. You wrote the HMI. You wrote the firmware-adjacent supervision that decides when the compressor spins up. This is the easiest case: the software is part of the asset, it's on the same project, and its contribution to consumption is direct and measurable. The interface you build — yes, the frontend — is part of that asset. An operator who can see setpoints and deviations at a glance runs the line closer to optimum than one squinting at a spreadsheet.
This is the category the scheme was practically designed around, and it's explicitly recognised. Custom platforms that acquire consumption data from meters and sensors, normalise it, and present it back for decisions are eligible when they're part of the project. Vendors in the IoT space have built entire offerings around exactly this shape — see the way Optimo IoT frames its Transizione 5.0 monitoring stack, which is a decent map of what the required data path looks like: field acquisition, gateway, time-series store, dashboard, reporting.
What auditors want to see here is not elegance. It's traceability: which meter, at which sampling interval, feeding which aggregation, producing which number in the ex-ante and ex-post certification.
MES, ERP modules, planning and scheduling tools — these are eligible when they carry an explicit sustainability or energy-efficiency function and are acquired alongside an eligible tangible asset. A scheduler that batches jobs to flatten peak demand qualifies on its function. A generic CRM does not, no matter how bespoke. The line is drawn well in this comparison of 4.0 and 5.0 treatment of custom software.
The 2026 framing has pulled artificial intelligence explicitly into the eligible perimeter, and I'd like to gently ask everyone to calm down. A predictive model that forecasts thermal load and pre-conditions a furnace is eligible because of what it does to the kWh figure, not because it contains a neural network. A chatbot bolted onto the intranet is not eligible because you called it AI in the invoice.
The practical test is the same one you'd apply to any feature: can you state the causal chain from the code to the meter? If the sentence needs three hedges to get from model output to consumption reduction, the certifier will notice. The admissibility boundaries for AI spend are laid out in reasonable detail in this breakdown of eligible AI software costs for 2026.
Plenty of manufacturers build in-house. Internal software development can be capitalised and included, but the evidentiary bar is higher than for a supplier invoice, and this is where projects fall apart.
What you need, from day one and not reconstructed in month eleven:
I'll self-roast here. On my first 5.0-adjacent project I insisted on a beautifully abstracted plugin architecture for the monitoring dashboard, three layers deep, because I was going to support "any meter protocol". The auditor asked which physical meter produced the number in cell B14 of the ex-post report. It took me two hours to answer, through my own abstraction. The second project used a flat, boring adapter per meter with the serial number in the filename. Ten seconds to answer. Documentation is a runtime concern.
A recurring question: is a subscription eligible? Generally the scheme wants capitalisable assets, which means perpetual licences, purchased custom builds, and multi-year contracts that get recorded as intangible assets on the balance sheet. A month-to-month SaaS fee expensed as an operating cost sits awkwardly. This is an accounting question more than a technical one, but it changes how you should structure the commercial offer — and it's worth resolving before you quote, not after. The practical implications for software vendors are discussed in this guide to Industria 5.0 software.
The certification process runs in two passes — ex ante, before you start, projecting the reduction; ex post, after commissioning, proving it. Both are produced by an independent certifier. Your software documentation feeds both. A clean structure:
A step-by-step walkthrough of the procedural side — booking, communications, timing — is set out in this complete guide to the scheme, and the incentive-tier arithmetic is summarised in Infocad's 2026 overview.
Nearly every one of these projects ships a dashboard, and nearly every one of them ships it with a colour-coded status grid, green and red, no text label, contrast ratio around 2.4:1 on a screen mounted under a factory skylight. The operator on the floor is fifty-five, wears safety glasses, and may well be one of the roughly eight percent of men with a colour vision deficiency. Your energy-efficiency gain depends on that person reading the number and acting on it.
So: put the state in text as well as colour, get the contrast above 4.5:1, size the type for a two-metre viewing distance, and make sure the whole thing is operable from a keyboard because touchscreens in industrial environments get used with gloves and fail. This isn't a nice-to-have appended to the funding project. It's the difference between a dashboard that changes behaviour and a dashboard that becomes wallpaper — and the ex-post measurement will tell you which one you built.
Custom software is eligible under Transizione 5.0 when it is part of an innovation project and you can trace a line from what it does to a kWh figure someone measured. Write that line down before you write the code. Itemise the invoice. Keep the repo. Then go check the contrast on your dashboard.
