Faktura

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 →

What is checked, and what is not

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

CheckedThe 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 checkedThe 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

Slovenia has legislated mandatory B2B e-invoicing. Businesses that exchange invoices with the public sector already have to send e-SLOG through the UJP. If you are building or buying accounting software for the Slovenian market, the file it produces has to be valid e-SLOG — and the cheapest moment to find out that it is 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. Preverimo skladnost s shemo e-SLOG 2.0 (ePOS/GZS) in ti povemo točno vrstico in element, kjer je napaka. Poslovnih pravil EN 16931 za ta format ne preverjamo — in tega ne bomo trdili, dokler ne bo res.