Slovenia E-Invoicing Requirements: 2026-2028 Guide

Slovenia e-invoicing requirements are already live, but only for part of the market today. If you issue invoices to Slovenian budget users, e-invoicing is already mandatory, the public-sector exchange point is UJP, and a PDF sent by email on its own is not a compliant exchange method. That current rule is narrower than the broader domestic B2B obligation under ZIERDED, which starts on 2028-01-01. In other words, Slovenia already requires structured electronic invoicing in the public-sector budget-user workflow, while the wider Slovenia e-invoicing mandate 2028 extends comparable domestic exchange obligations across B2B transactions from the start of 2028 and pushes businesses to prepare for structured invoice formats such as eSLOG.

The timeline matters because many English-language summaries are now outdated. For budget users, Slovenia e-invoice requirements have effectively been in force since 2015. The broader B2B direction was announced in May 2025, then ZIERDED was adopted on 2025-10-23, promulgated on 2025-10-31, and published in the Official Gazette of the Republic of Slovenia on 2025-11-06. Some older results still mention a 2027 go-live, but that is no longer the enacted position. The operative start date for the broader domestic B2B mandate is 2028-01-01. For finance teams, that distinction changes how you assess risk. If you sell to budget users in Slovenia, the key question is whether your intake and outbound process already supports the required structured exchange channel rather than relying on emailed PDFs. If you trade only with private-sector counterparties, the immediate issue is readiness for ZIERDED rather than a live universal B2B rule today. That means separating four practical questions now: who is in scope, which formats count as a compliant e-invoice, which exchange channels are allowed, and what operational changes should be completed before 2028.

Who already has to use e-invoicing in Slovenia

The current live rule does not cover every invoice exchanged between private businesses in Slovenia. Today, the operative requirement is narrower: it applies to invoices sent to Slovenian budget users. That means Slovenia public sector e-invoicing is already mandatory for a defined part of the market, even though the broader domestic B2B mandate only arrives later.

In practice, this is not a pilot or a future-state policy question for affected suppliers. Under official Slovenian guidance on e-invoicing of budget users, the Public Payments Administration acts as the single entry and exit point for budget users' incoming and outgoing invoices, and everyone doing business with budget users issues e-invoices for supplied goods and services. For finance teams, that means the obligation is already operational whenever you supply goods or services to an in-scope public-sector customer.

The practical scope turns on the customer, not on whether all of your sales are public-sector sales. If your customer is one of Slovenia's budget users, you should assume the e-invoicing exchange requirement already applies to that transaction. The Public Payments Administration of the Republic of Slovenia is therefore part of the current compliance path for those invoices, while the rest of your domestic customer base may still be operating under pre-2028 rules. In practice, finance teams usually verify this by checking procurement or onboarding documents, the customer master record, or any UJP and government guidance referenced by the customer when invoice-routing requirements are set.

Do not confuse this existing public-sector framework with the later nationwide expansion. The current regime is about invoicing budget users through the established public-sector route; the 2028 reform extends mandatory structured exchange much further across domestic B2B transactions. A workable decision rule is straightforward: if the buyer is a Slovenian budget user, treat e-invoicing as already live today. If the buyer is not a budget user, you still need to prepare for the later B2B expansion, but the current public-sector requirement is not the same thing as the 2028 mandate. If you want a useful comparison point, Liechtenstein's public-sector e-invoicing supplier rules show a similar need to separate today's public-sector obligations from wider economy-wide mandates.

What changes on 1 January 2028 under ZIERDED

From 1 January 2028, ZIERDED expands Slovenia's e-invoicing rules from the current public-sector and budget-user workflow into the domestic B2B space. In practical terms, the law is not just about invoicing government-related recipients anymore. It creates a broader requirement for businesses trading with other businesses inside Slovenia, which is why many teams now refer to the Slovenia e-invoicing mandate 2028 as the real compliance turning point.

That scope point matters. The change should be understood as a domestic business-to-business expansion, not as a claim that every Slovenian invoice is already covered today or that every invoicing scenario has been under the same rules up to now. At present, many companies only encounter structured e-invoicing when dealing with budget users and the channels tied to that environment. ZIERDED changes that planning baseline by extending mandatory e-invoice exchange beyond that existing route.

Older references still mention a 2027 start date. Some draft-law commentary and early summaries circulated before the final timeline was settled, so you may still see outdated statements online. For operational planning, the date to work with is 2028-01-01. If you are building compliance timelines, vendor communications, or ERP change requests, that is the enacted start date that should drive your roadmap for Slovenia B2B e-invoicing 2028.

For finance operations, the biggest implication is that businesses still using informal PDF-and-email workflows for domestic B2B transactions should treat 2026 and 2027 as preparation years, not as spare time. The likely work is broader than editing an invoice template. You may need to prepare for structured invoice formats, defined exchange routes, checks on whether files meet the required standard, and internal controls for handling exceptions when an invoice is rejected or cannot be processed as sent.

That said, the legal scope change and the technical delivery method are not the same question. ZIERDED sets the deadline and scope of the obligation for domestic B2B exchange. The separate operational question is how a compliant e-invoice must be issued, transmitted, received, and validated in practice. A simple way to picture the difference is this: today, a supplier billing a budget user must use the UJP-linked public-sector route; from 2028, a domestic invoice between two private Slovenian businesses also needs a structured exchange route rather than ad hoc PDF-by-email delivery. Keeping those two layers separate helps avoid a common mistake: assuming that once the 2028 mandate exists, any digital invoice file automatically satisfies it.

Why a PDF is not the same as a compliant e-invoice

A common mistake is to treat any digital invoice as an e-invoice. In Slovenia, that is not enough. A PDF sent by email may show the invoice contents to a person, but it does not by itself satisfy the core compliance idea behind electronic invoicing. The compliance issue is the exchange of invoice data in a structured format that systems can process, not just the delivery of a document image.

That distinction is already visible in the budget-user workflow. Slovenian guidance describes an electronic envelope in XML together with eSLOG XML, while PDF files can be included as annexes. In other words, the PDF can accompany the invoice as a readable copy or supporting document, but it is not the structured e-invoice itself. In this workflow, the XML payload is what matters operationally.

In practical terms, the Slovenia eSLOG 2.0 format is the invoice syntax businesses need to think about when data moves from one system to another. eSLOG 2.0 is not about how the invoice looks on screen. It is about how invoice fields such as supplier details, buyer details, dates, tax amounts, totals, references, and line items are encoded so software can import, check, and route them. That is what makes it a structured XML invoice rather than a static file attachment.

EN 16931 fits into this because it provides the European semantic model for electronic invoicing. Put simply, EN 16931 defines the business meaning of the invoice data that should be exchanged consistently across systems and countries. eSLOG 2.0 is the format layer Slovenian businesses encounter in practice, while EN 16931 is the interoperability layer behind the data model. Finance teams do not need to treat this as a theoretical standards exercise. They need to understand that machine-readable invoice data is the real basis of compliant exchange.

This is why the PDF-versus-e-invoice distinction matters so much in day-to-day operations. A team may be fully comfortable creating and emailing PDF invoices, but that does not mean it can comply with structured exchange requirements. The real test is whether your ERP, billing, AP, or invoice-routing tools can:

• generate a structured XML invoice
• receive a structured XML invoice
• validate required fields and format rules
• route the invoice into approval, posting, and archive workflows without rekeying data

For most finance teams preparing for Slovenia's rules, that is the practical reset to make now. Do not ask only whether you can send an invoice electronically. Ask whether your systems can handle a structured XML invoice in the Slovenia eSLOG 2.0 format, with PDF attachments treated as supporting annexes rather than substitutes for the invoice data itself.

How UJP, UJPeRacun, and approved exchange channels fit together

The Slovenia UJP e-invoice workflow is easiest to understand as a routing model, not just a file-format rule. For invoices involving budget users, UJP sits at the center as the public-sector entry and exit point. That means the sender does not just create a compliant e-invoice and send it however they like. The invoice has to enter the UJP exchange flow through an accepted route so it can be directed to the correct public recipient.

In practice, there are two common ways this works today for suppliers billing budget users. Larger or more automated issuers usually send through a bank, an e-invoicing provider, or another integrated exchange route connected to UJP. Smaller issuers can use UJPeRacun instead, which is the public portal for preparing and sending e-invoices without building a deeper system connection. UJPeRacun is intended for smaller issuers, and its interface is available in Slovene only.

Operationally, the control points matter as much as the invoice itself. The sender creates the structured invoice, the chosen channel passes it into the exchange layer, and UJP routes it onward to the budget user. Before the invoice reaches the recipient's AP or accounting workflow, the exchange path needs to support the right recipient identification, the right structure, and the routing data needed to deliver it to the correct entity. If any of that is wrong, the problem arises before normal invoice processing even starts.

That channel logic becomes even more important for the wider domestic B2B regime from 2028. The enacted framework is built around approved electronic exchange channels, not casual delivery by email. In other words, a business will need to decide not only which invoice format it can generate, but also how it will send and receive those invoices in a compliant way. If you also need to separate e-invoicing from FURS confirmation, cash-register obligations, or miniBlagajna use, see Slovenia fiscal verification of invoices.

At a practical level, one common model is provider-based exchange. A business selects an approved e-invoicing route, sends the invoice through that channel, and the recipient receives it through its own connected route. The exact approved route may differ: businesses may use a service provider, another approved network route, direct exchange where both sides are equipped for it, or a free public application for smaller-volume use. The planning task is the same in every case: decide which route each supplier or customer relationship will use and how structured invoices will be validated before they hit AP.

For finance teams, the takeaway is straightforward: map the full path, not just the document. Decide who creates the invoice, which channel transmits it, how the recipient endpoint is identified, where format and routing validation occur, and how accepted invoices enter AP or accounting workflows. That is the practical difference between merely producing an electronic file and operating a compliant exchange process.

A finance-team checklist for getting ready before 2028

Use the period before 1 January 2028 to turn Slovenia's legal requirements into a controlled invoice-processing design, not just a policy note. The key task is to separate what is already mandatory for dealings with budget users from what will become mandatory across domestic B2B transactions, then build intake, validation, and routing rules around those two realities.

1. Map invoices by legal scope, not just by customer type. List every outbound and inbound invoice flow and tag it as:

   • already subject to public-sector e-invoicing rules because a Slovenian budget user is involved
   • likely to fall into the domestic B2B mandate from 1 January 2028
   • needing separate review if it may sit outside the domestic mandate

2. Identify where your current process still depends on PDFs and email attachments. For each flow, note whether the operational record today is an emailed PDF, a portal upload, EDI, or a structured invoice file. This shows where the gap is largest, because a PDF can remain a visual copy for people, but the compliant business record must be the structured e-invoice.

3. Confirm which structured formats your ERP and invoice gateway can send, receive, and validate. Do not stop at "we support e-invoicing." Check whether your systems can:

   • import and export the XML formats you will need in Slovenia
   • validate mandatory fields, tax data, supplier and buyer identifiers, totals, and line-level logic
   • reject malformed files before they enter AP
   • preserve the original structured file for audit and dispute handling

4. Choose an exchange-channel model early. Decide whether each invoice stream will move through UJP-linked public-sector channels, an approved service provider, another approved network route, or a mixed model. The right answer may differ by customer group. Teams comparing regional rollout models can also look at North Macedonia's e-Faktura rollout and non-cash invoice split to see how channel choices and scope splits affect operations.

5. Define invoice intake rules for AP and shared-services teams. Write clear rules for what counts as a valid intake source after go-live:

   • which mailbox, portal, or network endpoint can receive invoices
   • whether AP may key in missing data or must reject incomplete files
   • when a supplier must resend a corrected XML invoice instead of sending a revised PDF
   • who owns exception handling when the structured file and the visual copy do not match

6. Separate the structured record from the visual copy in your workflow. If you still need PDFs for human review, archive them as presentation copies only. Match them to the structured invoice, but make the XML record the source for booking, validation, routing, and audit support. This prevents teams from approving the image while ignoring data-level errors in the actual e-invoice.

7. Upgrade supplier onboarding now. Ask suppliers how they will deliver compliant e-invoices, what format they support, and which exchange channel they intend to use. Update onboarding forms so vendors provide the identifiers, delivery details, and testing contacts your finance team will need before 2028. Suppliers serving both public entities and private Slovenian buyers should not be onboarded with two inconsistent invoice processes.

8. Assign routing responsibilities inside finance operations. Document who owns:

   • supplier communication and enablement
   • master-data quality
   • XML validation and rejection rules
   • exception queues
   • approval routing after successful validation
   • final posting and archive controls

9. Test validation controls against real failure scenarios. Before 2028, run sample files with missing tax fields, invalid identifiers, broken totals, duplicate invoice numbers, and mismatched buyer information. AP should know which errors trigger automatic rejection, which go to manual review, and which require supplier correction before the invoice can enter approval.

10. Align invoice data with downstream VAT and reporting processes. Structured invoice data becomes more valuable when your records, reconciliation, and VAT workflow are consistent. That is where Slovenia VAT records and DDV-O pre-fill workflow becomes relevant, especially for teams that want invoice intake and tax reporting controls to use the same source data.

11. Build a phased readiness plan by transaction volume and risk. Start with high-volume suppliers, public-sector counterparties, and domestic B2B flows that are currently most manual. Smaller edge cases can follow once the core intake, validation, and routing model is stable.

Prioritize now: scope mapping, system format support, exchange-channel decisions, supplier onboarding design, and XML validation rules. Leave for closer to 2028: final cutover timing, low-volume exception scenarios, and last-mile process tuning once the mandatory technical and legal guidance is fully settled.