Validating an XRechnung: EN 16931 and typical errors

Why “looks fine” is not enough

A viewer dutifully renders even a faulty XRechnung as a pretty invoice. The appearance says nothing about formal correctness.

Validation answers a different question: does this file match the rules by which it may be processed, posted and audited? Only this question decides whether the invoice may enter the approval run.

Funnel graphic: validation stages of an XRechnung — EN 16931 schema, mandatory fields, totals logic, tax rate — with result approved or rejected. — The validation stages an XRechnung should pass before it is approved.

Stage 1: schema and EN 16931

First the technical level: is the file even valid XML in the right standard (UBL or CII)? Then the business level: does it meet the business rules of the European norm EN 16931?

KoSIT provides an official validator with Schematron rules for this. It checks not only whether fields are present but whether their contents fit together. An invoice that fails here is not a valid XRechnung — no matter how tidy it looks in the viewer.

Stage 2: mandatory details under § 14 UStG

Beyond the norm an invoice must contain the VAT mandatory details: complete names and addresses, tax number or VAT ID, invoice date and number, quantity and type of service, service date, consideration and tax amount.

If one of these is missing the invoice is not proper — with consequences up to an endangered input-VAT deduction. That is not formalism, that is hard cash.

Stage 3: do the math, don't just read

The underrated stage. Do the line items sum to the net amount? Does the stated tax amount match the tax rate? Do net plus tax equal the gross amount?

Sounds obvious, in practice it is not. Rounding differences, wrong tax keys, swapped line items occur. A validation that does not recompute is only half the job.

The most common errors in the wild

Always the same suspects:

Missing or wrong VAT ID or tax number.
Service date not stated.
Totals that do not add up — net, tax, gross inconsistent.
Wrong or impermissible tax rate for the service.
Wrong ZUGFeRD profile (MINIMUM/BASIC WL instead of at least EN 16931).
Structurally valid but a mandatory field empty in content.

What happens when an invoice fails

A faulty invoice should not be posted silently and not deleted silently. It makes sense to detect it, document it and clarify it with the supplier — ideally before payment.

Validation at intake saves exactly this loop. What does not pass the check does not even enter approval — and does not land as a problem in the annual close.

Frequently asked questions

What does validating an XRechnung mean?

Checking it against the norm and the VAT obligations: valid schema, fulfilment of the EN 16931 business rules, present mandatory details and consistent totals.

What can I validate an XRechnung with?

With the official KoSIT validator (Schematron rules), with accounting software with a check function or with an inbox solution that validates every incoming invoice automatically.

What is EN 16931?

The European norm for the electronic invoice. It defines the business rules an XRechnung must meet to be valid.

What are the most common validation errors?

Missing VAT ID or tax number, missing service date, totals that don't add up, wrong tax rate and a too-lean ZUGFeRD profile.

What do I do with a faulty XRechnung?

Do not post or delete it silently, but detect, document and clarify it with the supplier — ideally before payment.

Validating an XRechnung: EN 16931, mandatory fields and typical errors