Receiving e-invoices in Germany: what to do since 1 January 2025

Since 1 January 2025 every business established in Germany must be able to receive e-invoices for domestic B2B supplies — including Kleinunternehmer, landlords and businesses that only make exempt supplies. The obligation is modest: an ordinary e-mail inbox is sufficient, no portal or network is required, and no consent is needed for the sender. What changes is what you do with the file: the XML (or the XML inside a ZUGFeRD PDF) is the invoice, it should be validated, and it must be archived unchanged for eight years.

What exactly does the receiving obligation require?

The obligation follows from § 14 Abs. 1 and 2 UStG as amended by the Wachstumschancengesetz: since 2025 an issuer may send an e-invoice under § 14 Abs. 1 Satz 6 UStG without the recipient's consent, and the recipient must accept it. The BMF's FAQ puts the technical side plainly: for receipt, an e-mail inbox is already sufficient. The BMF letter adds in UStAE 14.1 that no separate mailbox reserved for e-invoices is required, that the parties may agree other channels (download from a portal, an interface, a shared drive), and that the obligation applies even if the recipient is a Kleinunternehmer, a flat-rate farmer or only makes exempt supplies. There is no registration, no platform and no reporting on the receiving side; see the Germany hub for the full timeline.

Until the issuing obligation bites (1 January 2027 for issuers above €800,000 turnover in 2026, 1 January 2028 for all), most incoming invoices will still be paper or PDF, and you may continue to accept those — consent to an electronic "other" format can be given implicitly by processing it. The receiving obligation means you cannot refuse a valid e-invoice, not that everything you receive will be one.

What arrives, and how do I recognise it?

Three kinds of files reach a German inbox today:

A ZUGFeRD PDF looks like any PDF. Readers such as Acrobat show the attachment in the attachments panel; accounting software detects it from the PDF/A-3 attachment and the XMP metadata. Do not rely on the sender labelling it — check for the attachment.

Do I have to validate incoming e-invoices?

Not by law, but the BMF letter of 15 October 2025 makes validation the practical standard. It distinguishes three kinds of defect (Rn. 6a, 6b, 35a):

1. Format errors — the file does not conform to the permitted syntax or its technical rules, or cannot be extracted. Such a file is not an e-invoice at all but an "other invoice". Where the issuer was obliged to send an e-invoice, it has not fulfilled that duty.
2. Business-rule errors — the file is syntactically fine but violates EN 16931 or XRechnung rules (a missing buyer reference, a tax total that does not add up). The file remains an e-invoice. Rule violations that do not concern the VAT mandatory content are irrelevant for VAT purposes.
3. Content errors — the mandatory content of §§ 14 Abs. 4, 14a UStG is wrong or missing (wrong tax rate, missing VAT ID, wrong recipient). This makes the invoice incorrect whether or not a validator notices; a validator cannot judge whether 19 % was the right rate.

The letter states that a business observing the care of a prudent merchant may rely on the technical result of a suitable validator regarding format and business rules, that validation supports but does not replace the recipient's duty to check completeness and correctness, and that keeping the validation report is advisable as evidence. In practice: run every incoming XML through a validator (the KoSIT validator with the XRechnung configuration for XRechnung files, EN 16931 Schematron for ZUGFeRD), store the report next to the invoice, and still read the invoice.

For a one-off check without installing anything, the free e-invoice checker validates an uploaded XRechnung, ZUGFeRD or UBL file against the German rules and does not store it.

How do I archive an e-invoice correctly?

Keep the structured file unchanged in the form you received it, for eight years (§ 14b Abs. 1 UStG; the period was shortened from ten years for invoices whose retention period had not expired on 31 December 2024). The BMF letter (Rn. 60) says at least the structured part must be kept so that it is intact in its original form, and adds that storing e-invoices outside a GoBD-conformant system is not in itself a breach of § 14b UStG for VAT purposes. The GoBD, as amended on 14 July 2025, then set the bookkeeping rules:

• Incoming electronic documents are kept in the format in which they were received (Rn. 131) — the XML stays XML.
• For e-invoices it is sufficient to keep the structured part; the human-readable part of a hybrid invoice must be kept in addition only if it contains extra or deviating tax-relevant information, such as booking notes or a qualified signature (Rn. 119, 131).
• A format conversion that deletes the structured part — printing a ZUGFeRD PDF, converting it to TIFF — is not permitted (Rn. 121, example 10).
• For structured data sets, the requirement is agreement in content, not in appearance (Rn. 118): you do not need to preserve how the XML "looked".
• Machine evaluability must be preserved: the tax authority may access the XML during an audit.

Storing the e-mail that carried the invoice is not required for VAT if the invoice file itself is archived, but the e-mail may be a business letter with its own retention duty; whether that applies in a given case requires professional confirmation.

What does receiving mean for input VAT?

Input VAT (Vorsteuer) is deducted from a proper invoice. Two consequences follow from the BMF letter for the receiving side:

• Where the supplier was obliged to issue an e-invoice and sent an "other invoice" instead, the letter (UStAE 15.2a Abs. 1) says that invoice is not a proper invoice and does not in principle entitle the recipient to deduct input VAT, subject to two escape routes: the supplier can correct by issuing an e-invoice afterwards, and under UStAE 15.2a Abs. 1a the deduction remains possible where the recipient can prove by objective evidence that the substantive conditions are met — which, the letter says, a content-correct and complete "other invoice" will regularly do. From 2027 this becomes a real question for every PDF you receive from a larger supplier.
• For hybrid invoices, input VAT is deducted only from the structured part (UStAE 14c.1 Abs. 4a). If the PDF says one amount and the XML another, book from the XML and ask the supplier to correct the file.

A receiving procedure that works

1. One inbox. Nominate the address suppliers should use and tell them. A shared mailbox is fine; a separate one is not required.
2. Detect. For every attachment, check whether it is XML or a PDF with an embedded XML.
3. Validate. Run the XML through a validator; store the report.
4. Read. Render the XML (XSLT visualisation or your software) and check content: is this your order, your entity, the agreed price, the right tax treatment?
5. Book. Take amounts, tax breakdown, payment terms and bank details from the XML, not from the PDF.
6. Archive. Store the original file unchanged, with the validation report, for eight years.
7. Escalate. If the file is not an e-invoice or has content errors, ask the supplier for a corrected e-invoice rather than fixing data yourself.

How KRONENWERK handles this

SUPPORTED KRONENWERK reads incoming XRechnung, ZUGFeRD, Factur-X and UBL files into bills. The file is checked in three separate steps — is it a structured e-invoice at all, could it be read, does it violate a rule — using the same EN 16931 and KoSIT rules that KRONENWERK applies to outgoing invoices, cross-checked with the Mustang library, and the original XML is retained unchanged. The bill then carries supplier, lines, tax breakdown, due date and payment details taken from the structured data, and flows into expenses and the ledger. The free e-invoice checker uses the same validators without storing the file. What KRONENWERK does not do is decide the tax outcome for you: a file that is not an e-invoice, or fails a rule, is flagged with the reason so that you and your adviser can act. See also receiving over Peppol for the Belgian and cross-border case and the Germany country page.