E-invoicing Germany

German e-invoice validator: XRechnung and ZUGFeRD

Check an XRechnung or a ZUGFeRD invoice the way the KoSIT validator does: the schema, the EN 16931 rules and the XRechnung rules (BR-DE-*), with KoSIT's rule levels. ZUGFeRD PDFs work too, and nothing is uploaded.

The mandate in short

Since 1 January 2025 every business in Germany must be able to receive electronic invoices from other businesses. From 1 January 2027 businesses with a turnover above 800,000 euros in the previous year must issue them, and from 1 January 2028 all businesses do. Invoices to public buyers have been electronic for longer, in XRechnung with the buyer's Leitweg-ID.

An e-invoice under the mandate is a structured invoice that follows EN 16931. In practice that is XRechnung (UBL or CII) or ZUGFeRD / Factur-X from version 2.0.1 in a profile that carries the full EN 16931 data, such as EN 16931 (COMFORT) or EXTENDED. The MINIMUM and BASIC WL profiles do not count as e-invoices.

How to check an invoice

  1. Open the validator with the XRechnung profile, or drop a ZUGFeRD PDF: the profile is picked from the identifier inside it.
  2. Press Validate. The schema comes first, then the EN 16931 and XRechnung rules.
  3. Click a rule id for what it checks and how to fix it.

What is checked

For XRechnung, the levels follow the KoSIT validator configuration for the scenario the invoice declares (standard, Extension or CVD), so a rule KoSIT lowers to a warning does not fail the invoice here either. We compared the results with the KoSIT validator on the XRechnung test suite and the EN 16931 invoices of the ZUGFeRD corpus: the verdict and the rules reported were the same on every one.

Common reasons for a rejection are a missing buyer reference (BR-DE-15, which carries the Leitweg-ID for public buyers), missing payment instructions (BR-DE-1), a seller contact without phone or email (BR-DE-2) and cash discount terms in free text instead of the coded form (BR-DE-18).

Profiles to check with

Rules invoices break most

Each one has a page with what it checks, its test and, for many, how to fix it.

  • BR-DE-15: Das Element "Buyer reference" (BT-10) muss übermittelt werden.
  • BR-DE-1: Eine Rechnung (INVOICE) muss Angaben zu "PAYMENT INSTRUCTIONS" (BG-16) enthalten.
  • BR-DE-2: Die Gruppe "SELLER CONTACT" (BG-6) muss übermittelt werden.
  • BR-DE-TMP-32: Eine Rechnung sollte zur Angabe des Liefer-/Leistungsdatums entweder BT-72 "Actual delivery date", BG-14 "Invoicing period" oder in jeder Rechnungsposition BG-2...
  • BR-DE-18: Skonto Zeilen in … müssen diesem regulärem Ausdruck entsprechen: …. Die Informationen zur Gewährung von Skonto müssen wie folgt im Element "Payment terms" (BT-2...
  • BR-DE-21: Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen.
  • BR-CO-15: Invoice total amount with VAT (BT-112) = Invoice total amount without VAT (BT-109) + Invoice total VAT amount (BT-110).

Questions

Is the invoice uploaded?

No. The schema check and the rules both run in your browser. Only the API and URL monitors validate on our servers.

Is this the same as the KoSIT validator?

It runs the same published rule files and applies the levels of the KoSIT configuration (2026-08-31), and a weekly comparison with the KoSIT validator checks that the results stay the same.

Can I validate a ZUGFeRD PDF?

Yes. Drop the PDF: the XML attached to it is taken out in your browser and checked against the profile it names, and the attachment and its XMP metadata are checked against what ZUGFeRD asks.

Which XRechnung version is used?

XRechnung 3.0.2 with the XRechnung rules 2.6.0 and the EN 16931 rules 1.3.16, as in the KoSIT configuration of 2026-08-31.

Official sources

Other countries