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 and extends structured exchange obligations to private-sector trade in Slovenia.

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. ZIERDED was enacted in late 2025; some older results still mention a 2027 go-live, but the operative start date for the broader domestic B2B mandate is 2028-01-01.

If you sell to budget users in Slovenia, the 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.

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.

Decision rule: if the buyer is a Slovenian budget user, e-invoicing is already mandatory today. If not, prepare for ZIERDED's 2028-01-01 expansion — the current public-sector requirement is not the same as the 2028 mandate. For a peer comparison, Liechtenstein's public-sector e-invoicing supplier rules show a similar split between today's public-sector obligations and 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. The law creates a broader requirement for businesses trading with other businesses inside Slovenia, extending mandatory e-invoice exchange beyond the UJP-linked public-sector route. Older references still mention a 2027 start date — that is no longer the enacted position. The date that should drive your roadmap is 2028-01-01.

Businesses still using informal PDF-and-email workflows for domestic B2B transactions should treat 2026 and 2027 as preparation years. The work is broader than editing an invoice template: structured invoice formats, defined exchange routes, file-level validation, and exception handling when an invoice is rejected or cannot be processed as sent.

ZIERDED sets the deadline and scope of the obligation; the separate operational question is how a compliant e-invoice must be issued, transmitted, received, and validated. Today, a supplier billing a budget user must use the UJP-linked 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 avoids the common assumption that any digital invoice file automatically satisfies the 2028 mandate.

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.

eSLOG 2.0 is the Slovenia-specific format profile aligned with EN 16931, the European semantic model. It defines how invoice fields — supplier details, buyer details, dates, tax amounts, totals, references, and line items — are encoded so software can import, check, and route them. If you need the VAT-law side of those content rules rather than the exchange-format side, see Slovenia VAT invoice fields and simplified invoice rules.

The real test is whether your ERP, billing, AP, or invoice-routing tools can handle eSLOG 2.0 XML, with PDFs treated as annexes rather than the invoice itself. For an EU peer that hits the same 2028 deadline, see Latvia's e-invoicing requirements.

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.

From 2028, the same channel logic extends to domestic B2B. The framework is built around approved electronic exchange channels, not casual delivery by email — a business will need to decide both which invoice format it can generate and how it will send and receive those invoices in compliant fashion. 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. Update supplier onboarding and AP intake rules together. Ask suppliers which Slovenian format and exchange channel (UJP, provider, network) they will use, capture their identifiers and testing contacts on onboarding forms, and define what counts as a valid intake source after go-live: which mailbox, portal, or network endpoint receives invoices, whether AP may key in missing data or must reject incomplete files, and who owns exception handling when the structured XML and the visual PDF do not match.

6. Align invoice data with downstream VAT and reporting processes. Structured invoice data becomes more valuable when your records, reconciliation, and VAT workflow share source data. See Slovenia VAT records and DDV-O pre-fill workflow for the reporting-side connection.

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 and low-volume exception scenarios once the technical and legal guidance is fully settled.