Formats and the Leitweg-ID
Two decisions decide whether a German document is accepted: which format value you submit, and whether the buyer reference is present. Everything else about sending is generic and is documented under Invoice Endpoints.
Which format to submit
| Value | What it is | Use it for |
|---|---|---|
XRECHNUNG | XRechnung, the German CIUS of EN 16931, UBL syntax | B2G, and B2B where the counterparty asks for XRechnung |
XRECHNUNG_CII | XRechnung in CII syntax | The same, where the counterparty requires CII |
ZUGFERD | The hybrid German format: a PDF carrying the XML | B2B where the recipient wants a human-readable document alongside the data |
FACTUR_X_EN16931, FACTUR_X_EXTENDED, FACTUR_X_BASIC_WL | The Franco-German hybrid, named by profile | French counterparties; read the profile warning below before using one for a German invoice |
PEPPOL_BIS | Peppol BIS Billing 3.0 | Cross-border Peppol traffic |
PDF | An unstructured document | Delivery of something that is not a structured invoice |
The platform emits XRechnung at version 3.0, which has been in force since 1 February 2024. Patch releases within 3.0 are published by KoSIT on their own schedule, so a document you validate locally against a newer 3.0.x bundle can differ in detail from the verdict you get here; when that happens, send the document and the finding to support rather than assuming one side is wrong.
The ZUGFeRD profile question
ZUGFeRD and Factur-X are the same technical family expressed in profiles. Two of those profiles — MINIMUM and BASIC-WL — are not EN 16931-compliant, and the BMF circular excludes them explicitly. A document in either profile is not a compliant German e-invoice, whatever channel it travels on.
When no profile is specified on the API, the generated document uses the EN 16931 profile, so an omitted profile is safe. Naming FACTUR_X_BASIC_WL is not: do not use it for an invoice that has to satisfy the German mandate.
Name the profile explicitly rather than sending the bare FACTUR_X value: that one is retained only so that invoices stored before the profiles were split can still be read, and it says nothing about which profile you meant.
The buyer reference, and the Leitweg-ID
An XRechnung must carry a buyer reference. The rule is enforced at conversion, before anything is transmitted: if neither a buyer reference (BT-10) nor a purchase order reference is present, the document is refused with
A buyer reference or purchase order reference MUST be provided.
Build your payload so that at least one of the two is always populated. In practice the buyer reference is the field that carries meaning for the recipient's accounts-payable system, and for public buyers it is not optional at all.
For B2G, the buyer reference is the Leitweg-ID. It is issued by the public authority you are invoicing and communicated when the order is placed — it is never derived, guessed, or taken from the supplier's own data. § 5 ERechV makes it mandatory invoice content, and a federal buyer will reject an invoice without it even when Peppol routing succeeded, because the routing identifier and the invoice content are checked separately.
Three failure modes are worth handling in your own product before submission:
No Leitweg-ID supplied by your user. Block the submission in your UI and ask for it. It cannot be recovered from anywhere else.
A Leitweg-ID pasted with surrounding whitespace or formatting. Normalise before you send. A malformed value fails at the buyer, which is the slowest possible place to discover it.
A Leitweg-ID used as the client's own participant identifier. That is the onboarding mistake described under Onboarding a German company; the Leitweg-ID identifies the buyer, not your client.
Plain PDF
A PDF with no structured XML inside it is accepted by the platform as a document and delivered, but it is a sonstige Rechnung in the sense of § 14 UStG — not an e-invoice. Do not present it to your users as a compliant option for a transaction that falls under the mandate, and do not assume a German recipient will accept it once their issuing duty has started.
After submission
Tracking, processing status, retrieval and search are generic:
| Need | Page |
|---|---|
| Submit a document | Send invoice |
| Follow what happened to it | Document status |
| Find documents again | Search documents |
| Answer an incoming document | Send MLR response |
| Review the responses you sent | Search MLR history |
Germany adds no status vocabulary of its own and has no status chain to report back to an authority, which is the other half of the difference from France described in the overview.