I Support E-Invoicing. The Question Is How We Introduce It.

Policy analysis: support for Peppol, a proposal for public baseline access—not a registration guide.

I support electronic invoicing. I also support Peppol. Having previously implemented electronic data interchange, or EDI, I do not need to be persuaded that moving structured business information between systems can be better than repeatedly typing it into them. What requires scrutiny is the implementation: who must connect, who pays, who takes responsibility, and whether fulfilling a public obligation necessarily requires an individual commercial relationship.

My EDI experience explains my view of integration; it does not establish the superiority of a public channel. That requires a comparison of cost, quality and responsibility. These are not objections to modernisation. They are questions about the terms on which modernisation takes place. An efficient document format does not automatically make every institutional arrangement around it efficient, fair or proportionate. Slovakia should be able to discuss both propositions without treating support for digitalisation as a blank cheque.

Start with the actual improvement

A structured invoice is different from a picture of an invoice. The Slovak Financial Administration describes the new e-invoice as machine-processable XML, rather than an ordinary PDF or photographed paper document.1 That distinction matters because software needs explicit fields and rules, not merely something that looks correct to a person.

The potential benefit is straightforward. A supplier creates data once; a customer receives usable data; accounting staff spend less time transferring information and more time resolving exceptions. This is a potential workflow improvement, not a promise that every invoice can be booked without review. A technically valid document can still contain the wrong price, refer to the wrong order or describe a disputed delivery.

Peppol contributes an interoperability framework combining document specifications, network specifications and governance agreements.3 It gives participants a shared way to exchange documents rather than requiring every trading pair to invent the whole connection. That is worth preserving even when we disagree about a national mandate built around it.

One hypothetical business, several different obligations

Imagine a small Slovak maintenance company. This is an illustrative business, not a reported case. It buys replacement parts, invoices business customers and uses an external accountant. Its manager wants incoming invoices to reach the accounting system without manual transcription.

Under a well-designed process, the supplier sends a structured invoice, the company’s system recognises the supplier and order, and the accountant sees any exception. A disputed quantity remains a commercial question. A missing required identifier becomes a data-quality question. Neither needs to become a mysterious technical failure that only a service provider can interpret.

Now add mandatory tax reporting. The same transaction may generate information for the Financial Administration. That is a separate destination and a separate purpose, even if one service performs both delivery and reporting. The manager must understand which confirmation means that the customer received the invoice and which means that a reporting obligation was fulfilled.

Finally, add the provider contract. The business needs to know what happens if the service is unavailable, if the accountant changes software, or if the provider changes prices. The invoice standard alone does not answer these questions. They belong in the implementation rules, operating arrangements and commercial terms.

What Slovakia has actually chosen

The Financial Administration’s eFaktúra page, updated on 18 September 2026, tells recipients to contract with a certified delivery-service provider and describes access through accounting software or web and mobile applications.1 This is not merely an abstract recommendation to adopt a file format. It is a description of how businesses are expected to gain access.

Its January 2026 methodological information explains a transitional domestic regime from 1 January 2027 to 30 June 2030, followed by further changes from 1 July 2030.8 The initial issuing obligation is not accurately described as every invoice from every business: the guidance specifies domestic VAT-registered suppliers, qualifying domestic recipients and exceptions.8 Receiving capability and issuing obligations must therefore be explained separately. This is an account of the cited guidance, not a newly verified consolidation of the law: VAT registration alone does not determine every obligation. Check issuing, receiving and reporting separately for the transaction and applicable date.

There is another important qualification. The same guidance says that parties can use another delivery method with the recipient’s consent, while the obligation to ensure delivery-service capability remains relevant.8 It would be inaccurate to claim that every actual invoice must exclusively traverse one commercial delivery route. My concern is the required capability and contractual dependency, not a simplified claim of technical exclusivity.

Delivery is not the same as reporting

A business invoice serves the relationship between supplier and customer. Tax reporting serves the administration of tax. The overlap in data can support automation, but it does not erase the difference in purpose.

This distinction gives us a practical design test. For each data item, identify the business recipient, the reporting recipient, the legal purpose and the retention requirement. For each confirmation, identify the event it proves. For each failure, identify the party responsible for recovery. A single reassuring label such as “e-invoice sent” should not conceal several different states.

The state may reasonably require reliable reporting. It may also reasonably encourage a common delivery network. But it should explain why its chosen combination is better than alternatives, including a public baseline for compliance with optional commercial services around it. That comparison should include business administration, not just the cost of the central system.

A public baseline does not mean banning providers

My preference is a direct public baseline channel, with commercial providers competing on useful additions: integration, approval workflows, reconciliation, archiving or support. This is a policy proposal, not a description of an existing Slovak entitlement or a claim that it can be introduced without legal and procurement work.

The state need not write and operate every component itself. It could procure delivery capacity from qualified providers while remaining the public-facing counterparty for the baseline service. That would preserve technical specialisation without automatically requiring each affected business to negotiate a separate commercial relationship merely to comply.

Operating baseline transport has commercial value in its own right, not only when bundled with extras. The dispute is who procures and pays for it, not whether providers do useful work. Public access would still need registration, delegation, access recovery and conditions of use. Compare that residual administration with choosing and managing commercial terms. A required commercial relationship does not automatically mean any paid fee, let alone a subscription.

Such a baseline should be deliberately limited. It should not try to replace every accounting package or offer sophisticated enterprise functionality at public expense. Its purpose would be dependable access to the mandatory minimum, clear evidence of submission and receipt, readable records and an understandable route to support.

“Free” would also be the wrong description unless we mean free at the point of use. Public procurement still costs money. The relevant comparison is total cost, distribution of that cost, accountability and the burden on the smallest participants—not whether an invoice appears on the business’s own monthly expenses.

The strongest case for the provider model

The strongest counterargument is that a competitive provider market can deploy faster and offer better integration than a public service. Providers may already possess operational expertise and relationships with software vendors. A limited state interface could become another neglected portal that people use only because they must.

That is a serious objection. A public baseline that fails during busy periods or forces staff to retype data would undermine the very automation I support. It should not receive lower reliability or security expectations simply because it is public.

Conversely, a commercial market does not prove good outcomes by existing. Businesses need meaningful portability, understandable contracts and practical ways to recover from failure. Competition should be assessed through switching tests and service outcomes, not through the number of logos on a provider list. Neither ownership model deserves an automatic presumption of competence.

What would count as success?

Success should be visible in the work that disappears. Can the maintenance company receive a usable invoice without re-entering its contents? Can its accountant distinguish a technical rejection from a business dispute? Can it change providers without losing records or interrupting reception? Can it satisfy the mandatory minimum without buying unrelated features?

The state should publish a responsibility map and a baseline-service comparison. Businesses should request a complete quotation covering integration, routine use, exceptions, support, export and exit. Software vendors should demonstrate a full invoice lifecycle, including corrections and unsuccessful delivery, rather than only a successful send button.

Security deserves the same discipline. The presence of intermediaries raises questions about access, storage and operational controls; it is not proof of a vulnerability. Equally, a certificate is not proof that every deployment is immune to compromise. The right demand is evidence appropriate to each role, not dramatic claims unsupported by testing.

My position is therefore both supportive and conditional. Use structured invoices. Preserve Peppol interoperability. Make business automation real. But justify the allocation of obligations, costs and responsibility separately. The purpose of reform should be to remove unnecessary work—not to make a public duty dependent on a commercial relationship without showing why that is the best arrangement.

Sources

[1] Financial Administration: eFaktura (updated 18 September 2026)

[3] OpenPeppol: Peppol Interoperability Framework

[8] Financial Administration: 1/DPH/2026/I, January 2026

This series offers policy analysis, not individualised tax or legal advice.