Slovakia e-invoicing 2027: An implementation guide for software providers and intermediaries

Software providers preparing for Slovakia e-invoicing in 2027 need to define their operating role, prepare customer selection and authorisation, and ensure receiving registration in Slovakia’s central SMP. They also need to test invoice exchange and support. Domestic obligations apply from 1 January 2027. For ERP, accounting and invoicing platforms, an intermediary arrangement offers a route to serving customers through a certified delivery service provider. When we say “customer” in this article, we mean the business using your platform, called the taxpayer in Slovak law and the end user in Peppol.

OpenPeppol’s Slovakia country profile confirms the January 2027 start. Our Slovakia e-invoicing guide covers the regulatory overview. This article explains the intermediary route and the implementation decisions software providers need to make.

What changes for software providers supporting Slovakia?

Slovakia’s approach combines Peppol invoice exchange with a national tax-data reporting layer. Peppol provides the network for exchanging structured business documents; the Slovak Tax Data Document, or SK TDD, supports reporting invoice information to the tax authority. These are connected but distinct processes, described in the Slovakia Solution Reference Architecture, published by OpenPeppol and hosted by the Financial Administration.

The delivery service operates through certified delivery service providers. The Financial Administration publishes the current list of certified providers. A software vendor may offer customers access through a delivery service intermediary arrangement backed by a certified provider. The Financial Administration’s guidance explains both roles. The customer-facing service a business selects is known in Slovakia as its “digital postman” (digitálny poštár).

An existing Peppol integration gives you a foundation. Your team still needs to assess Slovak onboarding, identifiers, applicable reporting and operational requirements against what the integration already supports.

Slovakia also sits within the wider European shift towards digital VAT reporting. Under the EU’s VAT in the Digital Age (ViDA) reforms, new digital reporting requirements for cross-border B2B transactions apply from 1 July 2030. Experience gained in Slovakia can inform future implementations, but it does not establish compliance with every subsequent ViDA requirement.

Which customers and invoice flows must your platform support?

Start by identifying the legal entities and transactions your software serves.

The Financial Administration’s business manual distinguishes issuing from receiving. Domestic VAT payers must issue electronic invoices for specified domestic supplies. Receiving obligations cover a wider group, including businesses that are not VAT payers when they receive an in-scope invoice. It also includes domestic legal persons that are not taxable persons, such as municipalities and non-profit organisations.

A customer setting labelled simply “VAT registered” is therefore insufficient to determine every implementation requirement.

Build an inventory covering:

• Each customer’s legal entity, establishment and VAT status.
• The domestic invoice flows the platform must send and receive.
• Relevant document types, including corrections and advance-payment invoices where applicable.
• The source of invoice data and the system in which received invoices are processed.

What does becoming a delivery service intermediary involve?

A delivery service intermediary offers a certified provider’s service to customers under a contractual arrangement. This is a different role from becoming a separately accredited delivery service provider.

The Financial Administration’s intermediary registration application sets out the formal route: a contract is concluded between the certified provider and intermediary, and the provider submits the registration application. The form also states that the intermediary is not an independently certified entity and that the provider accepts full responsibility for the intermediary’s activities.

Prepare the arrangement in this order:

• Agree the service scope with the certified provider, including integration, customer support and applicable reporting.
• Supply the intermediary’s business details, public contact information, website and technical webhook details required by the application.
• Coordinate the provider’s submission and confirm the intermediary’s listing before directing customers to select the arrangement.
• Complete the integration and onboarding tests, with an agreed owner for activation, registration and incidents.

Intermediary registration establishes the operating arrangement. Each customer must still complete its own selection and activation journey.

Who is responsible for each part of the implementation?

Agree responsibilities with your infrastructure provider before estimating the engineering work. The following questions can structure that discussion; the final allocation depends on the service and contractual arrangement.

Separate the provider’s technical service from the decisions your application must support. For example, a provider may return a validation error, while your software must explain what the user needs to correct.

Document the handover between organisations as carefully as the connection between systems. Every unresolved task needs an owner and an escalation route.

How does the customer select its provider and intermediary?

Customer selection connects the taxpayer to its chosen provider and intermediary. It should be designed into the onboarding journey before customers begin using the service.

Slovakia’s provider-selection user guide describes the official application: an authenticated user selects a provider/intermediary combination, identifies the taxpayer they represent, supplies contact details and authorises information sharing. The application sends an email and, where configured, a webhook notification to the intermediary.

Design the journey around five steps:

1. Explain which customer representative needs to act and what information is required.
2. Guide that person to the correct provider/intermediary combination in the Financial Administration’s selection application. The application also lists every certified provider and its intermediaries, and the list can be viewed without logging in. To make the selection, the person must be registered on the Financial Administration’s portal and authorised to act for the taxpayer, and the taxpayer must have an assigned DIČ.
3. Match the selection notification and verified taxpayer information to the correct customer account and legal entity.
4. Coordinate central SMP registration with the certified provider and confirm the customer’s receiving capabilities before activation.
5. Complete an initial exchange and explain where subsequent invoices and statuses will appear.

Make incomplete onboarding visible. A customer who has started the process should be able to see what remains outstanding, rather than discover the problem when attempting to send an invoice.

This matters especially when one software account contains several companies. Treat activation as a legal-entity-level process and verify each entity’s status.

What role does Slovakia’s central SMP play?

The Service Metadata Publisher, or SMP, publishes the information needed to discover a participant’s receiving capabilities and delivery endpoint. Slovakia requires its end users to be registered in the national central SMP. The Peppol Authority Specific Requirements place this responsibility on service providers, with access granted after accreditation. The Financial Administration states that a provider may register a customer in the central addressing system only after the customer has given its authorisation through the official application, and that failure to follow this order will be sanctioned.

Arratech’s Peppol ID guidance confirms that Slovak registrations under scheme 0245 use the DIČ tax identifier, are published in the national SMP rather than Arratech’s own SMP, and require the taxpayer’s verification code from the Financial Administration.

Keep three milestones distinct in your software: the customer has selected the service; the required authorisation and registration have been completed; and receiving is operational. Selection alone should not trigger a “ready to receive” status. Verify the published capabilities and complete an inbound test.

For an intermediary, agree who receives and handles the verification information, who updates the national SMP and how activation is confirmed. Plan provider changes as a separate workflow, including the handover of the existing registration. The Peppol Authority Specific Requirements require the existing provider to deregister the end user from the centralised SMP within three working days when the end user changes provider.

What invoice data must your platform prepare?

Map the data before building the final customer interface.

The Financial Administration identifies Peppol BIS, based on UBL 2.1 and the European standard EN 16931, as the relevant structured invoice format. Review its accounting software guidance and current validation materials, including the Slovak Peppol BIS validation rules, with your provider.

Check whether buyer and seller details, identifiers, tax categories, amounts and references can be populated consistently from your existing records. Identify fields that need new controls or clearer user instructions.

Map the DIČ used for central SMP registration to the participant identifier field. Avoid assuming that an existing VAT-number field contains the correct network identifier.

Validate representative customer documents early. Include the variations your platform actually supports, rather than relying on one technically valid sample invoice.

What should you test before moving customers into production?

Test the service from the customer’s perspective, as well as the API connection.

The Slovakia Solution Reference Architecture treats invoice and tax-data exchanges as distinct flows with their own outcomes. Your application should preserve enough information to distinguish them. A single “sent” label can conceal work that remains unresolved.

Use this starting test matrix and adapt it to the applicable requirements and supported service.

For each test, record the expected result, owner and evidence. Agree who approves the transition to production.

Consider an illustrative example: an ERP vendor completes a successful outbound test, but an incoming invoice cannot be matched to the right customer company. The connection works, yet the customer workflow remains incomplete. Testing both directions exposes that gap before launch.

What needs to work after the first invoice?

Production readiness includes the people who will run the service.

Agree how long a transaction may remain pending before investigation, who handles different error categories and when an issue must be escalated to the provider. Give customer support access to the references and status history needed to investigate without asking customers to reconstruct the transaction.

Confirm retention separately from delivery. Do not assume that a transmission log provides invoice archiving, or that every item visible in a portal will remain available for the period your customer requires. The Financial Administration requires certified providers to store invoice delivery and receipt logs for at least six months. That requirement does not replace your customers’ own invoice retention obligations.

Assign an owner for specification and regulatory updates. That person should coordinate changes across product, engineering, support and customer communications.

How does Arratech support software providers and intermediaries?

Arratech operates as a certified delivery service provider in Slovakia, the role that submits an intermediary’s registration and takes responsibility for it under the official process. Arratech provides Peppol infrastructure and integration resources for software providers. Its Slovakia documentation describes participant registration, invoice validation and delivery tracking. Its identifier guidance explains the national SMP registration requirement.

For a software provider considering the intermediary route, the setup discussion should establish the contractual and registration arrangement, handling of customer-selection notifications and verification information, national SMP responsibilities, invoice integration and support handover.

Use Arratech’s Slovakia documentation as the technical starting point, then agree the current service scope for your implementation. As the certified provider, we take care of the tax data documents. Before you plan your customer launch, we’ll walk you through the onboarding steps we handle.

For the regulatory overview, explore our Slovakia e-invoicing compliance guide.

Discuss your Slovakia intermediary setup and integration requirements with Arratech.

Discuss Your Slovakia Integration