e-SLOG 2.0 validator — check a Slovenian e-invoice

Upload an e-SLOG 2.0 invoice and find out whether it is structurally valid, with the exact element and line number of anything wrong. Free, no account, nothing stored. As far as I can tell this is the only English-language validator that accepts the format at all.

Validate an e-SLOG invoice → Field mapping: where each EN 16931 field goes →

What is checked, and what is not

Being straight about this matters more than looking capable, so:

Checked	The file's structure against the official e-SLOG 2.0 XML schema published by ePOS (GZS). Wrong element, wrong order, missing mandatory segment, value too long, wrong data type — each reported with its line number.
Not checked	The EN 16931 business rules (VAT arithmetic, category consistency, the BR-* and BR-CO-* rules). e-SLOG maps to the European business terms, but that mapping is published as prose in a PDF, not as anything a machine can run. I will not approximate it and call the result compliance.

So: a file that passes here is a well-formed e-SLOG 2.0 document. That is what Slovenian receiving systems reject on most often, and it is not the same thing as being a correct invoice.

How permissive is the schema? More than you would hope. I tested it: a document containing only a header, a date, a total and nothing else — no seller, no buyer, no line items — passes. The schema constrains the shape of what is present, not whether the commercially necessary parts are there at all. Treat a pass here as "your XML will be parsed", not as "your invoice is complete". I would rather tell you that than let the green box imply more than it earned.

Why e-SLOG is different from the rest of this site

The other formats here — Peppol BIS, XRechnung, Factur-X — are all national variants of the same European standard, written in UBL or CII. You can layer extra rules on top of them and they still speak the same language.

e-SLOG 2.0 is not one of those. It is UN/EDIFACT INVOIC D.01B expressed as XML, in its own namespace urn:eslog:2.00, with segment names like S_BGM and D_1004 rather than named fields. That is why it needs a separate validator and why the three profile buttons on the front page do not apply to it.

Slovenia's mandate

Invoicing the public sector has required e-SLOG through the UJP since 2015. B2B becomes mandatory on 1 January 2028, under the act adopted on 23 October 2025 — ZIERDED, the Act on the Exchange of Electronic Invoices and Other Electronic Documents.

Two things about it are worth knowing if you are building software for this market:

• There is no clearing platform. Unlike Italy or Poland, invoices are not reported to the tax authority. Exchange is decentralised — e-route providers, direct system-to-system exchange, the Peppol network, or a free application aimed at small businesses.
• The date has already moved twice, from earlier proposals of 2026 and then 2027. Treat 2028 as firm but not immovable, and confirm it before you plan a release around it.

Which makes 2026-2027 the window in which Slovenian accounting software has to start emitting valid e-SLOG. The cheapest moment to find out that yours does not is now.

Slovenia's mandate, dates and formats →

Automate it

curl -X POST --data-binary @racun.xml \
  -H 'Content-Type: application/xml' \
  https://invoicevalidator.eu/v1/validate

The format is detected automatically; you do not have to say it is e-SLOG. The JSON response carries a checked field stating in words what was actually run against your file. Full API documentation →

Po slovensko

Naloži e-SLOG 2.0 račun in preveri, ali je strukturno pravilen. Preverjanje je brezplačno, brez registracije, datoteka se ne shrani nikamor. Cela stran po slovensko →

Check a Slovenian e-invoice