Procurement checklist for an exit—not a finding of lock-in at a named provider.
The most revealing question about an invoicing provider is not how quickly it can register a new customer. It is how that customer can leave. Can the business keep its receiving identity, retrieve its records, preserve delivery evidence and continue working without rebuilding everything around the next supplier?
Peppol interoperability is valuable. It does not make every application, archive and contract interchangeable. The fair criticism is not that changing providers is impossible. It is that technical migration of a receiving route is only one part of an economically usable exit.
Start with the migration that is already documented
The Financial Directorate’s FAQ, in the file dated 15 September 2026, contains explicit guidance on changing digital postmen. Part II, example 24, describes ending the contractual relationship, deregistration by the original provider within three working days of contract termination, confirmation of release and registration by the new provider.6 It also says a complaint may be submitted to the Peppol authority if the original provider fails to deregister within the stated period.6
The same FAQ, Part II, example 46, describes migration using codes between Service Metadata Publishers, or SMPs, with the Service Metadata Locator, or SML, updating the participant’s association. It presents this as a process preserving the participant’s availability in the network.6 It would therefore be inaccurate to claim the official design contains no mechanism for a continuous transition.
However, the two answers describe different sequences: termination and deregistration in one, coordinated migration codes in the other.6 The answers may cover different situations; their different wording does not establish a conflict. Ask for a decision tree explaining when each route applies and how unfinished documents are handled. A business should obtain confirmation of the applicable sequence for its actual providers before cancelling anything. I have not tested these workflows, and the FAQ’s statement of intended continuity is not evidence that a particular customer’s entire application migration has been demonstrated.
A new route is not a transferred history
An SMP publishes service metadata used in the delivery arrangement; the FAQ describes its role as publishing metadata concerning services such as electronic invoices.6 Changing the relevant registration concerns where future documents are directed. It does not, by itself, demonstrate that historical invoices, attachments or application records have been copied into the next product.
This distinction is the centre of the portability problem. A business may be reachable at the new provider while its accountant still needs the old portal to investigate last year’s dispute. An outgoing integration may still use the previous supplier’s credentials. Internal approvals might remain in a proprietary workflow even though the invoice itself is in a standard format.
Those are potential migration dependencies, not findings about any named Slovak provider. They should be investigated in the contract and a practical export test. A technical standard reduces some forms of dependence; it does not remove every commercial or organisational dependency around a service.
A hypothetical wholesaler changes suppliers
Consider a hypothetical wholesaler whose provider changes its tariff. The company wants to move. It receives invoices automatically into an accounting application, sends invoices through another connector and lets staff use the provider’s portal to inspect delivery problems.
The first task is to identify which relationships actually change. The Slovak FAQ says a business can have one receiving postman for a given ParticipantID but several sending postmen.6 Replacing the receiving service therefore need not mean replacing every outgoing connection. Equally, the wholesaler must check whether a bundled contract links them commercially.
The second task is records. The company wants its original structured invoices, the attachments it relies on and evidence explaining delivery outcomes. It also wants a list of unresolved documents at the transition point. If it exports only readable previews, it may preserve something useful for a person but fail to preserve the structured records it needs for later processing.
The third task is reconciliation. Suppose an invoice was already accepted by the old service but had not yet appeared in the accounting application when the route changed. The company needs a procedure to determine whether to wait, retrieve or retry. Blindly sending everything again is not a migration plan. This hypothetical case illustrates why the handover must cover work in progress, not only future routing.
What an exit package should contain
I would require providers to describe a standard exit package before the customer signs. It should distinguish the original invoice files from readable representations and explain how attachments, document identifiers, timestamps and available status evidence are linked. Exporting a folder of unexplained files is less useful than exporting records whose relationships remain understandable. Require a handover manifest: record types, date range, links, absent categories, open documents and completeness checks. A provider can export what it holds, not records held only in the ERP or by another party. The receiving system must demonstrate usable import; price basic export, transfer assistance and workflow adaptation separately.
The Financial Directorate’s FAQ, Part I, example 59, says that under the described transitional rules a VAT payer must retain electronic invoices in XML format and describes a ten-year period from the end of the relevant calendar year.6 That makes a precise retention and export discussion more than a convenience question. This statement should not be casually extended to every record and every non-VAT entity without checking the applicable rules.
The contract should also identify what the service does not retain. The Financial Administration’s general page describes a minimum six-month retention requirement for delivery and receipt logs.2 That statement must not be mistaken for a promise that every provider includes a complete long-term invoice archive. Different records and obligations require separate treatment. A minimum retention period is not an instruction to delete all logs at its end. My recommended evidence package is a procurement requirement, not a newly verified statutory retention schedule; the applicable provisions and temporal scope still need legal checking.
An exit package should be testable while the account is healthy. Ask for an export of sample records and try opening them outside the provider’s portal. Check relationships and completeness, not just whether a download button produces a file. This is a recommendation for future procurement, not a claim that I have performed such tests on current suppliers.
Portability includes the application connection
The public FAQ says authentication and technical connections for sending are handled at individual digital postmen.6 Consequently, a buyer should not assume that changing a network provider leaves the connection from its own application untouched.
A useful contract should identify the supported interface, version policy, authentication arrangements and transition assistance. If replacing the provider requires a new connector, the company needs to know who builds it, who tests it and what it costs. A standard invoice format does not answer those integration questions.
This is where a low monthly tariff can be misleading without being dishonest. A service may be reasonably priced for routine transport but expensive to replace because the customer built a substantial workflow around it. That is not automatically abusive lock-in. It is a switching cost that should be visible before the original choice is made.
The strongest defence of existing arrangements
Providers can reasonably argue that a universal migration package cannot transfer every proprietary feature. A new product may organise approvals differently or lack an old dashboard. Some configuration and staff retraining are unavoidable when moving between genuinely different services.
I agree. Supplier independence should not mean identical products or free unlimited consultancy. Providers should be able to charge transparently for optional work beyond a defined export and handover obligation. Competition would be poorer if every useful innovation had to fit a single application design.
The minimum should instead be usable access to the customer’s records, clearly bounded transition assistance and no surprise over what stops at termination. A provider that makes leaving straightforward can still retain customers because its service is good. That is stronger evidence of a healthy market than a long list of certified names alone.
Governance should make exit observable
The published Slovak guidance already gives a deregistration period and an escalation route.6 Policymakers should build on that specificity by making the complete user journey equally clear: when to request migration, how the two providers coordinate, which evidence the user receives and how a disagreement is resolved.
There is also a useful historical comparison. OpenPeppol’s published Netherlands-specific requirements in a document hosted under its 2022 materials describe cooperation with switching within three business days of the user’s desired end date, or deregistration within that period.5 That is a scoped example of making cooperation explicit, not a claim that Dutch rules apply in Slovakia or that the older document proves current Dutch operational performance.
Portability matters for both public and private services, but business switching and public-operator replacement require different scopes. A business should be able to export the records held for it and transfer relevant configuration where the receiving service supports compatible functions. That does not imply automatic transfer of proprietary workflows, identical products or unlimited free migration.
Government procurement needs a broader operator-takeover checklist: documented interfaces, transferable operational data and configuration, documentation and rights sufficient for takeover, a priced exit and a tested handover to another operator. These public-service continuity requirements should not be confused with an ordinary customer export. An unexportable public portal would merely move the dependency.
Test the exit before committing to the entrance
Businesses should request a written migration sequence, a sample exit package and an explanation of any continuing archive charges. They should identify the receiving registration, outgoing connectors and unresolved documents separately, then verify the new route before closing the old workflow according to the agreed procedure.
Government should clarify the relationship between the two migration descriptions and publish an end-to-end acceptance scenario. Network continuity, record continuity and accounting continuity should each have their own test.
Interoperability makes exchange possible. Practical portability makes choice credible. A successful e-invoicing market needs both, and neither is established merely by saying that every supplier uses the same network.
Sources
[2] Financial Administration: eFaktúra guidance
[5] Netherlands Peppol Authority: specific requirements, historical 2022 document
[6] Financial Directorate: eFaktúra FAQ, file dated 15 September 2026