Access is free · takes half a minute · no installation, nothing to configure
Tell us who you are and the validator opens right away. We use your details to keep you posted on the formats and rules that change, not to pass them on.
Fill in four fields and go straight to the tool.
By requesting access you agree that we may contact you about e-invoicing. One click unsubscribes you from every e-mail. Privacy policy.
Three format families, every version that is still in circulation, and both syntaxes. Upload the file you actually have; the validator does the rest.
| Format | Versions | Syntax | Description |
|---|---|---|---|
| XRechnung | 3.0.2 2.3.1 2.2.0 2.1.1 2.0.1 1.2.2 | UBL, CII | The German B2G standard |
| Peppol BIS Billing | 3.0.21 | UBL | The profile used across the Peppol network for invoices and credit notes |
| ZUGFeRD | 2.5.2 EN 16931 2.5.2 Extended | CII | The XML inside the PDF/A-3 file, the part that is legally binding |
Invoice (UBL)
Standard UBL invoice, InvoiceTypeCode 380.
Credit note (UBL)
UBL CreditNote, InvoiceTypeCode 381.
Invoice (CII)
UN/CEFACT CrossIndustryInvoice, the syntax behind ZUGFeRD.
If you are not sure what came out of your system, open the file in a text editor and look at the first element. It tells you the document type straight away.
An XRechnung or Peppol BIS invoice in UBL. Inside it you will find cbc:InvoiceTypeCode with the value 380.
A UBL credit note. Same structure, but the root element is CreditNote and the type code is 381.
The UN/CEFACT syntax. Used by ZUGFeRD and by XRechnung in its CII variant.
A ZUGFeRD invoice is a PDF/A-3 document with the machine-readable XML embedded inside it. The PDF is what people look at, the XML is what systems process, and the XML is what gets validated. Upload the ZUGFeRD file and the validator takes the XML out of it.
The validator runs the same three checks a recipient’s system runs. What passes here is accepted there.
Drop in the XML or the ZUGFeRD PDF. Nothing is installed, nothing is configured, and the file stays in your session.
First the syntax against the XSD schema, then the European business rules of EN 16931, then the rules of the format profile itself.
Every finding names the rule and the element it refers to, so you know which field to change before you send the invoice.
Example output. Your own file gets its own report.
Validation is not a formality. It is the difference between an invoice that gets booked and one that comes back with a message nobody in the team can read.
Public authorities and large buyers reject invoices that break the rules. The invoice comes back and the payment term starts again.
A Peppol access point will not forward a document that fails validation. Better to find out here than to learn it from a delivery error.
EN 16931 is only the base. The national CIUS adds its own rules: the Leitweg-ID, payment terms, mandatory contact data.
If your ERP or middleware produces the file, the report tells you exactly which field the mapping gets wrong, long before the first invoice goes out.
Free access, no installation. The form takes half a minute.
