Germany's e-invoicing mandate 2027/2028: a developer's guide

• Since 1 January 2025, every German company must be able to receive e-invoices — technically, an email inbox suffices.
• From 1 January 2027, companies with more than €800,000 prior-year turnover must issue e-invoices.
• From 1 January 2028, the issuing obligation covers every company for domestic B2B transactions.
• An e-invoice is structured XML per EN 16931 — in practice XRechnung or ZUGFeRD. An ordinary PDF is not an e-invoice.
• Germany requires no platform, no portal, no certification: transmission by email is permitted. The mandate is purely a format and validation problem — that is, a software problem.

The legal basis is the Wachstumschancengesetz, which rewrote § 14 of the German VAT act (UStG). The mandate covers transactions between companies established in Germany (B2B). Consumer invoices (B2C) are unaffected.

Transition rules bridge the gap: through 2025 and 2026 any company may keep sending paper or other formats with the recipient’s consent; in 2027 that remains open only to companies at or below €800,000 prior-year turnover. Note where the leverage sits: consent belongs to the recipient — the moment one large customer refuses it, your software is effectively on the hook earlier than the law alone demands.

An e-invoice is an invoice in a structured electronic format conforming to the European norm EN 16931 — data a machine can process field by field: invoice number, tax amounts and payment details as typed fields rather than prose.

Which settles the most common misconception: a PDF is not an e-invoice, however well designed. A PDF is a picture for humans. That is why the hybrid ZUGFeRD format embeds an XML data set inside the PDF file — and legally the XML is authoritative, not what the PDF shows.

“Conforming to EN 16931” concretely means passing the norm’s business rules (codes like BR-CO-16) and — in Germany — the national XRechnung rules on top (BR-DE-*). These rule sets are versioned and change roughly twice a year.

Both formats satisfy the mandate. Choosing between them is a product decision, not a legal one:

Rule of thumb: invoicing public bodies or large corporates means XRechnung; invoicing small business customers is gentler with ZUGFeRD. Many systems simply offer both — the data set underneath is the same.

Here Germany is remarkably pragmatic: there is no state platform, no registration, no certification. An e-invoice attached to an email fulfils the mandate. That separates Germany from Italy (SdI), Poland (KSeF) and France (Plateformes Agréées), where invoices flow through state-controlled infrastructure.

In practice recipients can still dictate channels: public bodies use portals or Peppol, large corporates sometimes their own intake. For your software that means: producing the correct format is the obligation; the delivery channel is a matter of agreement.

1. 1Map your fields. The norm addresses fields as Business Terms (BT) and groups (BG): BT-1 invoice number, BT-2 issue date, BT-10 buyer reference, BG-16 payment instructions. Map your data model onto these terms before touching XML — XRechnung’s mandatory fields exceed many internal invoice models (the seller contact block BG-6 among them).
2. 2Compute money as decimals. The norm’s calculation rules check to the cent. Floating point produces rounding drift that only validation reveals — the classic failure is BR-CO-16.
3. 3Generate the XML. UBL and CII are order-sensitive XSD schemas with fixed namespaces. Library or API — never emit XML from string templates without validating afterwards.
4. 4Validate against the official rule set — in CI. The bar is passing the KoSIT rules, not “the schema is valid”. Put real sample invoices into your test suite as golden files and run every change against them.
5. 5Track rule set releases. XRechnung updates roughly twice a year. Pin the rule set version and upgrade deliberately — an invoice that is valid today can produce warnings against a newer rule set.

Real invoices rarely fail on exotic rules — it is the same handful every time:

• BR-DE-15 — the buyer reference (BT-10) is missing. For public-sector invoices this is where the Leitweg-ID belongs.
• BR-DE-2 through BR-DE-7 — the whole seller contact block is missing because it only ever existed in the PDF letterhead.
• BR-CO-16 and the other calculation rules — rounding drift from floating-point arithmetic.
• BR-DE-18 — a cash-discount entry that starts the #SKONTO#TAGE=n#PROZENT=n.nn# notation but does not follow it exactly.
• BR-CO-25 — neither a due date nor payment terms transmitted.

The full reference with an explanation and fix per rule: all XRechnung error codes. Or try it directly: check an invoice in the validator — free, nothing stored.

Building it yourself is feasible: solid open-source libraries exist and the specifications are public. The honest cost is not the first release but the upkeep — rule set updates roughly twice a year, two syntaxes, PDF/A-3 conformance for the hybrid format, and the test coverage that keeps correctness durable.

That ongoing part is exactly what NormAPI takes over: invoice data as JSON in, valid XRechnung or ZUGFeRD out, validated against the current rule set — pin a version or track automatically. The validator is the same API customers use.

1. 1Establish your product’s cut-off: which customers exceed €800,000 — 2027 or 2028?
2. 2Pick target formats: XRechnung (UBL/CII), ZUGFeRD, or both.
3. 3Document a field mapping onto BT/BG terms; close the mandatory-field gaps in your data model.
4. 4Move monetary amounts to decimal arithmetic; centralise rounding.
5. 5Add validation against the official rule set to CI — or validate via the API.
6. 6Adopt golden files of real invoices in the test suite.
7. 7Define a process for rule set updates (pin, test, roll forward).
8. 8Plan the receiving side for your own customers’ inbound invoices.