Slovak e-invoicing and PEPPOL without the noise
A practical guide for foreign companies, Slovak subsidiaries, accountants and software teams that need to understand the Slovak e-invoicing rollout without seeing a mix of Slovak and English content.
What changes in practice
For covered Slovak transactions, an invoice is no longer just a PDF or paper document. The operational object is structured UBL XML aligned with EN 16931, PEPPOL BIS Billing 3.0 and Slovak SK-CIUS rules. PDF can remain a readable representation, but it is not the structured invoice.
UBL XML, not only PDF
The invoice data must be machine-readable and validated before the live delivery workflow.
PEPPOL delivery
Network delivery belongs to a certified PEPPOL Access Point. eFaktúra Centrum is the control and preparation layer.
SK-CIUS matters
Slovakia adds local constraints and identifiers on top of the European semantic model.
Five readiness steps
- 1. Map current invoice flowsList systems, document formats, VAT status, client volume, buyer types and how invoices are received today.
- 2. Validate sample XML earlyFind structural, EN 16931, PEPPOL BIS and SK-CIUS issues before the first production deadline.
- 3. Check partner readinessDo not promise a live PEPPOL workflow before checking whether counterparties can receive and process documents.
- 4. Choose the operating modelManual tool, accountant dashboard, ERP export, API integration or certified Access Point handoff.
- 5. Prepare receive-side controlInbox, exceptions, responses and audit evidence matter as much as sending invoices.
Core vocabulary
| Term | Meaning | Why it matters |
|---|---|---|
| EN 16931 | European semantic model for electronic invoices. | Defines the business terms and rules used across EU e-invoicing. |
| UBL 2.1 | XML syntax commonly used for PEPPOL invoices. | The file must be structurally correct before business validation is useful. |
| PEPPOL BIS Billing 3.0 | PEPPOL invoice implementation profile. | Controls interoperability between senders, receivers and Access Points. |
| SK-CIUS | Slovak national usage specification. | Adds Slovakia-specific constraints and local identifiers. |
| Access Point | Certified network participant for delivery. | eFaktúra Centrum prepares and controls documents; certified AP handles delivery. |
| Peppol ID | Network identifier used to address participants. | You need a correct endpoint before a live send can work reliably. |
| SMP lookup | Metadata lookup for PEPPOL participants and document capabilities. | Prevents blind sending to a partner that cannot receive the document type. |
| Schematron | Rule layer used to validate XML business constraints. | Production-grade validation combines XML structure, semantic rules and local rules. |
| ViDA | EU VAT in the Digital Age reform package. | Explains why countries are moving toward structured digital reporting and e-invoicing. |
Common mistakes
Starting with ERP replacement
Replacing the whole system is rarely step one. First validate, view and map current outputs.
Ignoring received invoices
Receiving creates exceptions, accounting decisions and evidence. It needs a workflow too.
Treating validation as a black box
A useful validator explains the error, affected field and remediation path.
Confusing preparation with delivery
Preparation tools are not the same as certified PEPPOL network delivery.
Frequently asked questions
These answers intentionally separate product guidance from legal advice. Use them for planning and operational readiness, then confirm final obligations with official sources or your provider.
Does a PDF count as an e-invoice?
No. A PDF is a readable representation. For covered flows, the operational invoice is structured XML that can be validated and processed by systems.
Is eFaktúra Centrum a certified PEPPOL Access Point?
No. It is a preparation, validation, viewing and workflow control layer. Certified network delivery is handled by a certified PEPPOL Access Point.
Do small businesses need to replace their accounting system?
Not as the first step. The practical first step is to validate current exports, understand partner readiness and choose whether the future workflow is manual, accountant-led, ERP-based or API-based.
What should a foreign parent company check first?
Check whether the Slovak entity has the right identifiers, ERP export capability, receive-side workflow, accountant ownership and a provider path for certified delivery.
What happens when XML validation fails?
The error must be connected to a field, cause and remediation path. A useful report separates fatal issues from warnings and helps decide whether the fix belongs to ERP, master data, tax setup or the recipient.
Why does receive-side control matter?
Received e-invoices create accounting actions, exceptions, evidence and approvals. A send-only rollout leaves a hidden operational backlog.
Can the same workflow cover Germany, Poland and Hungary?
Not one-to-one. EN 16931 and PEPPOL vocabulary helps, but each country may use different formats, rollout rules or clearance models. Slovakia should be handled as an SK-CIUS workflow first.
When should API integration start?
After current document samples, validation rules, status model, error handling, access roles and provider boundary are clear. API work without those decisions usually creates rework.
European context
Slovakia is part of a wider European move toward structured invoicing and digital VAT controls. The practical lesson is not to copy another country blindly, but to understand whether the model is PEPPOL-based, clearance-based or hybrid.
| Country | Model | Operational lesson for Slovakia |
|---|---|---|
| Belgium | PEPPOL-oriented B2B rollout. | Closest practical comparison: start partner readiness and Access Point planning early. |
| Germany | XRechnung/ZUGFeRD and phased obligations. | Receiving capability and readable workflows matter before full sending obligations. |
| Poland | KSeF clearance model. | Do not assume PEPPOL rules cover Polish clearance; treat it as a separate country workflow. |
| Hungary | NAV online invoice reporting. | Clearance/reporting systems need different status handling than PEPPOL delivery. |
| Italy | Centralized SDI clearance. | Evidence, retries and official responses become core operational objects. |
| Slovakia | PEPPOL BIS 3.0 plus SK-CIUS. | Build local validation, partner readiness and certified delivery handoff around Slovak rules. |
Role-based checklist
- Company owner: confirm whether customers and suppliers are affected, then choose a low-friction operating model.
- Accountant: map clients, VAT status, receive-side exceptions and evidence requirements.
- ERP team: export UBL samples, validate them and fix master-data or tax-rule issues before integration.
- Developer: align API handoff, rule IDs, webhook statuses, retries and artifact return.
- Finance manager: define approval, archiving, payment risk and audit trail expectations.
- Foreign HQ: avoid assuming one EU template; Slovakia needs SK-CIUS-aware rollout control.