XRechnung and ZUGFeRD in Magento 2: Germany's B2B e-invoicing obligation

The e-mail from the customer's accounts department is polite and short: "Please resend invoice 2026-10432 as an E-Rechnung. We can no longer process PDF invoices." Your Magento store sent exactly what it always sends, a nicely laid out PDF attached to the invoice e-mail. Until recently that was fine. From the customer's side it is now a document their bookkeeping software cannot read, and from 2027 or 2028, depending on your turnover, it is not even a valid way for you to invoice another German business.

This post is for Magento 2 and Adobe Commerce stores that invoice German businesses or public bodies. It sets out what the German rules require and when, the difference between XRechnung and ZUGFeRD, where the Leitweg-ID fits in, and how to produce compliant files from Magento's own invoices. It is written by the team that makes the E-Invoicing: Germany module mentioned further down, so weigh the product part accordingly. It is not tax advice; your Steuerberater has the final word on your situation.

What changed on 1 January 2025

Germany split invoices into two kinds. An E-Rechnung is an invoice issued, sent and received in a structured electronic format that allows electronic processing. Everything else, paper and a plain PDF included, is now a "sonstige Rechnung", an other invoice, in the words of the Federal Ministry of Finance (BMF)¹.

Two obligations follow, and they start at different times.

Receiving. Since 1 January 2025 every business established in Germany must be able to receive an E-Rechnung. There are no exceptions; even small businesses under the Kleinunternehmer scheme must be able to receive them. The BMF adds, helpfully, that an e-mail inbox is enough for this¹.

Issuing. The duty to send E-Rechnungen to other domestic businesses is phased in through transition rules. From 1 January 2025 to 31 December 2026, every issuer may still send other invoices; paper always works, and a PDF works if the recipient agrees. If your prior-year turnover was not more than EUR 800,000, that period runs until the end of 2027. EDI procedures that do not meet the E-Rechnung definition may also be used until the end of 2027. Only after these periods is the E-Rechnung really mandatory between domestic businesses¹.

So, in practice: a store with more than EUR 800,000 turnover in 2026 must issue E-Rechnungen to German business customers from 1 January 2027. Everyone else must do so from 1 January 2028. How the turnover figure is calculated (which revenue counts, which year) is a question for your tax adviser; we have only quoted the BMF's wording, "Vorjahresumsatz"¹.

Who is covered, and who is not

The rules apply to invoices between businesses established in Germany: a seat, management or a permanent establishment involved in the sale¹. A seller registered for VAT in Germany without an establishment there can say so on the invoice to explain why it is not sending an E-Rechnung¹. That matters for Magento merchants in Austria or the Netherlands who ship to Germany: customers may still ask for an E-Rechnung, but the obligation itself is aimed at domestic businesses.

Some invoices stay outside the obligation even between German businesses. The BMF lists them¹:

• invoices to consumers (B2C), where an invoice is usually optional from a VAT point of view;
• small-amount invoices up to EUR 250 gross;
• tickets that count as invoices;
• supplies by Kleinunternehmer;
• supplies to legal persons that are not businesses, such as many clubs.

For a B2C shop with the occasional business customer, note the EUR 250 limit: a EUR 89 order from a company needs an invoice, but not an E-Rechnung.

Invoices to public bodies follow separate rules. Suppliers to the federal administration have had to invoice electronically since 27 November 2020 under the federal E-Rechnungsverordnung (ERechV), with a threshold of EUR 1,000 and the federal OZG-RE portal as the channel; the BMF points out that the two regimes sit side by side¹. The federal states have their own rules.

What you must do by when

What counts as an E-Rechnung

The definition hangs on the European standard EN 16931, the semantic model for electronic invoices that was written for public procurement under Directive 2014/55/EU³ and now serves B2B as well. The BMF names the two formats German businesses mostly use: XRechnung, and ZUGFeRD from version 2.0.1, except the profiles MINIMUM and BASIC-WL¹. Other formats, EDIFACT for example, can be agreed if the VAT details can be extracted correctly and completely.

XRechnung is the German specification of EN 16931, maintained by the Coordination Office for IT Standards (KoSIT). It is pure XML, in either UBL or CII syntax, and adds national business rules such as a mandatory buyer reference⁴². There is no human-readable part; the recipient needs a viewer. The tax authority offers one at e-rechnung.elster.de¹.

ZUGFeRD (identical to the French Factur-X) is a hybrid: a PDF/A-3 file with the structured XML embedded. Your customer can open it like any other PDF, and their software reads the XML. One detail changed with the new rules: if the PDF and the XML disagree, the XML now wins¹. A ZUGFeRD file whose picture says EUR 119 and whose XML says EUR 109 is an invoice for EUR 109.

ZUGFeRD comes in profiles. EN 16931 matches the standard, XRECHNUNG embeds an XRechnung-compliant XML, and MINIMUM and BASIC WL carry too little data to count.

Which should you send? For business customers, ZUGFeRD with the EN 16931 profile is usually the friendliest choice: the customer who has no e-invoicing software still sees a normal invoice, and the one who has it gets data. For public bodies, the federal portal expects XRechnung or ZUGFeRD in the XRECHNUNG profile delivered as pure XML without the PDF part⁴. When a large customer names a format, send that.

The Leitweg-ID and the buyer reference

A Leitweg-ID is the routing address of a public-sector invoice recipient. It is made of a coarse address, an optional fine address and two check digits, and it goes into the invoice field BT-10, Buyer reference⁴. The contracting authority gives it to you with the order; federal authorities get theirs from the Central Federal Finance Office⁴.

Businesses do not need one. The BMF says so directly, and adds that where a format makes BT-10 mandatory, a placeholder such as "-" is enough for VAT purposes in B2B¹. XRechnung does make BT-10 mandatory, and the KoSIT validator will complain if it is empty. In practice it is better to put something useful there, such as the customer's purchase order number.

If you deliver over Peppol, the public body's Peppol receiver ID is the prefix 0204 followed by the Leitweg-ID, at least for bodies connected to the federal OZG-RE portal⁴. German businesses can use their VAT ID with prefix 9930 as a Peppol ID⁴. Peppol is one channel among several, not an obligation: for B2B the law prescribes no transmission route, and e-mail, an interface or a portal download all work¹. Our post on Peppol e-invoicing for Magento explains the network itself.

Why validation matters more than it used to

A file that does not meet the format rules is not an E-Rechnung at all. The BMF's letter of 15 October 2025 says that a file with format errors, meaning it does not match the permitted syntax, counts as an other invoice in a different electronic format⁵. During the transition that only means the recipient has to accept a non-E-Rechnung. Once the transition ends, it means you have not issued a valid invoice.

The same letter separates format errors from business rule errors. A business rule error, for example a tax amount that does not match the rate, or an empty BT-10 in an XRechnung, is found by validation too, but its VAT consequence depends on whether a mandatory invoice detail is affected; a missing BT-10 on its own is irrelevant for VAT⁵. A business may rely on the result of a suitable validation tool, and keeping the report is suggested as evidence⁵.

KoSIT publishes an open-source validator and the XRechnung configuration for it on GitHub². That is the reference most German recipients and portals use, and it is what we used to check our own module's files.

How Magento handles this out of the box

It does not. Magento Open Source and Adobe Commerce create invoices and credit memos, e-mail a PDF and stop there: no structured format, no Leitweg-ID field, no validation against EN 16931. You can build the XML by hand in a separate tool or the customer's portal. For a handful of public-sector orders a year that is reasonable. For dozens of German business invoices a week from 2027, it is a job nobody wants.

Step by step: German e-invoices from Magento

This is the route with our E-Invoicing: Germany (XRechnung, ZUGFeRD) module for Magento 2.4.7 to 2.4.9. The details come from its product page and user guide⁶⁷.

1. Install commercegears/module-e-invoicing-de with Composer. It brings the free E-Invoicing Core module (queue, admin grid, checkout fields). Magento's cron must run: documents are created by cron every five minutes, not during checkout.
2. Switch it on under Stores > Configuration > CommerceGears > E-Invoicing > General.
3. Fill in Seller (Your Company). XRechnung needs a contact name, phone and e-mail (rule BR-DE-2), your VAT ID or tax number (BR-DE-16) and your IBAN for invoices paid later by transfer (BR-DE-23). Empty fields fall back to Magento's store information, which is often not enough.
4. Check Countries, Formats and Delivery. The suggested rules send German businesses a ZUGFeRD PDF (EN 16931) by e-mail and public bodies an XRechnung UBL over Peppol, or as a download without the Peppol package.
5. Look at the checkout. At the payment step, buyers tick "This is a business purchase (electronic invoice)" and enter their VAT ID and, for German addresses, "Leitweg-ID or your order reference". German VAT IDs are checked for their check digit while the buyer types. A reference counts as a Leitweg-ID only if its check digits match, so an order number like 2026-15 does not turn a carpenter into a public authority.
6. Invoice an order as usual. The e-invoice appears under CommerceGears > E-Invoicing > E-Invoices, checked against the EN 16931 rules, the checkable XRechnung rules, the XML schema and Magento's total, with problems listed by rule ID. The ZUGFeRD PDF goes out with Magento's normal invoice e-mail.
7. Run your own files through the KoSIT validator before going live. The module can call one you run as a daemon on your server (it needs Java), for every new document if you like.

Some details worth knowing. The ZUGFeRD PDF is drawn from the same data as the embedded XML, so picture and data cannot drift apart. BT-10 is always filled: the Leitweg-ID, otherwise the buyer's purchase order number, otherwise the Magento order number. A sent document cannot be changed; you correct it with a credit memo, which becomes an e-credit note referring to the original. Customers download PDF and XML in My Account on Luma and Hyvä; the checkout fields are part of the Luma checkout, which Hyvä stores use through Hyva_LumaCheckout.

What we checked ourselves: e-invoices of the demo store's orders went through the official KoSIT validator (version 1.6.3, XRechnung 3.0.2 configuration) with "Das geprüfte Dokument enthält weder Fehler noch Warnungen". The ZUGFeRD PDFs also pass veraPDF (PDF/A-3B) and the Mustang validator's ZUGFeRD rules. The files and reports are on the product page; please check them yourself⁶.

What the module does not do: receive and book purchase invoices, archive documents for the retention period, connect directly to public-sector portals, or produce the MINIMUM and BASIC WL profiles. XRechnung over Peppol needs the separate E-Invoicing: Peppol package and a contract with a Peppol access point provider; without them you download the XRechnung and upload it to the buyer's portal.

Retention is the other half. Under § 14b UStG invoices are kept for eight years, and for an E-Rechnung at least the structured part must be kept unaltered¹. The module stores each file once with a SHA-256 checksum, but it is not an archive; your archive should receive the XML, not just the PDF.

Checklist

1. Make sure you can receive E-Rechnungen for your own purchases. An inbox counts, but someone has to read the XML.
2. Work out, with your tax adviser, whether your 2026 turnover puts you in the 2027 or the 2028 group.
3. List who you invoice: German businesses, public bodies (with Leitweg-IDs), customers abroad, consumers.
4. Collect the seller details XRechnung needs: contact name, phone, e-mail, VAT ID or tax number, IBAN.
5. Ask business customers for their VAT ID at checkout, and public bodies for their Leitweg-ID.
6. Choose formats per buyer type: ZUGFeRD EN 16931 for businesses is a sensible default, XRechnung for public bodies.
7. Validate sample files with the KoSIT validator before your first live invoice, and keep the reports.
8. Decide how corrections work: a credit memo and a new invoice, never an edited file.
9. Hand the XML files to your archive or accounting system, not only the PDFs.
10. Watch for XRechnung 4.0, expected in spring 2027, and update when your tools support it.

Frequently asked questions

Is a PDF invoice still valid in Germany?

Until the end of 2026 it is, if the recipient agrees to PDF; until the end of 2027 if your prior-year turnover was not more than EUR 800,000. After that, invoices between German businesses must be E-Rechnungen, apart from exceptions such as invoices up to EUR 250 gross¹.

Is ZUGFeRD an E-Rechnung?

ZUGFeRD from version 2.0.1 is, in every profile except MINIMUM and BASIC-WL¹. Since the structured XML is the leading part, check the XML, not the PDF.

Do I need a Leitweg-ID for my own company?

No. A Leitweg-ID identifies public-sector recipients. Businesses do not need one, and in B2B a placeholder in BT-10 is enough for VAT purposes¹.

Do e-invoices have to go over Peppol in Germany?

No. German law does not prescribe a transmission route for B2B; e-mail is fine¹. Federal public bodies accept Peppol among other channels through the OZG-RE portal⁴.

I sell from Austria to German businesses. Does this apply to me?

The German obligation targets businesses established in Germany. A seller registered in Germany without an establishment there can state this on the invoice¹. Your German customers may still prefer an E-Rechnung, and for public-sector buyers the procurement rules apply anyway. Check your case with an adviser.

Selling into Poland or Belgium too? See KSeF for Magento 2 and Peppol e-invoicing for Magento. For collecting VAT numbers only from business customers, see asking business customers for a VAT number. The E-Invoicing: Germany product page has sample files and validation reports, and the user guide describes every setting.

Sources

1. Bundesministerium der Finanzen, "Fragen und Antworten zur Einführung der obligatorischen (verpflichtenden) E-Rechnung zum 1. Januar 2025" (Stand März 2026), questions 2, 3, 4, 4a, 6, 7, 8, 11, 12, 12a and 13, https://www.bundesfinanzministerium.de/Content/DE/FAQ/e-rechnung.html, checked 22 October 2026. ↩1 ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13 ↩14 ↩15 ↩16 ↩17 ↩18 ↩19 ↩20 ↩21 ↩22 ↩23 ↩24 ↩25
2. KoSIT, "XRechnung" (versions, validity, validator and validator configuration), https://xeinkauf.de/xrechnung/, checked 22 October 2026. ↩1 ↩2 ↩3
3. Directive 2014/55/EU of 16 April 2014 on electronic invoicing in public procurement, https://eur-lex.europa.eu/eli/dir/2014/55/oj, checked 22 October 2026. ↩
4. E-Rechnung-Bund (Federal Ministry of the Interior procurement office), FAQ, sections on XRechnung, ZUGFeRD, buyer reference (Leitweg-ID) and Peppol participant IDs, https://e-rechnung-bund.de/en/faq/, checked 22 October 2026. ↩1 ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
5. Bundesministerium der Finanzen, letter of 15 October 2025, "Einführung der obligatorischen elektronischen Rechnung bei Umsätzen zwischen inländischen Unternehmern ab dem 1. Januar 2025; Anpassung des Umsatzsteuer-Anwendungserlasses", III C 2 - S 7287-a/00019/007/243, margin numbers 6a, 6b and 35a, https://www.bundesfinanzministerium.de/Content/DE/Downloads/BMF_Schreiben/Steuerarten/Umsatzsteuer/Umsatzsteuer-Anwendungserlass/2025-10-15-einfuehrung-obligatorische-e-rechnung.pdf, checked 22 October 2026. ↩1 ↩2 ↩3
6. CommerceGears, "E-invoicing: Germany (XRechnung, ZUGFeRD)" product page, version 2.2.0, https://commercegears.com/magento-2-extensions/e-invoicing-germany-xrechnung-zugferd/, checked 22 October 2026. ↩1 ↩2
7. CommerceGears, E-Invoicing: Germany user guide, sections 3 to 7, https://commercegears.com/user-guides/magento-2-extensions/e-invoicing-germany-xrechnung-zugferd/, checked 22 October 2026. ↩