Many wholesalers solved e-invoicing long ago. In the ERP. If you supply the federal government, you have been issuing e-invoices in line with EN 16931 since the end of 2020, and your accounting team knows structured documents from everyday EDI. The real risk lies elsewhere: in the Shopware shop, which can also generate invoices on the side, and in the customer account, where the buyer expects to find the document.
That is exactly where it gets expensive. Suppose an order covers 40 line items, 28 of them available immediately, and the shop is set up to generate an invoice for all 40 when the order comes in. The ERP invoices the partial delivery of 28 and, two weeks later, the rest.
The customer now has three documents with three numbers that together charge twice the order value. Their accounts payable team rejects them, and payment only follows once someone on your side cancels the shop invoice and explains which documents are valid. Two systems that can both write invoices, and an obligation that only one of them needs to fulfil.
E-invoicing mandate 2027: which deadlines apply to wholesale
As a mid-sized wholesaler, you are affected from the first delivery in January 2027, with the exception of EDI connections (more on that below). The €800,000 threshold for small issuers plays no role for you.
§ 14 UStG (German VAT Act) defines the e-invoice as an invoice in a structured electronic format in line with the European standard EN 16931. A format agreed between both parties is also permitted, provided that the mandatory information can be extracted from it correctly and completely into a format that complies with the standard or is interoperable with it. For supplies between two domestic businesses, the e-invoice is mandatory.
Three dates matter for the deadlines. You have had to be able to receive e-invoices since 1 January 2025; according to the BMF FAQ on e-invoicing (BMF: German Federal Ministry of Finance, as of March 2026), an email inbox is enough for that. You must issue them for sales from 1 January 2027. From 2028, the obligation applies to all businesses in domestic B2B, with permanent exceptions such as small-amount invoices up to €250 and invoices from businesses under the small-business VAT scheme.
Under the transition rules in § 27(38) UStG, paper or, with the recipient’s consent, PDF remains permitted for 2027 sales only for issuers with prior-year turnover of up to €800,000. This article reflects the position as of October 2026; it does not replace legal or tax advice.
At the turn of the year, the date of supply is what counts. Anything delivered from January 2027 needs an e-invoice, even if the order dates from December. For December deliveries, § 27(38) no. 1 only allows paper or PDF if the invoice has been transmitted by 31 December 2026. Go through this with your tax adviser before you switch over the ERP. Your collective invoice for the December call-offs that goes out on 5 January must already be an e-invoice.
ERP, shop or customer account: who creates the e-invoice in wholesale?
This is where the architecture decision is made. A wholesaler rarely invoices only shop orders. Phone orders, EDI orders, field sales, partial deliveries, collective invoices at month-end, rebates and credit notes all run through the ERP. If the shop also writes its own invoices, you have two number ranges and two places where master data drifts apart.
The customer changes their billing address in the shop, the ERP knows nothing about it, the XRechnung from the ERP carries the old address and the shop invoice the new one. Which one is valid?
My recommendation is therefore that in wholesale the ERP creates the e-invoice, whether it is called Business Central, eNVenta or SAP Business One. The shop is the order source and the display surface, with OXID just as with Shopware.
It passes on the order with the customer number, delivery address and the customer’s order reference; the ERP invoices and sends the finished document back, and the customer account offers the XML or ZUGFeRD PDF for download. This document return flow belongs in the requirements specification for your ERP integration; otherwise the integration stops at prices and stock levels, and the buyer calls about the invoice.
Shopware itself has been able to generate e-invoices in ZUGFeRD format since version 6.6.10.0, as a separate XML file or embedded in the PDF, in line with EN 16931 (Shopware release news, February 2025). For a pure online retailer without an ERP, that is workable.
With partial deliveries and monthly credit notes, it falls over. The core uses the XRechnung 3 profile as a fixed setting and writes the shop order number into field BT-10 (buyer reference), as the source code of the ZugferdBuilder shows. The identifier your customer expects there, such as their supplier number for you, therefore doesn’t get in. The shop knows nothing of a collective invoice covering 14 call-offs in a month; it knows documents per order. And cancellation invoices for embedded ZUGFeRD documents were missing entirely at first (GitHub issue #7495, closed in June 2025).
The format itself is also on the move in the first mandatory year. According to the BMF, XRechnung and ZUGFeRD from version 2.0.1 are recognised, excluding the MINIMUM and BASIC-WL profiles. According to KoSIT, XRechnung 3.0 is valid until at least 31 July 2027, the final version of 4.0 is expected in spring 2027, and ZUGFeRD is also being developed continuously. This logic and the version maintenance belong in the system whose vendor supplies updates and which your accounting team runs anyway.
| Task | ERP | Shopware shop | Customer account |
|---|---|---|---|
| Accept orders | Phone, EDI, field sales | Online order, punch-out | no |
| Create e-invoice (XRechnung, ZUGFeRD) | leading system | only makes sense without an ERP | no |
| Master data (VAT ID number, order reference, Leitweg-ID for B2G) | leading system | synchronised | display, correction with return flow |
| Cancellation, credit note, collective invoice | yes | limited | no |
| Deliver and archive the document | Dispatch and archive | Download link | Download |
The customer account is more than a download folder. The buyer places the order, but their accounting team needs the XML, and whether they can see it is determined by roles and approvals, such as those that come with B2B Components. If they can’t see it, they request it by email, and your inside sales team sends it by hand.
In short: the ERP writes, the shop orders, the account shows. You need to be able to justify any deviation from this.
The Leitweg-ID debate in the Shopware forum, soberly sorted
On the subject of the Leitweg-ID (the German routing ID for invoices to public authorities) in Shopware, a thread on the e-invoicing mandate has been running in the Shopware forum since March 2024, and one concern keeps coming back: “XRechnung could be a problem with Shopware: there’s currently no field for the Leitweg-ID, after all.” The workarounds discussed were a registration field, a custom field in the checkout or the comment field.
Picture the comment field across three orders. Customer A enters the Leitweg-ID correctly, customer B writes “Leitweg-ID see last order”, customer C leaves the field blank. None of the three values ends up in a field from which the ERP invoices.
The BMF answers the question unambiguously in its FAQ (question 6): for e-invoices between businesses, a Leitweg-ID is generally not required. It is only needed if the invoice goes to a public authority. Field BT-10, which holds the Leitweg-ID in B2G, is the same field into which the Shopware core writes the shop order number. In B2B, for VAT purposes, it may contain a placeholder such as “-” or an identifier assigned by your customer.
So your B2B customers don’t need a Leitweg-ID, and you don’t have to build anything for it into the Shopware checkout. If you supply public authorities, you still need it. For federal bodies, the federal e-invoicing ordinance (ERechV) has applied since 27 November 2020; for federal states and local authorities, the respective state regulations apply, both alongside the UStG (BMF FAQ, question 4a). Municipal utilities organised as companies count as B2B for VAT purposes; whether they still require a Leitweg-ID, they will tell you in the contract or order.
In all these cases, the Leitweg-ID belongs in the ERP as part of the customer’s master data. The customer account may display it and offer it for correction; the ERP remains the leading system.
The EDI special case: why your EDIFACT connections aren’t automatically sorted in 2027
Wholesale means EDI. According to the B2B market monitor by ECC Köln, wholesalers and manufacturers generated just under €1.6 trillion in sales through digital sales channels in 2025, EDI included. Only €549 billion of that went through online shops and marketplaces, and the larger remainder through other digital channels, including EDI (press release of 5 October 2026).
§ 27(38) no. 3 UStG allows you, for sales in 2027 and with the recipient’s consent, to continue invoicing via EDI in line with Recommendation 94/820/EC, even if the format does not comply with EN 16931. This exception applies regardless of turnover and ends on 31 December 2027. After that, EDIFACT remains permitted only if the mandatory VAT information can be extracted correctly and completely from the format (BMF FAQ, question 7).
The extra year for EDI is a postponement, not an all-clear. The same question arises for every connection. Do you stay with EDIFACT, or do you switch the customer to XRechnung? Staying means that the mandatory information must be fully derivable from the INVOIC message, and someone must be able to prove it. Switching means that the customer must be able to process XRechnung in their system, and you have to clarify that with each EDI partner individually. Both answers lie in the ERP, because that is where the EDI mappings live.
Take a customer who has been receiving INVOIC messages via an EDI service provider for years. Whether every one of them carries all the mandatory information may never have been checked, because so far they have been paid. What you need first is a customer list with the document channel per customer: EDI, e-invoice from the ERP or shop document.
Six questions before the turn of the year
Wherever you can’t answer a question cleanly, that is where your task lies.
- Does your ERP already create documents that comply with EN 16931, XRechnung or ZUGFeRD from 2.0.1, and has anyone run a real invoice through a validator?
- Does your Shopware shop write its own invoices in parallel? If so: switch that off or deliberately make it the only document route.
- Do invoices, cancellations and credit notes flow back from the ERP into the customer account, or does the interface stop at prices and stock levels?
- Are the VAT ID number, the customer’s order reference and, for B2G customers, the Leitweg-ID held as master data in the ERP, and can the customer see them in the shop?
- Which customers run via EDI, and what does the agreement say about format and extraction?
- Who updates the format versions when XRechnung 4.0 becomes binding, no earlier than after 31 July 2027?
If you can’t answer three of these questions, it isn’t a plugin problem. It means the division of roles is missing, and a Shopware B2B project with ERP integration has to define it first, before anyone configures formats. External help pays off when scoping the interface. You can tick the box in the document settings yourself.
Conclusion: the shop wins when it doesn’t write invoices
In wholesale, the e-invoicing mandate is above all a question of responsibility. The format is the solvable part, and Shopware has been able to handle it since 6.6.10.0 too. The problem is that the ERP and the shop can both do it, and nobody has decided which one should. This decision costs one meeting with accounting, IT and e-commerce, and it saves you support calls that tie up your inside sales team.
The timing for this is awkward, and that is exactly why it is right. According to the BGA wholesale survey (BGA: Federation of German Wholesale, Foreign Trade and Services) from October 2026, 34% of the wholesalers surveyed are planning job cuts, and 47% are keeping headcount stable. If you are cutting jobs or just holding steady, you can’t afford an invoicing route that generates cancellations by hand.
Go through the six questions before you configure the year-end changeover in the ERP. Then the order with 40 line items gets two documents instead of three, and both match the delivery.