Peppol Is Not Slovakia's E-Invoicing Model: Separate the Standard from State Decisions

Governance analysis: Peppol is part of the solution, not the whole Slovak regime.

“It uses Peppol” is useful technical information. It is not a complete answer to a business asking why it must enter a provider relationship, what information reaches the tax administration or who carries the cost of an outage. These are different questions, decided at different levels.

This is a risk in public debate, not a quotation of a specific Financial Administration defence. The distinction matters because both supporters and critics can misuse the standard. Supporters may attribute every national design decision to international interoperability. Critics may blame Peppol for obligations created by domestic policy. Neither approach helps us retain the benefits of a shared network while improving the arrangement around it.

Peppol is more than a file, less than a national tax system

OpenPeppol describes its interoperability framework as a combination of governance and architecture, encompassing agreements, policies, requirements and specifications.3 Calling it “just XML” therefore understates what it provides. A common document format without rules for participants, addressing and trusted delivery would not deliver the same network.

At the same time, the framework is not identical to the Slovak tax regime. The Slovak Financial Administration’s January 2026 guidance describes specific domestic issuing and reporting obligations and a transition beginning in January 2027.8 Those obligations must be explained by reference to the national legal arrangements, not merely by pointing to a Peppol logo.

There is room for national requirements within the framework. OpenPeppol says that Peppol Authorities may define additional requirements within their jurisdictions, subject to formal approval through the relevant governance process.3 Consequently, the existence of an additional national requirement is not, by itself, evidence that a country has violated the nature of Peppol.

The useful question is more precise: which rule comes from which authority, for what purpose, and with what consequences for the business?

Draw the system in layers

Start with the business application. This is where the supplier records the transaction and where the customer performs its accounting or approval work. A local integration connects that software to a provider. Its behaviour matters to users even if it is not the same interface used between network providers.

Next comes the document layer. Peppol Billing documentation describes invoice and credit-note syntax and rules.5 A compliant invoice is a structured business message. Compliance with its format does not determine whether the underlying goods exist or whether a tax deduction is justified.

Then comes network delivery. OpenPeppol’s four-corner model connects the sender and recipient through their respective service providers, with addressing and capability lookup supporting routing.3 This is the layer people usually mean when they describe the two Access Points in the middle of the exchange.

Finally, add the reporting layer and the legal obligations around it. Information may be extracted from the invoice and supplied to an authority. That activity can share infrastructure with delivery, but it has a different recipient and purpose. Its exact scope cannot be inferred from the fact that the invoice travelled over Peppol.

A hypothetical supplier makes the difference visible

Imagine a hypothetical furniture manufacturer issuing an invoice to a Slovak office-equipment retailer. Its accounting application produces the business document. A provider accepts it, performs the relevant processing and sends it toward the retailer’s provider. The retailer’s system imports it for matching against the purchase order.

Now ask what the manufacturer needs to know. If its application cannot reach the provider, has anything been sent? If the provider accepted the document but delivery is delayed, which record proves what happened? If reporting succeeds but the retailer disputes the invoice, does the application preserve both facts without treating them as contradictory?

None of these questions is solved by saying “four corners”. A diagram describes roles; an operating model must explain state transitions, evidence and responsibility. The manufacturer also needs a process for corrections, duplicate submissions and recovery after interruption.

Add one more issue: changing providers. The retailer should not need to renegotiate the commercial sale because the manufacturer changes its network service. But the manufacturer may still need to migrate local integration settings and historic evidence. Network interoperability and practical portability overlap without being identical.

The centralisation claim needs precision

It is inaccurate to describe Peppol as a network with no central components. OpenPeppol identifies a single centralised Service Metadata Locator and its authority over central components including the public-key infrastructure.3 These components support discovery and trust. Their existence does not mean that the locator is a central warehouse containing every business invoice.

Conversely, a national reporting destination can collect specified information even when business delivery is distributed across providers. Distributed delivery does not prove that reporting is decentralised. Nor does central reporting prove that every provider stores every document indefinitely.

A responsible assessment asks for an actual data-flow map: which organisation receives which fields, whether it stores them, for how long, and under which access controls. Without that map, dramatic assertions about a complete national archive or absolute privacy are not reliable architecture analysis.

This also changes the security discussion. Certification and common trust mechanisms are relevant controls, but neither demonstrates that every deployed application is invulnerable. Additional processing introduces additional responsibilities; it does not automatically establish a vulnerability or a legal breach.

The contract is a policy issue, not a syntax rule

The Financial Administration’s public guidance says that receiving electronic invoices requires contracting with a certified delivery-service provider.1 Its more detailed methodological explanation also distinguishes the duty to ensure delivery-service capability from the possibility of another delivery method with the recipient’s consent.8 Both parts matter when describing the actual obligation.

The justified concern is therefore not a claim that every document can only travel through one mandated route. It is that access to the mandated capability places a business in a service relationship whose pricing, support, continuity and exit conditions matter to compliance.

A required commercial relationship does not automatically imply a paid fee or subscription. Baseline transport itself has commercial value; the question is who procures and pays for it. A common network does not decide who signs the relationship. The state could explore procuring a public-facing minimum service while allowing providers to compete for enhanced functionality. That is my preferred direction, subject to legal, procurement and operational assessment. It should not be represented as something already guaranteed by the standard.

There is a meaningful difference between using private expertise and requiring each affected business to become a separately contracting customer. The former does not logically require the latter. Public registration, delegation, access recovery and conditions of use would remain. Compare that work fairly with managing provider terms, rather than presenting public access as administration-free or the current arrangement as the only expression of Peppol.

The best argument against changing the arrangement

The strongest defence of the chosen model is that decentralised providers may be better placed to integrate with diverse software and support different business needs. A public baseline could duplicate existing services, reduce incentives to invest or become a poor-quality dependency of its own.

That defence deserves evidence. Compare support performance, accessibility, total compliance costs and switching outcomes. Include very small recipients as well as sophisticated businesses with existing integrations. A market that serves large customers well may still need a clear answer for someone who only needs reliable receipt and an export for the accountant.

A public baseline also requires discipline. It should not become an unlimited subsidised accounting suite. It should define a minimum obligation, publish service expectations and preserve interoperability with the commercial market. The argument is for a dependable floor, not for eliminating choice. Procurement must compare one or several operators, entry conditions, open interfaces, switching costs and a tested service takeover. A single award can concentrate dependence rather than remove it; none of these options is asserted to be legally ready.

Ask for an attribution table

Before approving an implementation, I would ask for a table with four columns: requirement, issuing authority, business consequence and accountable operator. Put document fields, delivery confirmations, reporting deadlines, provider registration and retention rules on separate rows. Add the contractual basis where the requirement is commercial rather than statutory.

Then trace one invoice through those rows. Include an error and a correction. The exercise will expose unanswered questions much faster than arguing over whether a solution is “pure Peppol”. It can also reveal where public explanations are broader than the detailed rules or where an optional service has been mistaken for a legal requirement.

Peppol is a useful foundation precisely because it can support cooperation across organisations.3 We should protect that foundation from being used as a rhetorical shield. Support the standard, scrutinise the national decisions, and require each layer of the system to justify its own costs and responsibilities. That is not hostility to e-invoicing. It is how an interoperable technical design becomes an accountable public programme.