Slovakia Goes Peppol on 1 January 2027: E-Invoicing for Custom ERPs and EDI Flows

From 1 January 2027, a VAT payer established in Slovakia can no longer email a PDF to another Slovak business and call it an invoice. Domestic B2B and B2G invoices have to be structured XML under the European standard EN 16931, delivered over the Peppol network through a certified provider, which the Financial Administration calls a "digitálny poštár", a digital postman. Every Slovak company, sole trader and public body has to be able to receive them, including those that are not VAT payers.

As of early October 2026, that leaves about 90 days.

If you run Pohoda, KROS, Money or a similar packaged accounting product, this is mostly your vendor's job. They are shipping Peppol support, and the Financial Administration's own manual of 26 August 2026 says that in most cases an update of the existing system will be enough. Install the update, pick a provider, agree the routine with your accountant.

This article is for everyone else: companies whose invoices come out of an in-house ERP, a heavily customised or end-of-life system, a billing engine inside their own product, or an EDIFACT link with retail customers.

What the Law Requires

The obligation comes from the amended VAT Act (222/2004 Z. z., changed by 385/2025 Z. z.). In outline, from the Financial Administration's eFaktúra page and the manual:

• Issuing. VAT payers established in Slovakia must issue e-invoices for domestic supplies, and for payments received before supply, when the customer is a Slovak taxable person or any Slovak legal entity. Consumers are out. So are VAT-exempt supplies and simplified invoices (a receipt up to €100, or an eKasa receipt up to €400 including VAT). Invoice value otherwise no longer matters.
• Receiving. Every Slovak taxable person, VAT payer or not, and every Slovak legal entity must be able to receive e-invoices through a certified provider.
• Format. XML conforming to EN 16931, in UBL 2.1 or CII D16B. On the network that means Peppol BIS Billing 3.0, which is UBL.
• Delivery. Through a certified provider over Peppol. Partners may agree on another channel, such as email or an existing EDI link, but only with the buyer's prior consent, the invoice must still be EN 16931 XML, and both sides must still be reachable through a provider.
• Timing. 15 days from supply, as today. For an invoice sent through the network, the issue date is the day it was handed to the provider.
• Reporting. The provider extracts the tax data and reports it to the Financial Administration, and the law treats your reporting duty as done once you hand the invoice over. The kontrolný výkaz (VAT control statement) stays until 1 July 2030.
• Archive. VAT payers keep the XML for ten years from the end of the year it relates to. A PDF rendering is not the invoice.
• Penalties. Breaching the e-invoicing obligations or sending incorrect data can be fined up to €10,000, and up to €100,000 for repeat breaches, according to the manual and the FAQ of 15 September 2026. An obvious error corrected promptly, or a provable failure on the provider's side, is not penalised.

The cut-over follows the tax point. If the obligation to issue an invoice arose by 31 December 2026, the old rules apply, even if it is paid in 2027.

Two smaller changes catch people out. A payment schedule (splátkový kalendár) for rent or leasing no longer works as a summary invoice: each recurring supply needs its own e-invoice. And foreign companies that are only VAT-registered in Slovakia stay outside the scope until 30 June 2030.

EDIFACT Invoices Stop Counting

This is the part that hits manufacturers and suppliers to retail chains. The FAQ is blunt. You can keep exchanging EDIFACT with your customers after 1 January 2027, but for domestic transactions an EDIFACT invoice will no longer meet the definition of an electronic invoice for VAT purposes. In its words, "vy alebo váš poskytovateľ IT služieb musí vykonať konverziu": you or your IT provider must convert those invoices to EN 16931 UBL or CII.

The FAQ even names the route. CEN/TS 16931-3-4 maps EDIFACT INVOIC D16B to the EN 16931 semantic model, and from there you map to UBL. Its example: the EDIFACT invoice number becomes business term BT-1, which becomes cbc:ID in UBL.

Two design choices follow.

Where the conversion happens. Either your system generates UBL from the same data that feeds the EDIFACT message, or your EDI service provider converts on the way out. If it is theirs, ask for their validation reports, because the fine is yours.

Which channel carries it. If the UBL goes over Peppol as Peppol BIS, the provider reports it. If you keep the EDI channel by agreement with the buyer, nothing is reported automatically, and you still need a Peppol endpoint for everything else.

The rules concern invoices, credit notes and self-billed invoices. Orders and despatch advices can stay as they are.

What You Actually Have to Build

For a custom system the work splits into four pieces. The provider connection is usually the smallest.

1. Outbound: UBL that passes validation

Map your invoice data to EN 16931 business terms, then to UBL. The eFaktúra page publishes a transposition spreadsheet (version 1.11 when this was written) that maps the business terms to the clauses of Slovak law behind them, with Slovak cardinality on top of Peppol BIS. Treat it as your specification.

The fields that cause trouble are rarely the obvious ones:

• The recipient's DIČ. Slovak participants are addressed on Peppol as 0245:DIČ, the tax identification number, not the IČO and not the IČ DPH. A company already on Peppol under a 9950 identifier still needs a 0245 registration in the Slovak SMP. If your customer master holds only IČO and IČ DPH, you have a data job before you have a code job.
• VAT category codes. S, Z, E, AE and O, each with Peppol business rules attached. Category O (outside the scope of VAT) forbids VAT identifiers on the invoice and cannot share an invoice with standard-rated lines. The exemption reason text (BT-120) is for exempt supplies; filling it on a standard-rated invoice makes the XML invalid.
• Units of measure from the UN/ECE code lists, not free text. Every line needs one.
• The document types you forgot. Corrections as a credit note plus a new invoice, or a corrective invoice that references the original in BT-25. Tax documents for prepayments use type code 388. Self-billed invoices are type 389.

Validate before you send, against Peppol BIS and the Slovak rules, and route failures to someone who can fix them. Lock the invoice once it is handed over, and make retries idempotent: the same invoice sent twice under two numbers is a tax problem.

2. The provider connection

The register of 1 October 2026 lists 79 certified providers, Slovak and foreign. Each has its own API and authentication. There is no central state platform in the invoice path: the plan for one was dropped in 2024, and invoices travel directly between providers. Practical points from the FAQ:

• You can register only one provider for receiving per participant ID, but you may send through several.
• Registering your receiving provider through the Financial Administration's portal is a legal requirement, and the person doing it needs authorisation to act for the company on that portal. Arrange that this week. It is the slowest step that involves no code.
• If the recipient is not on Peppol, delivery fails, but your duty as sender is met and the data is still reported. Your code has to record the failure and tell someone, not retry forever or block billing.

Running your own access point means OpenPeppol certification, accreditation by the Financial Administration and, from 1 July 2027, ISO/IEC 27001. For a company that only sends its own invoices, a provider is the sensible answer.

3. Inbound into accounts payable

From January your energy supplier, telecoms operator and software vendors will send you UBL. The manual puts responsibility for being able to receive on the recipient: a supplier who sends correctly through the network has done its part.

Inbound work means pulling documents from the provider's API, validating them, matching the supplier, mapping lines into your AP model, matching purchase orders where you do that, and feeding the existing approval workflow, which the law leaves alone. You also need a readable rendering of the XML on demand and the ten-year XML archive. Peppol carries no rejection message here, so disputes are settled with the supplier as before.

4. Reporting and reconciliation

The provider builds the tax data document and reports it. Your job is to make sure what you hand over is right, and that your VAT filings still reconcile, because the kontrolný výkaz continues until 2030. Store the provider's message identifiers and delivery statuses against each invoice, so that when the numbers disagree you can find out why.

How Long It Takes

The Financial Administration's own estimate: if your software is already connected to Peppol, activation is immediate. For custom or complex solutions, integration "môže trvať niekoľko dní až týždňov", several days to weeks.

That is fair for the connection itself. The weeks go into data: finding the DIČ for every customer and supplier, getting the VAT category right for every product and service, and building inbound processing that does not depend on someone opening each document.

Testing will be slower than you expect. The Peppol monitor at epostari.sk, run by Verteco, itself one of the certified providers, counted 3,332 of 235,518 Slovak VAT payers able to receive Peppol invoices on 2 October 2026, about 1.4%. It measures VAT payers only and describes its figures as informative. Even so, few of your customers can take a test invoice today, and January will bring plenty of "recipient not found" errors. Handle them as a normal case.

A 90-Day Plan

Weeks 1 to 2: inventory and decisions. List every system that issues invoices to Slovak businesses: the ERP, the billing engine, the EDI gateway, the spreadsheet someone in sales still uses. Do the same for inbound. Check DIČ coverage in customer and supplier master data. Choose a provider, sort out portal authorisation, register for receiving.

Weeks 3 to 6: outbound. Build the UBL mapping and validation, connect to the provider's test environment, and convert EDIFACT invoices or agree the conversion with your EDI provider. Cover credit notes, prepayments and self-billing, not only the happy path.

Weeks 5 to 9: inbound. Retrieval, validation, supplier matching, AP mapping, rendering and archive.

Weeks 9 to 11: live in 2026. Voluntary use is allowed this year. Send real invoices to customers who are already registered and receive from suppliers who are. This is where mapping errors show up, while they cost nothing.

Weeks 12 to 13: cutover. Make the switch key on the tax point, not the posting date. Plan around the holidays: the last two weeks of December are not a test window.

If the build will not make it, have a fallback. A provider's standalone web application, the option the manual suggests for small businesses, is enough to receive invoices on 1 January while the integration finishes. It is a stopgap for receiving, not a way to issue at volume.

What Is Still Moving

The FAQ notes a revised EN 16931 approved in October 2025 and says it cannot yet describe the impact; Peppol BIS will follow the standard. The transposition spreadsheet is at version 1.11 and the FAQ has been reissued repeatedly. Keep the mapping versioned and in one place, not scattered through invoice code.

The second phase is already in the timeline. From 1 July 2030 the obligation is expected to extend to cross-border supplies, the issuing deadline drops to 10 days, and the kontrolný výkaz goes. Do not hard-code "Slovak customers only" into the design.

Where to Get Help

We build the connection between the system that produces your invoices and the network that now has to carry them: UBL mapping and validation, provider API integration, EDIFACT conversion and inbound processing into AP. Our e-invoicing integration service explains how we work, and if the system underneath is the real problem, see ERP modernization. If the work is scoped and you need hands, we also place experienced developers into existing teams.

To talk through your setup, write to office@c9group.dev.