One point of standing. The binding text is the Slovak one, published in the Zbierka zákonov. This page is a working guide for a reader who does not read Slovak, not a substitute for the instrument; where the two diverge, the Slovak text governs.
What are the five corners, and which one is Slovak?
Slovakia calls the document an e-faktúra — an electronic invoice — and its journey has five stations, not four.
| Corner | Who | What it does |
|---|---|---|
| 1 | Supplier (sender) | Creates the invoice in its own system and hands it to its provider. |
| 2 | Supplier's access point — digitálny poštár | Validates the document against the Slovak CIUS and sends it over AS4. |
| 3 | Buyer's access point — digitálny poštár | Takes the document off the network and delivers it to the buyer. |
| 4 | Buyer (recipient) | Receives the structured invoice into its own system. |
| 5 | Finančná správa | Receives the SK TDD, a tax data document derived from the invoice. |
Corners 1 to 4 are the ordinary Peppol network, which operates in dozens of countries and which a multinational may already be connected to for other markets. The fifth corner is the Slovak extension. The format is XML conforming to EN 16931 — UBL 2.1 or UN/CEFACT CII — and specifically Peppol BIS Billing 3.0, itself a Core Invoice Usage Specification of EN 16931, with a Slovak CIUS narrowing it further. The Financial Administration announced full technical readiness on 24 August 2026 and published an updated FAQ and manual two days later.
The fifth corner is a reporting destination, not a gate. Nothing waits for it. The invoice is not held, queued or approved there, and the tax administration receives data derived from the invoice rather than the invoice itself — a point worth having ready when a group's data-governance function asks what the Slovak state can see.
How does this differ from Poland's KSeF and Italy's SdI?
| Property | Clearance model (Poland, Italy) | Peppol 5-corner (Slovakia) |
|---|---|---|
| Path of the invoice | Through a state platform | Between independent providers |
| Confirmation of receipt | One response from the state system | Responses from several links in a chain |
| Reporting to the tax administration | Part of the same operation | A separate flow (SK TDD) |
| Authority over duplicates | Central | None |
| Proof of authenticity | Record in the state system | Transmission over AS4 |
| State system unavailable | A defined legal state with its own deadlines | No equivalent — it is your provider's outage |
Poland's KSeF and Italy's Sistema di Interscambio belong to the same architectural family: the invoice is routed to a state system, which validates it, and its acceptance is the compliance event. Everything downstream — the identifier, the immutability, the penalty analysis — follows from that single moment. In Poland an accepted invoice receives a numer KSeF and can afterwards be corrected but never deleted, and from 1 January 2027 issuing outside the system carries a penalty of up to 100% of the tax shown; see KSeF penalties from 1 January 2027.
Slovakia has no such moment. Nothing accepts the invoice on behalf of the state, so nothing tells you that you have failed. The last row of the table is the one that catches project teams: Poland defines named legal states for platform downtime, each with its own transmission deadline and its own documentation duty — the three states are set out in offline24, awaria and niedostępność. Slovakia has nothing equivalent, because there is no state platform in the invoice path to be unavailable. What exists instead is a statutory relief where the breach was caused by a technical failure on the provider's side — a relief that shifts the burden onto you, because you have to be able to prove it.
Why is it not enough to track whether the invoice arrived?
This is the most important integration consequence of the 5-corner model, and the one most often missed. Delivery of the invoice to the buyer and delivery of the SK TDD to the Financial Administration are two distinct events in two distinct flows. A system that watches only the first simply does not know whether the second was discharged. The invoice can be sitting in the buyer's ledger, correctly posted and paid, while the tax obligation remains unmet.
The practical conclusion is that a period-end control has to compare three sets against one another: invoices issued, deliveries confirmed by the network, and SK TDDs confirmed by the fifth corner. If the three do not reconcile, you have a problem that nobody will report to you. In a centralised model the platform would report it; here there is no platform to do so.
There is a second reporting duty on the other side of the transaction. When your provider receives an invoice, the data from it must be reported within five days. A draft amendment from the Ministry of Finance — LP/2026/282, of 27 May 2026 — would defer that buyer-side duty to 1 July 2030 and introduce a penalty-free period from 1 January to 31 March 2027. As at the position date of this page it had not been approved, it remained in the legislative process, and the Financial Administration's August 2026 materials describe no such period. Fines run to €10,000 for a first breach and €100,000 for a repeated one, and they begin on 1 January 2027 regardless. Do not design the architecture around it. The library's register of corrections tracks the point.
What changes when authenticity rests on AS4 rather than a document signature?
Authenticity of origin and integrity of content rest on the secured AS4 transport within the Peppol network, not on a digital signature applied at document level. Trust arises because the document passed between two certified access points that authenticated each other. Under the Peppol AS4 Profile, access points sign at transport level using X.509 certificates issued from the Peppol PKI; certificates are verified when they are fetched from the SMP, and certificates not issued by OpenPeppol must not be used.
For any process that has treated a signed file as the evidential artefact, this is a departure from established practice. An archive of signed PDFs proves less after 2027 than it did before. The evidence becomes the transmission record: document and operation identifiers, timestamps, acknowledgements from the access points, and the status returned by the fifth corner. Those records come into existence only if somebody deliberately keeps them; they are not a by-product of storing the invoice.
The Slovak VAT Act has not abolished the older route — a guaranteed or qualified electronic signature remains one of the recognised means of ensuring authenticity under § 71 of the Act. But it is not what the Peppol channel relies on, and a control narrative resting on signature verification will describe a control the new channel does not perform.
Why is the SMP registration a single point of failure?
For receiving, an entity has exactly one provider, because the registration in the SMP (Service Metadata Publisher) is unique to a ParticipantID — that entry is precisely what tells senders where to deliver. For sending, an entity may contract several providers at once.
| Direction | Number of providers | Consequence |
|---|---|---|
| Receiving | Exactly one (SMP registration) | Single point of failure. No alternative route. |
| Sending | Several in parallel | A fallback is possible. |
The asymmetry is material. If your receiving provider goes down, invoices cannot be delivered to you — and changing provider is not an immediate operation, because the SMP entry has to be rewritten and propagated across the network. This belongs in the business continuity plan, not in the small print of a contract. Two questions to put to a provider: what availability does it commit to, and how long does transferring the registration take in practice?
Why does a retry create a duplicate?
A timeout does not mean the document was not received. It means only that you did not learn the outcome. If the system answers that situation with an automatic retry and has no durable operation identifier assigned before the first attempt, the second attempt puts a second document into circulation.
In a centralised model the platform would catch the duplicate. In a decentralised model there is no authority to flag it. Two invoices travel the network, two SK TDDs arrive at the fifth corner, and the discrepancy surfaces at a reconciliation, potentially months later. Idempotency is a familiar requirement everywhere; what is different here is that no counterparty can enforce it for you.
How do you prove that your provider failed?
The statutory relief for a technical failure on the provider's side does not operate by itself. To rely on it you must be able to show that the failure happened and when. That means retaining records of attempts, responses and error states — not only of outcomes. A system that remembers invoice sent on 3 March
offers no defence. A system that remembers three failed attempts with error codes and timestamps offers one.
The same logic applies to operations performed by automated processes or AI agents, where the record of who authorised the operation has to come into existence before it runs rather than after. See AI governance for the general treatment, and workflow automation for where these controls sit in a cross-system process.
How should a foreign group choose a digitálny poštár?
Digitálni poštári — literally digital postmen — are certified Peppol access points that are additionally accredited by the Finančné riaditeľstvo SR (Financial Directorate of the Slovak Republic). The Financial Directorate is also Slovakia's Peppol Authority, listed as such by OpenPeppol, and it publishes the national requirements and the list of approved providers.
Four points apply with particular force to a group that is not Slovak.
- Peppol certification is not Slovak accreditation. A global access point already serving your entities in other Peppol markets is not thereby entitled to act in Slovakia. Accreditation by the Financial Directorate is a separate act, and support for the Slovak CIUS and the SK TDD reporting leg is a separate capability. Ask for both by name.
- The registration is per entity, not per group. A ParticipantID belongs to a legal entity. A shared service centre operating for six Slovak companies still needs six registrations, and a single group-level contract does not create them.
- Verify the whole scenario, not just receipt. Not every provider covers sending, receiving and the reporting leg to the same standard, and the reporting leg is the one that is hardest to test from outside.
- Ask what the provider gives you back. Transmission acknowledgements and error states, in a form you can archive and read years later, are the raw material of every defence you will ever run. If they exist only inside the provider's portal, they are not yours.
What happens to B2G and IS EFA?
Public-sector invoicing has been governed by zákon č. 215/2019 Z. z. on guaranteed electronic invoicing and the central economic system — Slovakia's implementation of the EU obligation on public authorities to receive electronic invoices under Directive 2014/55/EU. From 1 January 2027, B2G moves under the same regime as B2B, and IS EFA is moving to a Peppol-based solution.
The practical warning is the same one the Slovak market is already hearing: if a vendor offers IS EFA as a channel for your B2B invoices, it is working from stale information. B2B runs on Peppol. For a group selling to Slovak public bodies as well as businesses, the two channels converge rather than needing separate integrations.
In practice
Where invoices are issued by automated processes rather than by a person, the decentralised model moves the question from did it go through?
to can you show what happened and who permitted it?
BarzelVault applies policy and approval thresholds ahead of execution and issues signed audit receipts. BarzelOps runs the cross-system workflow with durable state, approval checkpoints and tenant isolation, which keeps each Slovak entity's transmissions attributable to that entity.
Frequently asked questions
Is it a clearance system?
No. Peppol 5-corner: four corners of the Peppol network, and a fifth corner, the Financial Administration, receiving the SK TDD. The invoice is never submitted to the state for acceptance.
What is the fifth corner?
The Finančná správa, to which the SK Tax Data Document is sent. It is a Slovak extension of the standard network and a reporting destination, not a gate.
What is a digitálny poštár?
A certified Peppol access point additionally accredited by the Finančné riaditeľstvo SR, which is also Slovakia's Peppol Authority.
Can I use several providers?
One for receiving, fixed by the SMP registration for the ParticipantID; several for sending.
Why is a signed document no longer enough?
Authenticity rests on the AS4 transport, not on a signature applied to the file. The evidence is the transmission record.
Does my global Peppol provider already cover Slovakia?
Not automatically. It must be accredited by the Financial Directorate and support the Slovak CIUS and the SK TDD reporting leg.
Where this leads
A clearance model concentrates risk in one place and tells you when you have hit it. The Slovak model distributes it across a chain of independent parties and tells you nothing. That is not a worse design — it is a cheaper and more interoperable one, and it reuses infrastructure a multinational may already have. But it moves the burden of knowing whether you are compliant from the state onto you, on a date when the fines begin. The work that follows is reconciliation, retention and continuity planning — none of it technically hard, none of it automatic.
In practice
The control has to run before the invoice becomes irreversible.
An accepted structured invoice can be corrected but never deleted, and from the penalty date every defect has a price. Barzel puts the approval threshold, the duplicate check and the signed record in front of submission, so the process can be defended on the day an auditor or the tax authority asks.
95 days leftMandatory e-invoicing in Slovakia from 1 January 2027
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
BarzelOps
Governed workflow automation across the systems that run the business.
- Durable, idempotent execution: a timeout is retried once, never filed twice.
- Human approval checkpoints that pause the workflow and resume it.
- Isolation per entity or client, signed evidence receipts and a portable manifest; HubSpot, Xero, Gmail, Google Drive and Slack.
Free tier: 100 calls a dayPaid plans from $19 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Related
- Slovak e-invoicing from 1 January 2027: which entities are caught
- KSeF penalties from 1 January 2027 (Poland)
- offline24, awaria and niedostępność: three states, three obligations
- Glossary of regulatory and technical terms
Sources
- Zákon č. 385/2025 Z. z., amending zákon č. 222/2004 Z. z. o dani z pridanej hodnoty — slov-lex.sk.
- Zákon č. 222/2004 Z. z. o dani z pridanej hodnoty (Slovak VAT Act), § 71 — slov-lex.sk.
- Finančná správa SR, Aktualizované FAQ a manuál k e-fakturácii, 26 August 2026.
- OpenPeppol, Peppol Authorities — the Financial Directorate of the Slovak Republic (FR SR) is listed as the Peppol Authority for Slovakia.
- Peppol BIS Billing 3.0, a Core Invoice Usage Specification of EN 16931 — docs.peppol.eu.
- Peppol AS4 Profile, version 2.0.3, 22 April 2024 — docs.peppol.eu.
- Council Directive (EU) 2025/516 of 11 March 2025 amending Directive 2006/112/EC as regards VAT rules for the digital age (ViDA).
- Directive 2014/55/EU of 16 April 2014 on electronic invoicing in public procurement.
- Zákon č. 215/2019 Z. z. o zaručenej elektronickej fakturácii a centrálnom ekonomickom systéme (B2G, IS EFA) — slov-lex.sk.
- Ministerstvo financií SR, draft amendment LP/2026/282 of 27 May 2026 — in the legislative process and not enacted as at 3 September 2026. The entry on the slov-lex legislative-process portal could not be retrieved for verification, so no link is given here.
This article is a working guide for English-speaking readers and does not constitute tax or legal advice. The binding text is the Slovak one.