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.
Which entities in a group are actually caught?
This is the first question a group tax function has to answer, and it is not answered by listing which entities hold a German VAT number.
The BMF FAQ sets the test in one sentence: a business is treated as domestic where it has its seat, its place of management (Geschäftsleitung), or a Betriebsstätte participating in the supply within the territory of the Federal Republic. The same FAQ then addresses the case that matters most to a multinational directly: foreign entrepreneurs who are registered for VAT in Germany but have no fixed establishment there may note that fact on the invoice in order to explain why they are not issuing an E-Rechnung.
Two consequences follow, and they point in opposite directions.
- A German VAT registration is not, by itself, establishment. Article 11(3) of Council Implementing Regulation (EU) No 282/2011 puts it in terms that apply across the single market: the fact of having a VAT identification number is not in itself sufficient to consider that a taxable person has a fixed establishment. A foreign parent that registered in Germany for a distance-selling or reverse-charge reason has not thereby acquired an issuing obligation.
- Establishment brings the whole duty with it. A GmbH incorporated in Germany, a German branch with a participating Betriebsstätte, or a foreign company whose place of management is in Germany is a domestic business, and the receiving duty applied to it from 1 January 2025 without qualification.
The outer boundary of what Germany may require is set at EU level and is worth reading, because it uses the same word. Council Implementing Decision (EU) 2023/1551 of 25 July 2023 authorises Germany to accept only invoices issued in electronic form by taxable persons established in the territory of Germany, and to provide that the use of such invoices is not subject to acceptance by a recipient established in Germany. It applies from 1 January 2025 until the earlier of 31 December 2027 or the date on which Member States must apply national provisions transposing the amendments to Articles 218 and 232 of Directive 2006/112/EC made in the VAT in the Digital Age package. That successor instrument is Council Directive (EU) 2025/516 of 11 March 2025, in force since 14 April 2025, whose new second paragraph to Article 218 lets a Member State require electronic invoices from taxable persons established within its territory without a Council authorisation, and whose amendment to Article 232 removes the need for recipient acceptance where that option is used.
Establishment is therefore the hinge of the whole regime, at both the German and the European level. It is a documented judgement about where seat, management and participating Betriebsstätten actually sit — not a field in the VAT master data.
What is an E-Rechnung, and what is a sonstige Rechnung?
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, 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.
That term of art is where most English-language summaries go wrong. A PDF sent by e-mail is a sonstige Rechnung, not an electronic invoice in the German sense, however electronic its transmission. The BMF names as conforming formats:
- XRechnung — purely structured, maintained by the KoSIT, currently Standard XRechnung 3.0.2
- ZUGFeRD from version 2.0.1 (FeRD, currently 2.5.2) — hybrid, except the MINIMUM and BASIC-WL profiles, which are not complete invoices. Permitted are BASIC, EN 16931 (COMFORT), EXTENDED and XRECHNUNG.
- Factur-X, where it is EN 16931 conformant
For an inbound process that means two shapes have to be handled: a bare XML file with no readable rendering, and a PDF/A-3 with XML embedded inside it. The differences between them are set out in XRechnung and ZUGFeRD.
Does an e-mail inbox really discharge the obligation?
In the BMF's view, providing an e-mail inbox is already sufficient for receiving an electronic invoice. That is legally accurate and operationally misleading. It answers the question of compliance, not the question of whether the file can be used. Three capabilities have to be kept apart:
| Level | What it means | Status |
|---|---|---|
| Able to receive | The file reaches the company and is not lost. | the statutory minimum, compulsory since 1 January 2025 |
| Able to process | The structured part is read, matched to master data and posted. | no statutory duty, unavoidable in practice |
| Able to check | Validation against EN 16931 and reconciliation of the mandatory particulars under § 14 Abs. 4 UStG. | decides the input VAT deduction |
The common finding in companies that set receipt up as a formality in early 2025 is that level one exists, level two does not, and level three is nobody's job. The gap surfaces the first time a German supplier switches and sends an XRechnung in place of the familiar PDF.
Which errors put the input VAT deduction at risk?
The BMF-Schreiben of 15 October 2025 distinguishes three classes of error. This taxonomy is the most useful thing in either Schreiben and is reflected in almost no inbound check.
| Class | Description | Effect |
|---|---|---|
| Format error | Breach of the EN 16931 syntax | no immediate risk to the input VAT deduction |
| Business rule breach | A plausibility rule of the standard is violated | no immediate risk to the input VAT deduction |
| Content error | Mandatory particulars under § 14 Abs. 4 UStG missing or wrong | puts the input VAT deduction at risk |
Both failure modes cost money, in different currencies. A check that treats every validation finding as grounds for rejection blocks payment runs, forfeits early-payment discounts and generates supplier queries for no tax reason. A check that validates syntax alone waves through exactly the class that matters. Build the inbound gate along the three levels: log format errors, assess business-rule breaches, escalate content errors.
A Rechnungsberichtigung (invoice correction) must itself be an E-Rechnung and must refer unambiguously to the original document. A pure reduction in consideration under § 17 UStG needs no correction at all — a frequent cause of unnecessary correction loops in groups that treat every credit as a re-issue.
Why is the XML the binding half of a hybrid file?
In ZUGFeRD and Factur-X the structured XML part governs. Where the PDF image diverges from it in substance, that divergence can amount to a second invoice, with a tax liability under § 14c UStG.
For inbound processing the consequence is uncomfortable: the posting has to be taken from the XML, not from the PDF a human reads. Many systems still extract from the image out of convenience — by OCR, or through an existing document-capture route — because that works without rebuilding anything. When the two halves diverge, the legally decisive content is the one nobody looked at.
How long must incoming E-Rechnungen be kept?
Eight years under § 14b UStG. Not ten. The period was shortened from ten to eight, and English-language coverage gets this wrong routinely; so do group retention policies written once and inherited by the German entity. Over-retention is not a safe default — it is a data-protection exposure and a storage cost with no legal benefit. Our register of corrections tracks this one.
Under the BMF-Schreiben of 15 October 2025 at least the structured part must be kept so that it is present intact in its original form. The GoBD apply in addition; storage outside a GoBD-certified system is not in itself a breach.
This is where automated inbound handling most often breaks the rule. Any pipeline that normalises incoming files, converts them to an internal format, or writes only the extracted fields to a database defeats the requirement — even where nothing is lost in substance. The original has to be secured byte for byte before processing starts, which for a group means the German archive cannot simply be a view over the group document-management standard.
Do I need a Leitweg-ID to receive B2B invoices?
No. The Leitweg-ID (routing identifier) is an addressing feature of German public-sector clients under the E-Rechnungsverordnung, carried in the EN 16931 field Buyer reference (BT-10). The federal administration's own guidance describes it as the string that enables technical addressing to a recipient's processing systems, notified to suppliers when the contract is awarded. It concerns B2G invoicing only. Requesting one for B2B receipt, or demanding one from suppliers, solves a problem that does not exist and delays everyone who believes you.
What does a foreign parent have to do differently?
A domestic German filer and a group finance function in London, New York or Zurich face the same statute and a different problem. Five differences are worth planning around.
- The duty attaches to the German entity, not to the group. There is no consolidated discharge and no group filing. If four entities in the structure are established in Germany, four receiving capabilities exist and four sets of evidence have to be attributable to a named taxpayer.
- Intra-group invoicing is asymmetric. A parent established outside Germany has no obligation to issue an E-Rechnung to its German subsidiary. The subsidiary is nonetheless obliged to receive one from any German supplier that sends it. Designing the intra-group flow first and the third-party flow second gets this backwards.
- Establishment has to be determined, not inherited. Seat, place of management and participating Betriebsstätten move when the operating model moves — a warehouse taken on, staff transferred into a local entity, a supply chain re-routed. Whoever owns permanent-establishment analysis in the group is closer to this than the e-invoicing project team.
- The archive requirement collides with group standards. A global content platform that re-renders, re-compresses or re-indexes on ingest will not hold the structured part intact in its original form. This is usually discovered late, because it looks like a solved problem.
- An audit is conducted in German. Field definitions, control descriptions and approval records that exist only in English remain usable, but they will be read by someone reconstructing your process from a schema they have never seen. Bilingual definitions cost little now.
Compared with its neighbours, Germany is deliberately undemanding at this stage. There is no central platform to connect to, no clearance step, and no government-assigned invoice number — unlike the Polish and French models, where an invoice becomes irreversible the moment the state accepts it. The German duty is a capability requirement, not a transmission protocol. What that buys in simplicity it takes back in ambiguity: nothing external tells you the obligation has been met.
How to test whether receipt actually works
- For every group entity with a German VAT registration, record whether it has a seat, a place of management, or a participating Betriebsstätte in Germany.
- Name the single mailbox or endpoint at which an E-Rechnung for that entity arrives, and confirm suppliers have been told what it is.
- Send one pure XRechnung and one ZUGFeRD file from outside the group, and follow each to the point of posting.
- Confirm the hybrid file was posted from the embedded XML, not from the PDF image.
- Retrieve the archived copy and compare it byte for byte with what was sent.
- Split the inbound check into format errors, business-rule breaches and content errors, and escalate only the third.
- Reset the retention parameter on the German entity to eight years.
In practice
Where inbound invoices are checked and released by systems or by AI-assisted workflows, the question moves from format to responsibility, and the record of who or what released a payment becomes the evidence. 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
Who has to be able to receive an E-Rechnung?
Every domestic business, since 1 January 2025, with no threshold and no transition — including Kleinunternehmer under § 19 UStG. A business is domestic where it has its seat, its place of management, or a Betriebsstätte participating in the supply in Germany. No consent from the recipient is required.
Is a foreign company with only a German VAT registration caught?
Registration alone is not establishment. The BMF FAQ says foreign entrepreneurs registered for VAT in Germany without a fixed establishment there may note that on the invoice to explain why they are not issuing an E-Rechnung. Article 11(3) of Regulation (EU) No 282/2011 states the general principle.
Does an e-mail inbox satisfy the obligation?
For the statutory duty, yes, in the BMF's view. For processing the structured data and checking the mandatory particulars under § 14 Abs. 4 UStG, no.
Is a PDF an E-Rechnung?
No. A PDF without structured, EN 16931 conformant data is a sonstige Rechnung and in electronic form requires the recipient's consent.
How long must incoming E-Rechnungen be kept?
Eight years under § 14b UStG, with at least the structured part held intact in its original form. Not ten years — that is a widespread and outdated figure.
May I reject an E-Rechnung for validation errors?
Only content errors put the input VAT deduction at risk. Format errors and business-rule breaches should be recorded but do not justify blanket rejection.
Where this leads
The receiving duty is the part of the German regime that is already in force, already unconditional, and already being missed — usually by groups whose German entity is small enough that nobody looked at it. It costs nothing to comply with in the narrow sense and a good deal to comply with usefully. The issuing side, which arrives on 1 January 2027 for larger issuers, is the part with a threshold and a date; the receiving side has neither, and has not had either since the beginning of 2025.
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.
In forceE-Rechnung receipt duty in force since 1 January 2025
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 2027 issuing mandate and the EUR 800,000 threshold
- XRechnung and ZUGFeRD: formats, profiles and cross-border pitfalls
- Audit trail requirements for AI agents
- Workflow automation
- Glossary of regulatory and technical terms
Sources
- § 14, § 14b, § 14c, § 19, § 27 Abs. 38 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 — definition of inländisches Unternehmen, e-mail inbox, eight-year retention, Kleinunternehmer.
- KoSIT, Standard XRechnung — current version 3.0.2.
- FeRD, ZUGFeRD / Factur-X — current version 2.5.2.
- E-Rechnungsverordnung (ERechV) — Leitweg-ID, Buyer reference BT-10.
- E-Rechnung in der Bundesverwaltung, Buyer reference / Leitweg-ID.
- Council Implementing Decision (EU) 2023/1551 of 25 July 2023 authorising Germany to derogate from Articles 218 and 232 of Directive 2006/112/EC.
- Council Implementing Regulation (EU) No 282/2011 of 15 March 2011, Article 11.
- Council Directive (EU) 2025/516 of 11 March 2025 (VAT in the Digital Age), in force since 14 April 2025.
- 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.