Known-good UBL, CII and Factur-X documents to test your implementation against — plus one that is broken on purpose.
A complete, valid UBL invoice. The usual starting point when you are implementing EN 16931 from scratch and want a known-good document to diff against.
Download · CEF eInvoicing EN 16931 artefacts (EUPL-1.2)
A credit note is its own document type in UBL, not an invoice with a negative total - this shows the shape.
Download · CEF eInvoicing EN 16931 artefacts (EUPL-1.2)
The CII syntax, which is what sits inside a Factur-X or ZUGFeRD PDF. Same semantic model as UBL, entirely different element names.
Download · CEF eInvoicing EN 16931 artefacts (EUPL-1.2)
A PDF carrying the invoice XML as an attachment named factur-x.xml, but deliberately NOT a compliant Factur-X container — no XMP metadata, no /AF entry. Validate it and then the properly-formed one below to see precisely which container checks it fails.
Download · built here from the CEF CII example
The same invoice as a correct Factur-X container: XMP metadata declaring the profile, the attachment listed in the catalog's /AF array, the right /AFRelationship. Validate it against the one above to see exactly which container checks the incomplete file fails.
Download · built here with the factur-x library (Akretion), from the CEF CII example
An ordinary domestic Slovenian invoice: one service line, standard rate, paid by transfer. It is valid EN 16931 and valid Peppol BIS 3.0 - and XRechnung rejects it on 2 rules, because Germany alone requires a Buyer reference (BT-10) and a named seller contact (BG-6). Nothing about it is wrong; it is simply not German. This is the case that costs people money, and it is what the comparison view loads.
Download · written here, not derived from any vendor or standards-body sample
The Slovenian national format, which is not a variant of EN 16931 at all but UN/EDIFACT INVOIC D.01B written as XML - segment names like S_BGM and D_5004 instead of named fields. One consultancy line, 22% VAT. Validating it checks the file's structure against the official ePOS schema; the EN 16931 business rules do not apply to this syntax and are not run.
Download · written here; the VAT numbers in it are checked against VIES and belong to nobody
A UBL invoice whose VAT amount is wrong on purpose. Valid XML, valid structure, and it fails 2 EN 16931 rules, 9 Peppol rules and 12 XRechnung rules - a compact way to see what each profile actually adds.
Download · built here
Nothing is stored, and the whole invoice is checked, not just this rule. A PDF only works if it is Factur-X / ZUGFeRD — a PDF with the invoice XML inside it.