The latest revision of the Agenzia delle Entrate framework moves Italy’s software-based receipt model further from architectural design and closer to everyday retail operation, with changes touching meal vouchers, connection timing, commercial documentation, cloud deployment and certification.
Italy’s software-fiscalization project is entering a more practical phase. The technical package under review is identified as version 1.4 of the specifications for the Soluzione Software model, the framework that allows electronic storage and transmission of daily retail receipts to be performed through approved software rather than only through the traditional hardware-centered Registratore Telematico model. The significance of the latest revision lies less in a new architecture than in the steady removal of ambiguities that become expensive once a specification reaches real stores, real payment flows and real multi-country retail systems.
The legal foundation remains Article 24 of Legislative Decree No. 1/2024, which permits software solutions to perform the electronic storage and telematic transmission of anonymous daily receipt data provided that security and immutability are guaranteed. The same provision requires the software model to support integration and interaction between receipt registration and electronic payment processes, while the detailed implementation rules are delegated to the Agenzia delle Entrate. The Revenue Agency’s measure No. 111204 of 7 March 2025 then established the operating framework, including the roles of the Produttore, Erogatore and Esercente, as well as the two-part architecture built around the Punto di Emissione and Punto di Elaborazione.
That architecture is important for retailers because it represents a genuine shift in where Italian fiscalization can live. The first component, commonly described as MF1 and associated with the Punto di Emissione, can operate on a physical or virtual environment such as a POS, tablet, SmartPOS, PC or virtual machine. The second component, MF2 at the Punto di Elaborazione, is responsible for secure central processing, storage and communication with the Revenue Agency. From an enterprise-architecture perspective, Italy is therefore moving toward a model in which fiscal execution can become a software service while the legal control framework remains tightly governed.
From version 1.0 to an implementation-grade specification
The version history shows a specification being hardened in stages. The original version 1.0, dated February 2025 and attached to the March 2025 Revenue Agency measure, established the core actors, components and lifecycle. Version 1.1 was publicly documented in June 2025, when additional material described the MF1 and MF2 structure and expanded the technical package around APIs and operational flows. By December 2025, version 1.2 had introduced a more explicit qualification requirement for Providers, including valid ISO certifications, while also refining activation-seed initialization, hash-code formats and several technical paths and textual inconsistencies.
The Revenue Agency continued changing the implementation package in 2026. An April update revised several technical documents and attachments used for receipt transmission and software-solution integration, which is a reminder that the main specification is only one part of the compliance surface. XML schemas, response structures, activation flows and supporting documents can change independently, and a software provider that watches only the headline version number can still miss an implementation-relevant change.
Version 1.4 continues that progression. The change set supplied for this review concentrates on meal-voucher handling, connection deadlines, removal of a QR-code requirement, management-document rules, cloud-architecture scenarios and the scope of ISO certification. These are not cosmetic subjects. They sit exactly where a conceptual fiscal architecture meets the operating reality of restaurants, retailers, SaaS providers and large distributed store estates.
Meal vouchers expose the difference between payment and fiscal treatment
Meal vouchers are a deceptively difficult retail case because they look like a payment method at the checkout while their fiscal treatment does not necessarily follow the same logic as cash or a card payment. The version 1.4 update brings this area into sharper focus for the software-solution model, reducing the risk that a POS team simply maps a meal voucher into a generic tender type and assumes that the fiscal result follows automatically.
The practical consequence for software providers is that payment semantics and fiscal semantics need to remain distinguishable in the transaction model. Large retailers and hospitality operators routinely support mixed tender, partial payment and multiple voucher issuers, so the implementation needs to preserve enough information for the fiscal layer to apply the Italian treatment without forcing the checkout application to become a collection of country-specific exceptions. The change also deserves careful separation from the parallel Registratore Telematico specifications, because the separate RT version 11.2 released in 2026 also introduced new meal-voucher handling. The two specification tracks address related retail behavior but govern different fiscal architectures.
Connection timing becomes an operational requirement, not an architecture diagram
The clarification of connection deadlines is another sign that the framework is moving toward production use. In a distributed software model, it is not enough to state that a Punto di Emissione communicates with a Punto di Elaborazione and that the latter communicates with the Revenue Agency. Retail systems need deterministic behavior when a connection is delayed, unavailable or restored, because timing affects queues, local state, monitoring, retries and the moment at which a transaction can be regarded as fiscally complete.
The latest revision therefore matters for POS vendors and fiscal providers even where it does not require a visible change at the checkout. Connection windows and deadlines become part of the state machine behind the transaction, and they need to be reflected in retry logic, exception handling, monitoring thresholds and support procedures. For international retailers this is particularly important because the temptation to reuse a generic offline model across countries is strong, while fiscal rules normally define the permitted contingency behavior locally.
Removing QR-code friction simplifies the physical edge
The reported removal of a QR-code requirement is a small change with a disproportionately practical effect. Earlier descriptions of the software model included QR-code-related identification at the point of emission, which introduced another physical or visual artifact into a framework whose strategic attraction is precisely the possibility of moving fiscalization away from dedicated fiscal hardware. Removing that requirement, where the new version now permits it, makes the software model more consistent with a device-light architecture and reduces rollout work across large estates.
This does not reduce the need for identification, traceability or control. It changes the mechanism. In a mature software architecture, identity should be carried through cryptographic credentials, registered endpoints, system metadata and auditable lifecycle records rather than through a label that becomes another item to print, distribute, place and maintain in thousands of stores.
Management documents need a clean border around fiscal documents
The version 1.4 treatment of management documents is equally relevant for real retail software. Modern POS systems create many outputs that are operationally useful but are not themselves the fiscal commercial document, including internal summaries, kitchen or service documents, courtesy outputs, order information and other management records. Once software fiscalization becomes embedded directly into a POS or cloud commerce stack, the distinction between a fiscal document and a management document must be unmistakable to the operator, the customer and an auditor.
The latest clarification should therefore be read as part of a broader design principle. Fiscal software needs explicit document types and explicit lifecycle states rather than relying on visual similarity or printer behavior to communicate legal meaning. This becomes even more important in omnichannel environments where a document may be displayed on screen, sent electronically, printed on a non-fiscal printer or consumed by another application before it reaches the customer.
Cloud architecture is becoming part of the expected design space
The cloud-related clarifications are among the most strategically important parts of the current revision because the original architecture was already deliberately technology-neutral. Contemporary explanations of the March 2025 specification noted that both the Punto di Emissione and Punto di Elaborazione could be implemented on physical or virtual systems, including local or cloud virtual machines, while the PEL communicates with the Revenue Agency through APIs. Version 1.4 appears to make those deployment scenarios more explicit rather than turning cloud into a mandatory topology.
That distinction matters. A central cloud PEL can give a retailer or provider one operational view across many stores, simpler release management and a common monitoring layer, while the PEM can remain close to the transaction where local resilience or peripheral access requires it. A hybrid arrangement is therefore not a compromise in the negative sense; it can be the natural architecture for a country that wants software-based fiscalization without pretending that every store, network and checkout environment behaves like a permanently connected web application.
ISO certification moves from a checkbox toward a defined responsibility boundary
Certification is another area where the specification has become progressively more precise. Version 1.2 explicitly broadened the requirement so that Providers were expected to hold valid ISO certificates, while the March 2025 measure already placed a lifecycle obligation on the Producer to maintain the certifications submitted with the approval request. The version 1.4 update reportedly refines the scope of those certification requirements, which is important because an ISO certificate is meaningful only when its certified scope actually covers the organization, services and systems that perform the regulated function.
For providers, the practical issue is therefore not simply possession of a certificate but alignment between the certified management system and the fiscal service being offered. Changes in hosting model, subcontracting, organizational responsibility or the boundary between Producer and Provider can affect that alignment, so certification belongs in product governance and vendor governance rather than in a one-time approval checklist.
The business impact is controlled change, not the elimination of fiscal complexity
For retailers, the direction of travel remains attractive. A certified software approach can reduce dependence on dedicated fiscal hardware, support more modern POS and mobile architectures and make central monitoring easier, particularly for large store networks. It can also allow country-specific fiscal execution to sit behind a more stable retail-facing interface, which is where the largest long-term savings normally appear in international environments.
The successive revisions also show why software fiscalization should not be interpreted as fiscalization becoming simple. Complexity is moving from a physical device into software lifecycle management, provider qualification, cryptographic identity, version control, availability design, evidence and certification. That can still be a major improvement, but only when retailers and vendors treat the fiscal layer as controlled system software rather than as an API connector that can be installed once and forgotten.
The March 2025 Revenue Agency measure makes that point explicit by requiring the Producer to maintain the solution and provide the updates needed to keep it aligned with security requirements, fiscal law and the technical specifications in force. Version 1.4 is therefore not merely another document for development teams to read. It is part of the operating contract of the solution, and every approved implementation will need a disciplined way to identify the delta, assess impact, test the affected flows and release the change without destabilizing checkout operations.
A specification that is converging on retail reality
Italy’s software-solution initiative started with a broad policy objective: allow secure software to perform a fiscal function that had long been associated with certified physical devices. The original version established the architecture, subsequent revisions strengthened APIs, cryptographic details and provider requirements, and the current version is increasingly occupied with the exceptions and operational boundaries that determine whether a model works outside a laboratory.
That evolution is healthy, even if it creates work for vendors. Meal vouchers, timing rules, document classification, endpoint identification, cloud deployment and certification scope are the kinds of details that decide whether a theoretically elegant fiscal architecture can survive a busy store, a network interruption, a mixed-payment transaction and a multinational rollout. Version 1.4 moves the Italian software-fiscalization model further in that direction, while also making clear that the final cost advantage will depend on disciplined implementation and governance as much as on the absence of a dedicated fiscal box at the checkout.
Sources and document links
1. LATEST VERSION / OFFICIAL REPOSITORY: Agenzia delle Entrate, “Specifiche tecniche e allegati per l’invio dei corrispettivi – Soluzione Software” – official repository for the current technical package, including the version 1.4 material under review.
2. PREVIOUS PUBLICLY VERIFIABLE MAIN-SPEC VERSION: Fiscal Solutions, “Update of the technical specification regarding software solution for fiscalization in Italy” – documents version 1.2 and its changes, validated 10 December 2025.
