A guide to roles and evidence—not a verified map of the complete Slovak implementation.

An invoice can leave an accounting application, reach a network gateway, arrive at a customer’s system and generate a tax report. Those are different events. Calling all of them “sending an e-invoice” makes a reform sound simpler, but leaves businesses unable to tell which obligation has been completed and who should fix a failure. I support structured invoicing. My concern is that we cannot govern an infrastructure whose components we describe incorrectly.

The first correction is fundamental: an SMP is a publisher of service metadata, not an invoice warehouse. OpenPeppol describes capability lookup as an electronic address book or business registry, separate from Access Points exchanging business messages.1 A diagram that puts every invoice through “state storage/SMP” therefore confuses two functions. A state may operate additional reporting or storage services, but their existence, content and connection to delivery need separate evidence.

Start inside the business

An enterprise resource planning system, or ERP, is where a business may create the invoice from an order, delivery record or service record. Here the practical questions concern source data: the correct buyer, the right quantities, the agreed price and the tax treatment. A technically valid document can still describe the wrong transaction. A network cannot settle whether a technician actually completed the work merely by accepting a structured message.

The connection from that application to a provider is another boundary. Businesses should ask what interface is offered, how authentication works, how rejection is reported and which version of the invoice is preserved. “Supports Peppol” is not a complete description of this local integration. The provider’s service can include conversion, validation, storage or workflow, but buyers should identify those functions rather than assume that they all come with network connectivity.

That distinction matters commercially. A firm may want delivery alone while another needs an archive and approval workflow. Combining these in a product is legitimate; presenting the bundle as an indivisible consequence of the standard is not a convincing explanation of necessity. The specification of the public obligation should let a business understand which service is required and which is optional.

Delivery is a chain, discovery is a lookup

OpenPeppol’s four-corner model connects the sending business, its service provider, the receiving provider and the receiving business. The Access Points exchange business messages, while addressing and capability services help find the appropriate destination.1 The fact that some roles may be operated by the same organisation does not make them the same technical function.

The Service Metadata Locator, or SML, identifies the relevant SMP. The sending provider then consults the SMP to discover the receiver’s capabilities and addressing information.1 This is a lookup alongside the message exchange, not a statement that invoice line items are deposited in the SMP. OpenPeppol explicitly allows centralised or decentralised provision of local addressing and capability lookup.1 Centralised metadata is consequently not evidence of a central invoice archive.

This correction does not make discovery unimportant. A wrong address, unavailable lookup or unauthorised registration change could affect delivery. Those are plausible failure modes to assess, not allegations that any particular Slovak service has experienced them. Their treatment depends on implementation, including authentication, update procedures and recovery arrangements. It is equally unsound to describe an SMP failure as harmless or to assume that it instantly deletes invoices from every ERP.

A hypothetical invoice with two destinations

Consider a fictional engineering supplier billing a customer for maintenance. Its ERP creates a structured invoice and submits it to its provider. The receiving provider accepts the message, but the customer’s ERP cannot match the purchase order. Separately, suppose the national design requires a report to the tax authority and that reporting interface is temporarily unavailable. This is a design exercise, not a description of a tested Slovak incident.

There are now several answers to “was it sent?” The supplier’s provider may have accepted the submission. The receiving provider may have acknowledged transport. The customer may still be unable to process the business document. The report may remain queued. These states should be visible separately because they call for different responses: technical retry, commercial clarification, correction or reporting recovery.

A single green tick conceals too much. I would require a status record identifying the document version, the relevant event, its timestamp and the actor confirming it. Each state should identify its source and observation boundary: unconfirmed, failed and unsupported are different outcomes. A provider cannot confirm the buyer’s accounting decision unless that evidence is supplied. One support contact should explain uncertainty and resolve its own part, not guarantee an unobservable business outcome. Whether a particular event counts as legal delivery, starts a payment period or satisfies a reporting deadline is a legal and contractual question. It should not be inferred from a reassuring icon or from the fact that an HTTP request succeeded.

Tax reporting needs its own description

Business-to-business delivery moves the invoice to the customer for processing. Tax reporting provides information for a public function. Even if both use common infrastructure or the same service provider, their purpose, recipient, permitted data and completion criteria are not interchangeable. OpenPeppol’s description of the four-corner exchange is not, by itself, a description of Slovakia’s reporting payload or statutory timing.1

Part 05 summarises the Financial Administration’s January 2026 guidance for the described transitional regime: listed relevant identifiers, invoice number, dates, goods or service details, prices, discounts and tax information. The legal dataset is therefore not wholly unknown. What I have not verified here is its mapping to the current technical message, attachments, operational logs and retention. A versioned architecture should connect that known scope to the reporting branch: who creates the report, whether delivery depends on its acknowledgment, and who corrects discrepancies. Existing specifications are the starting point for that check; an unreviewed payload is not evidence that documentation is absent.

This separation also improves proportionality analysis. The customer may need detailed line descriptions to reconcile an order; the reporting authority needs a justification tied to its own purpose. Where personal data are involved, Article 5 requires purpose limitation and data minimisation.16 That does not establish that line-level reporting is unlawful. It establishes why one recipient’s operational need cannot automatically justify every other recipient receiving an identical copy.

Where responsibility becomes practical

I would separate three governance roles alongside the technical map. The substantive reporting sponsor should justify the purpose and expected benefit of collection. The technical implementer and operator should deliver safe, reliable and correct processing, including validation, access control, recovery and evidence of failures. The authority empowered to make the rules should justify their scope, proportionality and safeguards. These are functional distinctions, not a claim about the actual Slovak organisational chart; one organisation may perform more than one role. They do not absolve IT teams of responsibility for their design and operation, or make technical success proof of a justified reporting purpose.

For procurement, I would turn the architecture into a small responsibility matrix. For each transition, identify the sender, receiver, data format, acknowledgment, retention policy and support owner. Add what the customer can export and what happens when the provider changes. This makes a discussion about “the platform” concrete enough to price and test.

The matrix should include conversion. If the ERP sends one representation and the provider creates another, preserve enough evidence to identify which version the buyer received. The same principle applies to a correction: a retry should not silently become a new business invoice. A well-designed correlation scheme should connect delivery and reporting without pretending they are a single event.

Storage needs the same discipline. Temporary transport queues, customer archives, diagnostic logs and a public reporting database are different repositories. Ask which ones actually exist and what they contain. Logging complete payloads for convenience could create additional copies, but that is a risk to check, not an established fact about all providers. Access rights and deletion rules should follow each repository’s function.

The strongest objection: businesses want simplicity

Most business owners do not want an architecture lesson. A competent provider can absorb integration complexity and offer one reliable service. That is a serious argument for intermediaries, especially where maintaining an interface internally would be expensive. OpenPeppol’s “connect once” model is expressly intended to let participants reach others through their chosen provider.1

The answer is not to force every firm to operate a network gateway. It is to make simplicity auditable. A provider can offer one dashboard while retaining distinct delivery and reporting evidence beneath it. A public baseline service could also procure specialist capabilities without obliging every business to negotiate a separate commercial bundle. That is a policy proposal, not a claim that the public sector is automatically a better operator.

Publish the map before demanding trust

Slovakia should make a versioned reference architecture readily accessible, building on existing documentation with separate arrows for invoice delivery, metadata lookup and tax reporting. Each arrow should name the data transferred and the acknowledgment returned. Businesses should request the corresponding map for the service they buy, including the boundary between the provider and their ERP.

Then test one ordinary invoice, one rejection, one correction and one interruption in each branch. The acceptance criterion should be an explainable result, not merely a successful demonstration on a good day. E-invoicing becomes easier to defend when its advocates can say precisely where an invoice goes, what the state receives and which party is accountable at every step.

Sources

[1] Peppol Interoperability Framework - OpenPeppol

[16] GDPR: original EU Regulation 2016/679 (official UK archive, adopted text)