One point of standing before anything else. The binding text is the German one — the Umsatzsteuergesetz as published, and the BMF-Schreiben as issued. This page is a working guide for a reader who does not read German; where it matters, check the instrument, and where the two diverge the German text governs.
What is legally an E-Rechnung in Germany?
Under § 14 Abs. 1 UStG an E-Rechnung is an invoice in a structured electronic format which is created, transmitted and received electronically, permits electronic processing, and complies with EN 16931. Everything else — paper, PDF, TIFF, JPEG, a Word file — is a sonstige Rechnung, an invoice that is not an E-Rechnung, and in electronic form it requires the recipient's consent.
The BMF's formulation is that in particular the formats customary in Germany, XRechnung and ZUGFeRD from version 2.0.1 — with the exception of the MINIMUM and BASIC-WL profiles — meet the VAT requirements for an E-Rechnung. Two things sit in that sentence. There is no ranking between the two formats. And the exception is in the parenthesis, which is precisely the part implementation projects read past.
A note for anyone outside Germany trying to work from first principles: EN 16931 is a CEN standard and is sold, not published openly. That is why national implementations matter so much in practice. The semantic model was mandated for public-sector invoicing across the EU by Directive 2014/55/EU, and each Member State then specifies how it is used. XRechnung is the German specification of that model. A team that cannot read the standard directly is working through the national specification whether it intends to or not.
When does XRechnung fit, and when ZUGFeRD?
The decision reduces to one question: does a human have to be able to read the document? Where the counterparty processes the invoice entirely by machine, a PDF image is ballast that somebody has to maintain and stand behind. Where invoices land with recipients who review, approve or file them, the embedded image saves a rendering step at the far end.
| XRechnung | ZUGFeRD | |
|---|---|---|
| Structure | Purely structured XML, no PDF layer | Hybrid: PDF/A-3 with embedded XML |
| Maintained by | KoSIT (Koordinierungsstelle für IT-Standards) | FeRD (Forum elektronische Rechnung Deutschland) |
| Current version | Standard XRechnung 3.0.2 | 2.5.2 (permitted from 2.0.1) |
| Human readability | Only through a viewer or a rendering at the recipient | Immediate — the PDF is part of the file |
| Typical use | B2G, highly automated B2B routes, high document volumes | Mixed recipient landscape, smaller trading partners, visual review |
| EN 16931 conformity | Given | Only in permitted profiles |
French Factur-X — technically the twin of ZUGFeRD — also meets the requirements where it is EN 16931 conformant. For a group with entities on both sides of the Rhine that matters: the same hybrid construction can serve German and French routes, which is not true of the purely structured option.
Which ZUGFeRD profiles qualify, and which do not?
This is by a distance the most common implementation error. ZUGFeRD is not a single format but a family of profiles. Two of them are not EN 16931 conformant because they are not complete invoices. A business issuing in either is sending a sonstige Rechnung in VAT terms, even though the file passes every ZUGFeRD validation tool it is put through.
| Profile | EN 16931 | Qualifies as E-Rechnung | Reason |
|---|---|---|---|
| MINIMUM | no | no | Not a complete invoice within the meaning of the standard |
| BASIC-WL | no | no | Not a complete invoice within the meaning of the standard |
| BASIC | yes | yes | Reduced but complete data set |
| EN 16931 (COMFORT) | yes | yes | Reference profile of the standard |
| EXTENDED | yes | yes | The standard plus further fields |
| XRECHNUNG | yes | yes | Congruent with the XRechnung requirements |
Why the names mislead
The naming is the trap. MINIMUM sounds like a lean but valid invoice. BASIC-WL sounds like a variant of BASIC — and BASIC qualifies. Both readings are wrong. When configuring an outbound format, do not infer the profile from its name: validate the generated file against EN 16931 once, before the first production invoice run. On the inbound side the same applies in reverse, and the incoming-invoice check needs a profile test, not merely a format test.
Why does the XML part govern in a hybrid file?
In a hybrid format the structured XML part governs. Where the PDF image diverges from it in substance, the divergence can amount to a second invoice, with a tax liability under § 14c UStG. That is not a theoretical construction; it is the reason a particular system architecture eventually becomes visible to a tax auditor.
In an established landscape the PDF often comes from an output-management or reporting tool and the XML from an interface. Both read the same master data, but by different routes, with their own rounding rules, text blocks and release cycles. Those paths diverge — not immediately, but reliably. And the legally decisive half is the one nobody looks at: the image is reviewed, the XML is posted.
The requirement is therefore blunt. XML and PDF must be generated from one data source, in one step, with one calculation. Where that cannot be enforced, an automatic reconciliation of the two components belongs in the outbound process, and its output belongs in the audit trail rather than in a log that rotates.
What breaks in a cross-border ERP setup?
The German rules are not difficult. What breaks is the interaction between them and the way a multinational configures one invoicing platform for many countries. Eight failures recur.
- One global template, many national specifications. A single generic EU e-invoice output, configured against whichever country went live first, will fail German business rules. XRechnung is the German specification of the EN 16931 model, not a synonym for it.
- A profile inherited from a vendor default. Where the connector or middleware chooses the ZUGFeRD profile, nobody in the finance function has made a decision. MINIMUM is a plausible default and is not an E-Rechnung.
- Two generation paths. PDF from the form designer, XML from the interface. This is the § 14c exposure described above, and it is the hardest to see because both halves are individually correct.
- The standard version hard-coded. The applicable XRechnung version has changed before and will change again. It belongs in configuration as a parameter, not compiled into a template.
- Buyer reference treated as mandatory everywhere. A validation rule written for the German public sector, where the Leitweg-ID is required, then rejects perfectly valid B2B invoices that have no reason to carry one.
- Normalisation on ingest. A group document platform that re-renders, re-compresses or re-indexes on import defeats the requirement to hold the structured part intact in its original form.
- A ten-year retention parameter. Inherited from a group policy and simply wrong for Germany, where the period is eight years.
- Validation treated as pass or fail. The BMF distinguishes format errors, business-rule breaches and content errors, and only the third puts the input VAT deduction at risk. A binary gate either blocks payment runs for no tax reason or waves through the class that costs money.
Only two of these eight are tax questions. The rest are configuration decisions taken by people who will never read the Umsatzsteuergesetz, which is the reason the German entity's controller has to see the format configuration before go-live rather than after the first rejected invoice.
How must a correction be issued?
A Rechnungsberichtigung (invoice correction) must itself be an E-Rechnung, and it must refer unambiguously to the original document. That is a format constraint with a systems consequence: a credit note produced through a separate output route, or a corrected PDF sent by e-mail, does not correct an E-Rechnung. A pure reduction in consideration under § 17 UStG requires no correction at all — worth establishing before a group builds a re-issue loop for every price adjustment.
The three classes of error the BMF-Schreiben of 15 October 2025 distinguishes belong in the same conversation, because they decide what actually has to be corrected. A format error breaches the EN 16931 syntax. A business-rule breach violates a plausibility rule of the standard. A content error is a missing or incorrect mandatory particular under § 14 Abs. 4 UStG. Only the third puts the input VAT deduction at risk, and only the third is a reason to reissue. A validation tool that reports all three with equal weight will generate corrections that nothing in the statute requires, and a group that reissues on every finding will spend the first quarter of the mandate explaining credit notes to its own auditors.
Is a Leitweg-ID required for B2B invoices?
No. The confusion is persistent, including in professional commentary. The Leitweg-ID is a routing identifier for invoices to German public-sector clients (B2G) under the E-Rechnungsverordnung (ERechV). The federal administration describes it as the unique string that enables technical addressing of an e-invoice to a recipient's processing systems, notified to suppliers when the contract is awarded; an invoice to a federal authority without one cannot be delivered correctly. In EN 16931 it travels in the field Buyer reference (BT-10).
In domestic B2B it is not a condition of a valid E-Rechnung. Declaring it a mandatory particular builds a validation rule that rejects correct incoming invoices. A B2B customer may of course require its own reference in BT-10 — a purchase order number, a cost centre — but that is a contractual agreement, not a statutory particular, and it should be enforced as such.
Should a group wait for XRechnung 4.0?
No. The KoSIT has announced XRechnung 4.0 as the German implementation of the new EN 16931-1:2026, targeted for the middle to the end of 2026, with a preliminary version of the specification to be made available for early review. As at 3 September 2026 neither a published final version nor a binding date from which the standard must be applied could be confirmed. The operative version remains Standard XRechnung 3.0.2.
For planning purposes 4.0 is a watch item, not a milestone. Check the position directly with the KoSIT before each release plan, and make sure the standard version in your systems is a configurable parameter rather than a hard-wired value — which is the same point as item four above, and the reason it is worth fixing now rather than during a version change.
How must the file be archived?
Eight years under § 14b UStG. Not ten. English-language coverage of the German rule gets this wrong routinely, and so do group retention policies applied to the German entity without checking. Under the BMF-Schreiben of 15 October 2025 at least the structured part must be held intact in its original form — for ZUGFeRD that means the PDF/A-3 file with its embedded XML, not a data set extracted from it. The GoBD apply in addition; storage outside a GoBD-certified system is not in itself a breach. Our register of corrections tracks the eight-year point.
In practice
Where invoices are generated, validated and released by systems or by AI-assisted workflows, the format question turns into a responsibility question, and the record of what was generated from which data has to outlive the release that produced it. BarzelVault applies policy and approval thresholds ahead of execution and issues signed audit receipts. BarzelOps runs the cross-system workflow with durable state, approval checkpoints and tenant isolation, so each German entity's operations remain attributable to that entity.
Frequently asked questions
XRechnung or ZUGFeRD — which is legally better?
Neither. Both meet the requirements. The choice is operational: XRechnung for purely machine processing, ZUGFeRD where a readable document has to travel with the data.
Is ZUGFeRD in the MINIMUM profile an E-Rechnung?
No. MINIMUM and BASIC-WL are not EN 16931 conformant because they are not complete invoices. Permitted are BASIC, EN 16931 (COMFORT), EXTENDED and XRECHNUNG.
What applies if the PDF image and the XML differ?
The XML part governs. An image that diverges in substance can amount to a second invoice and create a risk under § 14c UStG.
Is a Leitweg-ID required in B2B?
No. It is a B2G routing identifier under the ERechV, carried in Buyer reference (BT-10). In B2B it is not a statutory particular.
Is XRechnung 4.0 available yet?
Announced for the middle to the end of 2026 as the implementation of EN 16931-1:2026. No published final version and no binding application date could be confirmed as at 3 September 2026. Standard XRechnung 3.0.2 remains operative.
Is Factur-X permitted in Germany?
Yes, where it is EN 16931 conformant. For suppliers and customers in France it is the usual route, and the hybrid construction is shared with ZUGFeRD.
Where this leads
For a group, the German format question is small and the configuration question is not. The statute names two acceptable formats and one exclusion, and that part can be settled in an afternoon. What takes the time is establishing, entity by entity and template by template, that the file actually leaving the system is the file the statute describes — in a permitted profile, generated once from one source, archived byte for byte for eight years, and validated on a scale rather than a switch.
In practice
The control has to run before the invoice becomes irreversible.
An accepted structured invoice can be corrected but never deleted, and from the penalty date every defect has a price. Barzel puts the approval threshold, the duplicate check and the signed record in front of submission, so the process can be defended on the day an auditor or the tax authority asks.
95 days leftE-Rechnung issuing duty from 1 January 2027 for 2026 turnover above €800,000
BarzelVault
The AI action firewall: decide what an agent may do before it does it.
- Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
- Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
- Credential isolation, spend and action limits, and an emergency kill switch.
Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize
BarzelOps
Governed workflow automation across the systems that run the business.
- Durable, idempotent execution: a timeout is retried once, never filed twice.
- Human approval checkpoints that pause the workflow and resume it.
- Isolation per entity or client, signed evidence receipts and a portable manifest; HubSpot, Xero, Gmail, Google Drive and Slack.
Free tier: 100 calls a dayPaid plans from $19 a monthLive on MCPize
Enterprise: written quote by email within two business days. No sales call.
Related
- The obligation to receive, in force since 1 January 2025
- The 2027 issuing mandate and the €800,000 threshold
- Audit trail requirements for AI agents
- Workflow automation
- Glossary of regulatory and technical terms
Sources
- § 14, § 14b, § 14c, § 17 Umsatzsteuergesetz (UStG) — gesetze-im-internet.de.
- BMF-Schreiben vom 15.10.2024, III C 2 - S 7287-a/23/10001 :007. No live official URL; the Schreiben of 15 October 2025 supplements it and does not replace it.
- BMF-Schreiben vom 15.10.2025, III C 2 - S 7287-a/00019/007/243, Einführung der obligatorischen elektronischen Rechnung bei Umsätzen zwischen inländischen Unternehmern ab dem 1. Januar 2025.
- BMF, FAQ E-Rechnung, Stand 23.03.2026.
- KoSIT, Standard XRechnung — current version 3.0.2.
- KoSIT, XRechnung 4.0 — was kommt auf uns zu?, page dated 17 March 2026 — EN 16931-1:2026, timing mid to end 2026, no binding application date stated.
- FeRD, ZUGFeRD / Factur-X — current version 2.5.2.
- E-Rechnungsverordnung (ERechV) — Leitweg-ID in B2G.
- E-Rechnung in der Bundesverwaltung, Buyer reference / Leitweg-ID.
- Directive 2014/55/EU of 16 April 2014 on electronic invoicing in public procurement.
- EN 16931 — European standard for electronic invoicing, published by CEN. Not linked: the standard is sold, not published openly.
This article is a working guide for English-speaking readers and does not constitute tax or legal advice. The binding text is the German one.