Germany mandates structured e-invoicing for public-sector suppliers and is rapidly expanding requirements to B2B transactions. The two dominant formats — XRechnung and ZUGFeRD — both follow the European EN 16931 standard, but validating them correctly is more nuanced than running an XML schema check.
This post explains what XRechnung validation actually involves, where invoices commonly fail, and why technical validity alone is not enough for real-world accounting workflows.
Table of contents
Open Table of contents
What is XRechnung?
XRechnung is Germany’s national implementation of the European e-invoicing standard EN 16931. It defines a set of business rules on top of two underlying XML syntaxes:
- UBL (Universal Business Language) — the more widely used syntax internationally
- CII (Cross Industry Invoice) — the UN/CEFACT syntax, common in German and French implementations
Both carry the same semantic content (invoice number, dates, parties, totals, VAT breakdowns) but use different XML structures and namespaces. A validator must handle both.
ZUGFeRD is a related format: a PDF/A-3 document with an embedded XML payload. The XML inside a ZUGFeRD PDF is either UBL or CII, so once extracted, the same validation logic applies.
The three layers of validation
Most people think of validation as “does the XML parse correctly?” In practice, there are three distinct layers, and invoices can fail at any of them.
Layer 1: Structural validity
The XML must be well-formed and use the correct root element and namespaces. A UBL invoice uses urn:oasis:names:specification:ubl:schema:xsd:Invoice-2, while a CII invoice uses urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100. Getting this wrong means the document isn’t recognized as an e-invoice at all.
For ZUGFeRD, there’s an additional step: the XML must actually be embedded in the PDF. Not every PDF that looks like an invoice contains structured data — scanned PDFs without embedded XML are a common source of confusion.
Layer 2: Field-level and arithmetic checks
Even with valid structure, invoices frequently have issues with:
- Missing mandatory fields — invoice number, issue date, currency code, supplier name, and buyer name are all required. In practice, buyer name is the most commonly omitted field.
- VAT arithmetic — the sum of VAT breakdown amounts must match the declared VAT total. Rounding differences across line items are a frequent source of mismatches, especially in invoices with multiple tax rates.
- VAT breakdown consistency — if the invoice declares a non-zero VAT total, it must include a breakdown by tax rate. Missing breakdowns are a common error in CII invoices generated by smaller ERP systems.
- Date consistency — issue date, due date, and service period should be logically consistent. An invoice with a due date before the issue date will pass schema validation but indicates a data quality problem.
Layer 3: Business and policy checks
This is where most real-world rejections happen. An invoice can be structurally valid and arithmetically correct but still fail during booking because:
- A buyer reference (Leitweg-ID for public-sector invoices, or an internal reference for corporate buyers) is missing
- A required purchase order number is absent
- The invoice references a vendor not in the buyer’s master data, or the vendor’s IBAN has changed since the last invoice
- Payment terms on the invoice don’t match what’s agreed in the contract
- The invoice amount deviates from a recurring contract fee without explanation
These are not XRechnung schema errors. They’re operational readiness problems that cause invoices to bounce between accounting, procurement, and suppliers — sometimes for weeks.
Common validation errors in practice
After processing thousands of invoices, certain patterns appear repeatedly:
| Error | Frequency | Impact |
|---|---|---|
| Missing buyer reference | Very common | Blocks public-sector processing entirely |
| VAT breakdown sum mismatch | Common | Accounting system rejects the invoice |
| Missing supplier VAT ID | Occasional | Cannot match to vendor master |
| Due date before issue date | Occasional | Data quality flag |
| Wrong currency code format | Rare | Parse failure |
The high-frequency errors are almost never caught by schema validation. They require field-level and policy-level checks.
Why deterministic validation matters
For Kanzlei offices (tax advisory firms) processing invoices for dozens of mandants (clients), validation must be deterministic: the same invoice with the same rules must always produce the same findings. This matters because:
- Audit trails require reproducibility
- Re-processing an invoice after a rule update should produce explainably different results, not random variation
- Batch operations across mandants must be consistent
This means validation rules need to be versioned. When a rule is added or changed, the version increments, and each invoice records which rule version was applied. Re-processing uses the new version and creates a new evaluation — the old one is preserved for audit.
Schema validation is necessary but not sufficient
The takeaway: XRechnung/ZUGFeRD schema validation catches structural problems, but most invoice rejections in real workflows are caused by missing references, policy violations, or commercial mismatches that schema validation doesn’t cover.
A practical validation system needs all three layers — structural, field-level arithmetic, and business/policy checks — applied deterministically and with clear evidence for every finding.
This is the problem I built RechnungRadar to solve. It runs the full validation pipeline on every incoming invoice and produces actionable findings before the invoice reaches DATEV or an ERP system — so that clarification loops happen once, not repeatedly.