Germany E-Invoicing Overview
This section covers what changes for a German client company. It is deliberately short, because most of what you need is already generic: Germany has no separate API host, no Germany-only endpoint, and no country configuration call. You onboard a German company with the same partner endpoints as any other, and the German specifics are values you pass, not calls you add.
If you integrated France first, read the next paragraph before anything else. France has a central platform (the PPF) that the company must be registered with, a configuration record to create, and a lifecycle of statuses to report back. Germany has none of those. German B2B e-invoicing is decentralised and post-audit: there is no state clearance platform, no real-time reporting obligation, and therefore no German equivalent of the France config endpoint or the CDV/CDAR lifecycle. Expecting a French-shaped flow is the single most common integration error here.
What German law requires
| Duty | Who | From when |
|---|---|---|
| Be able to receive a structured e-invoice | Every domestic business, B2B | 1 January 2025, no transitional relief |
| Issue structured e-invoices | Issuers whose previous-year total turnover exceeded EUR 800,000 | 1 January 2027 |
| Issue structured e-invoices | All remaining domestic businesses | 1 January 2028 |
The obligation applies only when both parties are established in Germany (§ 14 Abs. 2 UStG). A company merely VAT-registered in Germany, with no seat, management or participating establishment there, is outside it.
Until the issuing duty bites, paper or a non-conforming electronic format may still be used with the recipient's consent — that is the transitional rule in § 27 Abs. 38 UStG, and it is the reason a German customer may still accept a PDF today and refuse it in 2027.
Statutory basis: the Wachstumschancengesetz of 27 March 2024, which rewrote § 14 UStG. The administrative reading is the BMF circular of 15 October 2024, extended by the circular of 15 October 2025. The BMF also maintains a FAQ on the mandate that is updated far more often than the circulars.
What counts as an e-invoice
German law splits invoices in two. An elektronische Rechnung is issued, transmitted and received in a structured electronic format that allows electronic processing. Anything else — including a PDF, an image, or paper — is a sonstige Rechnung (§ 14 Abs. 1 UStG).
A structured format qualifies when it complies with EN 16931 and the syntax list of Directive 2014/55/EU, or when issuer and recipient agree on a format from which the VAT-mandatory particulars can be extracted correctly and completely into an EN 16931-compliant form.
The formats the BMF names explicitly are XRechnung and the hybrid ZUGFeRD from version 2.0.1 onwards, excluding the MINIMUM and BASIC-WL profiles, which are not EN 16931-compliant. National formats are not compulsory: any EN 16931-compliant European format qualifies.
Two consequences are worth building into your own product:
A PDF is not an invoice. Sending one is a delivery method, not compliance. Where a document must be a structured invoice, the structured file is the invoice.
In a hybrid invoice the structured part governs. All VAT-mandatory particulars have to sit in the XML; a reference from the XML to an unstructured attachment does not satisfy the requirement.
B2G is separate law
Public-sector invoicing in Germany is not the same regime as B2B, and it came first.
At federal level the E-Rechnungsverordnung (ERechV) applies. § 4 requires the XRechnung standard, or another standard meeting the European norm, and transmission through a federal administration portal with prior registration. § 5 makes the Leitweg-Identifikationsnummer mandatory invoice content, alongside bank details, payment terms and an e-mail or De-Mail address. § 3 Abs. 3 exempts invoices from direct awards up to EUR 1,000 and a small number of other cases.
The Leitweg-ID is issued by the public buyer, not by you, not by your client and not by Peppol. The contracting authority communicates it when placing the order, and it travels in the invoice as the buyer reference (BT-10).
Peppol addressing for federal B2G puts the Leitweg-ID on the receiving side: the receiver participant is 0204:<Leitweg-ID>, the sender is 9930:<VAT number> or 0088:<GLN>. Even when the document is routed over Peppol, the Leitweg-ID must also appear inside the invoice.
The federal platforms have been consolidated: the ZRE became unavailable during Q4 2025, and the federal administration now receives through the OZG-RE.
Germany is a federal state, so Land-level and municipal B2G obligations are their own law and differ from the federal rules above. KoSIT — the German Peppol Authority, at the Senator for Finance in Bremen — maintains the synopsis of Land implementations. Do not generalise the federal rules to a municipal buyer.
Retention
A copy of every issued invoice and all received invoices must be kept for eight years, counted from the end of the calendar year in which the invoice was issued (§ 14b Abs. 1 UStG). The eight-year period replaced the former ten years and applies to invoices whose retention period had not expired on 31 December 2024.
For an e-invoice, at least the structured part has to be retained unaltered and remain machine-evaluable; the GoBD amendment of 14 July 2025 confirms that retaining the structured part alone is sufficient for a hybrid invoice.
Which party holds the archive of record is a contractual question between you and your client. Decide it explicitly rather than assuming the platform is the archive.
Where to go next
| Page | What it covers |
|---|---|
| Onboarding a German company | The partner API sequence, the identifier scheme to register, and what to poll |
| Formats and the Leitweg-ID | Which format value to submit, the ZUGFeRD profile question, and the buyer-reference rule |
The endpoint-level reference for the calls themselves lives in the generic sections of this guide: Authentication, Company Management, Peppol Registration, Invoice Endpoints and MLR.