{"id":143186,"date":"2026-04-28T07:19:53","date_gmt":"2026-04-28T07:19:53","guid":{"rendered":"https:\/\/darkopavic.xyz\/?p=143186"},"modified":"2026-04-26T07:24:40","modified_gmt":"2026-04-26T07:24:40","slug":"italian-software-fiscalization-why-the-technical-requirements-are-more-complex-than-they-look","status":"publish","type":"post","link":"https:\/\/darkopavic.xyz\/index.php\/2026\/04\/28\/italian-software-fiscalization-why-the-technical-requirements-are-more-complex-than-they-look\/","title":{"rendered":"Italian Software Fiscalization: Why the Technical Requirements Are More Complex Than They Look"},"content":{"rendered":"\n
\n

The key message: Italy is not simply asking for \u201creceipt transmission software.\u201d It is asking for a certified, distributed fiscal control system.<\/strong><\/p>\n<\/blockquote>\n\n\n\n

Italy\u2019s new technical specification for software fiscalization should not be read as a simple interface document. It is a blueprint for a regulated fiscal infrastructure. For a POS software vendor, it may look at first like another country-specific compliance project. For a retailer, it may look like a way to replace physical fiscal devices with software. Both views are too small.<\/p>\n\n\n\n

The Italian model creates a complete system around the sale. It defines where the fiscal software sits, how the sale is signed, how documents are chained together, how data moves from the store to the central processing layer, how the tax authority can audit it, how the software version is identified, and how the system must behave when something goes wrong. This is why the project is technically demanding. It is software, but it is expected to behave with the discipline of certified fiscal hardware.<\/p>\n\n\n\n

The official architecture is built around two modules. MF1 is installed on a device or hardware system such as a POS, PC, tablet, or similar device. Together with that device, it becomes the Punto di Emissione, or PEM. The PEM is the part that records the fiscal transaction, issues the commercial document, manages lottery flows, sends data to the PEL, and allows consultation of stored data. MF2 is installed on any hardware system or in the cloud that can communicate by web service with Agenzia delle Entrate. Together with that hardware\/cloud environment, it becomes the Punto di Elaborazione, or PEL. The PEL prepares and sends daily XML files, stores transaction details over time, manages lottery flows, and supports extraction of detailed data for inspections.<\/p>\n\n\n\n

This separation is the foundation of the complexity. The PEM is close to the sale. The PEL is close to the authority, the long-term archive, and the audit process. The challenge is making both behave as one approved fiscal system.<\/p>\n\n\n\n

Where PEM and PEL Should Be Installed<\/h1>\n\n\n\n

The location question is one of the first architectural decisions. It is also one of the easiest places to make a wrong assumption.<\/p>\n\n\n\n

The PEM should be understood as a local fiscal emission component. The specification says MF1 must be installed on a device or hardware system, such as a POS, PC, tablet, or similar device. It also requires the PEM to support the physical location of use, which corresponds to the address of the commercial establishment. That location is then reflected in the commercial document and in the Journal. In practical terms, the safest interpretation is that the PEM must be tied to the point of sale environment where the sale is made. It can be a POS device, a tablet, a mobile POS, a PC, or possibly a local in-store fiscal node, but it should not be treated as a generic cloud service serving many unrelated stores.<\/p>\n\n\n\n

The specification also says that each cash point must be connected to a single PEM. One PEM can serve more cash points only when all those cash points are in the same store location and do not operate independently from the PEM. This is important for retailers with large stores. It suggests that a local store-level PEM may be possible, but a central cloud PEM for many stores would be difficult to defend unless the authority or the certification process explicitly accepts that design.<\/p>\n\n\n\n

The PEL is different. The PEL is a processing component installed on a system able to communicate with the tax authority through web services. It is responsible for transmission, storage, audit extraction, and central orchestration. This makes it more natural for a cloud, data center, or centrally managed server architecture. The specification even discusses cases where the PEM is physically distinct from the PEL. That reinforces the practical reading: PEM belongs near the fiscal event; PEL can be central, provided the approved solution, security rules, service levels, and data guarantees are respected.<\/p>\n\n\n\n

A safe architecture for most vendors is therefore simple to describe: keep MF1\/PEM local to the store, sales device, or in-store fiscal environment, and place MF2\/PEL in a controlled central or cloud infrastructure. The compliance risk increases when the PEM is moved away from the place where the sale is made.<\/p>\n\n\n\n

The Twelve Technical Complexity Points<\/h1>\n\n\n\n

1. PEM-PEL architecture: one fiscal system, two technical centers<\/h2>\n\n\n\n

The first complexity is the split architecture itself. The PEM and PEL are not optional modules. They are tightly connected parts of one approved solution. The PEM records the transaction and issues the document, while the PEL receives transaction details, creates daily files, sends data to Agenzia delle Entrate, stores fiscal data, handles lottery flows, and supports audit extraction. This creates a distributed fiscal system with shared responsibility. A fiscalization solution vendor must design not only the transaction screen, but also synchronization, message confirmation, state management, local storage, central storage, retry behavior, and audit matching. In a normal retail system, these are operational topics. In this model, they become fiscal topics.<\/p>\n\n\n\n

2. Hash chains and the Journal: the real integrity engine<\/h2>\n\n\n\n

The heart of the system is the Journal and its hash chain. For each signed commercial document, the solution must calculate a SHA-256 hash and transform it into Base64. The Journal records document data, hashes of the documents issued during the day, and links with the previous Journal and the previous daily corrispettivi file. The result is a chain of evidence. If someone changes a document later, the chain should reveal the inconsistency. For developers, this means the Journal is not a log file in the normal software sense. It is a fiscal object. Its sequence, timing, signing, references, and recovery behavior must be precise.<\/p>\n\n\n\n

3. Opening, closing, and change-of-day logic<\/h2>\n\n\n\n

The Italian requirement recognizes that retail life does not always end at midnight. Restaurants, petrol stations, entertainment venues, airports, and large stores may operate across calendar days. The PEM must manage cash opening, transaction recording, Journal creation, and closure. Closure must happen within 24 hours from opening. If the closure happens after midnight, the system must correctly identify the change of day inside the Journal. The PEL then needs to create daily corrispettivi files that may refer to the same Journal but only include the correct section for each fiscal day. This is technically hard because the business day, accounting day, calendar day, and VAT period can diverge.<\/p>\n\n\n\n

4. Offline mode and automatic blocking<\/h2>\n\n\n\n

The system must continue to protect fiscal integrity when communication fails. The PEM can operate for a limited time without successful communication to the PEL, but it must keep the necessary data, warn the user, close the cash session when required, and block MF1 activity if the maximum allowed condition is exceeded. When communication returns, it must transmit the missing signed XML files, the Journal, and an anomaly notification that explains the period of missing communication. This creates a delicate balance. The retailer wants business continuity. The authority wants control. The software must support both, without creating a hidden channel for unreported sales.<\/p>\n\n\n\n

5. Secure certificate and private key management<\/h2>\n\n\n\n

Digital certificates sit at the center of the model. The PEM signs commercial documents, Journal files, and lottery files. The PEL signs transmissions and communicates with the authority. The private keys must be protected, not casually stored like ordinary application secrets. This moves the project into the world of secure key storage, certificate lifecycle, controlled renewal, revocation, and non-exportability. For a POS vendor used to cloud credentials, this may be a major change. The fiscal certificate is not only a technical credential. It is part of the legal identity of the fiscal process.<\/p>\n\n\n\n

6. Security perimeter and mutual authentication<\/h2>\n\n\n\n

The specification defines a security perimeter for communication among the components and with Agenzia delle Entrate. The PEL uses TLS 1.2 and mutual authentication with X.509 certificates for the connection to the authority. External API calls also require TLS 1.2 and mutual authentication. The PEM communicates with the PEL through a private exchange protocol that must protect integrity, authenticity, and non-repudiation. This creates several security paths: POS to PEM, PEM to PEL, PEL to Agenzia, external software to fiscal APIs, and Agenzia back to the PEL for audit requests. Each path has to be designed, tested, monitored, and documented.<\/p>\n\n\n\n

7. API equivalence with the approved fiscal user interface<\/h2>\n\n\n\n

The specification allows fiscal functions to be exposed through REST or SOAP APIs. But there is a strong condition: those APIs must replicate exactly the same fiscal functions and controls as the approved user interface. The native MF1 user interface must also remain available to the merchant and to inspectors. This prevents a vendor from building a strict certified interface for approval and then allowing another software layer to bypass controls through APIs. In simple terms, the API cannot become a back door. For modern POS ecosystems, where many modules call each other through services, this is a significant design constraint.<\/p>\n\n\n\n

8. Audit services and real-time inspection support<\/h2>\n\n\n\n

The system must be ready for inspection. In an on-site check, the merchant may be asked to close the cash session. Inspectors can request data stored in the PEM for the previous 48 hours, or a shorter period. In parallel, the authority can ask the PEL for the same detailed data. The purpose is to compare what the PEM recorded with what the PEL stored. This is a very important requirement because it turns the architecture into an audit mirror. The PEM and PEL must agree. Data must be searchable. Time stamps, hashes, documents, and reports must match. A system that transmits correctly but cannot support fast audit extraction is not complete.<\/p>\n\n\n\n

9. Anomaly reporting: logs become fiscal signals<\/h2>\n\n\n\n

In many software systems, errors are internal operational logs. In the Italian model, anomalies become regulated fiscal events. The PEM and PEL must detect and report connection errors, integrity errors, hash-chain problems, communication failures, and inactivity periods. The PEL must aggregate and transmit anomaly reports to Agenzia delle Entrate at least once per day, separately from the fiscal corrispettivi data. This means monitoring, error classification, XML generation, audit explanation, and customer support must be part of the fiscal product. A wrong anomaly strategy can create inspection risk, even when the sales data itself is correct.<\/p>\n\n\n\n

10. Ordinary and instant lottery integration<\/h2>\n\n\n\n

The lottery requirements add a second layer of logic to document generation. For ordinary lottery flows, the PEM prepares and signs the lottery XML and sends it through the PEL. For instant lottery flows, the PEM must request secret codes, store them securely, and use them to produce the two-dimensional code when the conditions are met. The PEL acts as a bridge and does not inspect the signed XML content. The business rule details matter. If a valid instant lottery code is not available, documents are still issued, but without the lottery code. If the document is a \u201cscontrino parlante,\u201d the field used for tax deduction is alternative to the lottery code. This is an example of how a secondary public policy requirement directly changes the fiscal receipt workflow.<\/p>\n\n\n\n

11. Returns and cancellations<\/h2>\n\n\n\n

Returns and cancellations are among the most complex parts of retail fiscalization because they combine legal control with real store behavior. The PEM must support returns and cancellations for documents issued by the same PEM, but also manual cases where the original document was issued by another device or where other proof of purchase is used. The system must validate references, VAT capacity, document identity, original device identity, and manual data entry. A return is not merely a negative sale. It is a new fiscal document connected to a prior event. In a multinational retail environment, this area needs very careful design because store staff need simplicity, while the fiscal rules require traceability.<\/p>\n\n\n\n

12. Approval, certification, version control, SBOM, and SWID<\/h2>\n\n\n\n

The final complexity is the product lifecycle. The solution must be approved by Agenzia delle Entrate after certification and review. The Erogatore must pass interoperability tests and show valid ISO 9001 and ISO 27001 certifications. The solution must have a unique identifier, version identity, SWID identification, and integrity self-analysis on both PEM and PEL. The self-analysis must verify components listed in the SBOM. This is a modern software supply-chain requirement inside a fiscal regulation. It means the vendor must know exactly which software version and which components produced the fiscal data. Release management, DevOps, dependency control, security management, and regulatory approval become one process.<\/p>\n\n\n\n

What This Means for POS Vendors<\/h1>\n\n\n\n

For POS software vendors, the Italian model is not a small localization layer. It touches core architecture. The POS cannot simply send receipt data to a fiscal endpoint and consider the transaction compliant. It must integrate with an approved MF1\/PEM that controls document issuance, signing, numbering, state, lottery handling, offline behavior, local consultation, and interaction with the PEL. If the POS calls fiscal APIs, those APIs must follow the same rules as the approved fiscal interface.<\/p>\n\n\n\n

The practical lesson is to separate commercial flexibility from fiscal control. The POS can still manage promotions, baskets, pricing, loyalty, returns, and customer experience. But once a transaction enters the fiscal path, the approved PEM rules must dominate. Any attempt to keep fiscal logic spread across many POS modules will make certification, testing, and support more difficult.<\/p>\n\n\n\n

What This Means for Fiscal Solution Vendors<\/h1>\n\n\n\n

For fiscal solution vendors, Italy creates both a challenge and an opportunity. The challenge is clear: the provider must deliver a full fiscal infrastructure, not just a middleware connector. The opportunity is equally clear: many retailers and POS vendors will not want to build this alone. They will need a partner who understands the architecture, approval process, certificates, secure storage, Journal logic, PEL services, anomaly handling, audit flows, and version management.<\/p>\n\n\n\n

The most valuable product will not be the one that only passes tests. It will be the one that remains stable in real retail conditions: weak connectivity, late closing, store migrations, returns, software updates, certificate renewals, support tickets, inspections, and integration with many POS systems. The difference between a technical implementation and a market-ready fiscal platform will appear in these edge cases.<\/p>\n\n\n\n

What This Means for Retailers<\/h1>\n\n\n\n

For retailers, especially international retailers, the key decision is whether to build, buy, or partner. Building internally may look attractive for large retailers with strong technology teams. But the Italian requirements show that this is not only an engineering project. It is also a certification project, an operational project, a security project, and a long-term compliance project.<\/p>\n\n\n\n

Retailers should ask practical questions before starting. Where will the PEM run in every store format? Who owns the PEL? Who manages certificates? How will stores operate when the connection is unstable? What happens during inspection? How will software updates be controlled? How will the retailer prove which version was installed and which components were active? These questions should be answered before development begins, not during certification.<\/p>\n\n\n\n

The Strategic View<\/h1>\n\n\n\n

Italy is moving fiscalization from dedicated hardware toward software, but it is not removing control. In some ways, it is increasing control. The new model expects software to offer the same trust as a fiscal device while adding digital traceability, central storage, audit services, supply-chain visibility, and controlled communication between distributed components.<\/p>\n\n\n\n

That is why the most important sentence for decision-makers is simple: Italian software fiscalization is not a receipt project. It is a fiscal infrastructure project. The winning solutions will be designed from the beginning around integrity, auditability, secure identity, operational resilience, and certification. Vendors who treat it as a normal POS integration will underestimate it. Retailers who treat it as a cost-saving shortcut will also underestimate it. The companies that understand its architecture early will have a strong advantage.<\/p>\n\n\n\n

Simple Architecture Summary<\/h1>\n\n\n\n
Component<\/strong><\/td>Practical location<\/strong><\/td>Main role<\/strong><\/td><\/tr>
PEM \/ MF1<\/td>Local to the point of sale environment: SmartPOS, POS PC, tablet, or in-store fiscal node.<\/td>Records the fiscal sale, issues the commercial document, signs files, manages local data, lottery flows, and communication to PEL.<\/td><\/tr>
PEL \/ MF2<\/td>Central server, data center, or cloud architecture, if approved and secured.<\/td>Receives PEM data, generates and transmits daily XML files, stores fiscal data, manages audit requests and lottery transport.<\/td><\/tr>
Agenzia delle Entrate<\/td>External authority system.<\/td>Receives transmissions, manages approval and accreditation processes, and can request audit data through defined services.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n

Source Notes<\/h1>\n\n\n\n

This article is based on the attached \u201cSpecifiche Tecniche v.1.3 – Soluzione Software per la memorizzazione e la trasmissione telematica dei corrispettivi.\u201d<\/a><\/p>\n\n\n\n

This document is an analytical business and technical article. It is not legal advice. Any implementation should be validated against the final official documents, the relevant annexes, the certification process, and direct guidance from the competent Italian authorities.<\/p>\n","protected":false},"excerpt":{"rendered":"

The key message: Italy is not simply asking for \u201creceipt transmission software.\u201d It is asking for a certified, distributed fiscal control system. Italy\u2019s new technical specification for software fiscalization should not be read as a simple interface document. It is a blueprint for a regulated fiscal infrastructure. For a POS software vendor, it may look…<\/p>\n","protected":false},"author":1,"featured_media":143188,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"episode_type":"","audio_file":"","cover_image":"","cover_image_id":"","duration":"","filesize":"","date_recorded":"","explicit":"","block":"","itunes_episode_number":"","itunes_title":"","itunes_season_number":"","itunes_episode_type":"","filesize_raw":"","footnotes":""},"categories":[1],"tags":[],"class_list":["post-143186","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/posts\/143186","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/comments?post=143186"}],"version-history":[{"count":1,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/posts\/143186\/revisions"}],"predecessor-version":[{"id":143187,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/posts\/143186\/revisions\/143187"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/media\/143188"}],"wp:attachment":[{"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/media?parent=143186"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/categories?post=143186"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/tags?post=143186"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}