In short and in plain language
This text is about the e-invoice in the XRechnung format. A new version is coming soon. It is called XRechnung 4.0.
With the new version, one invoice can hold many orders. This helps with an invoice for the whole month. Discounts for fast payment also get their own fields.
The old version stays valid for a while. There is no need to rush. But the shop and the ERP need good data. The ERP is the program for orders, stock and invoices.
This text does not replace tax advice. Please ask your tax adviser.
We help to get your shop and ERP ready for the new version.
Many B2B shops do not invoice business customers order by order but once a month: one collective invoice covering all deliveries, often with a cash discount for payment within a set period. E-invoicing has so far been a tight fit for exactly this case. XRechnung 3.0 allows at most one purchase order reference in the invoice header, and the discount sits as a coded string in the free-text field for payment terms. XRechnung 4.0 changes that: on 15.09.2026 the German Coordination Office for IT Standards published a pre-release that can show several orders and deliveries per invoice and moves early payment discounts into a group of their own (KoSIT). There is no need to rush, because XRechnung 3.0 remains in force at least until 31.07.2027 (KoSIT). But anyone issuing collective invoices with buyers’ purchase order numbers and tiered discounts can use the months until the final bundle to prepare the data in shop and ERP. This article shows which fields are new, which data has to be clean beforehand and what a test plan looks like.
Key takeaways
- KoSIT published the pre-release of XRechnung 4.0 on 15.09.2026, and it is not yet intended for production use. The final bundle is expected in spring 2027 (KoSIT).
- XRechnung 3.0 remains in force at least until 31.07.2027, and parallel use of the previous and new EN 16931-1 is planned until March 2029 (KoSIT). The exact transition periods will come with the bundle.
- Several orders and deliveries per invoice become possible: purchase order reference (BT-188), delivery note (BT-198) and delivery date (BT-187) can sit on each invoice line (KoSIT).
- Cash discounts move from the string #SKONTO#TAGE=n#PROZENT=n# in field BT-20 into the new group BG-35 with end date, percentage and amount. Periods counted in days become calendar dates (KoSIT).
- For a collective invoice, the shop needs the customer’s purchase order number for every order and the ERP needs delivery note and delivery date per line, because a reference to the delivery note is not enough in an e-invoice (BMF).
- Before switching, run a validated test for every invoice type: collective invoice, partial delivery, tiered discount, corrective invoice. Keeping the validation report is advisable as evidence (BMF).
What the XRechnung 4.0 pre-release changes
XRechnung is the German implementation of the European standard EN 16931 for electronic invoices. That standard has been revised: the new edition EN 16931-1:2026 has been ratified and has been available in English since March 2026 (KoSIT). Overall, more than 50 new business terms and 7 new business groups were added (KoSIT). Business terms, BT for short, are the individual data fields of an e-invoice, while business groups (BG) bundle several of them. XRechnung 4.0 carries these changes into the German standard. The pre-release of 15.09.2026 is meant to give an early overview and is expressly not yet intended for productive use (KoSIT).
- Several orders and deliveries can be referenced in one invoice, with purchase order and delivery note references per line (KoSIT).
- More detailed delivery information becomes possible, down to delivery date and delivery address per invoice line (KoSIT).
- Cash discounts get their own fields in group BG-35 “Early Payment Discount”, which replaces the previous convention (KoSIT).
- Late payment interest can be stated in a structured way in group BG-36 “Late Payment Penalty” (KoSIT).
- Charges collected for third parties are covered by the new group BG-34 “Charges on Behalf of a Third Party” (KoSIT).
- Buyer reference and attachments: BT-10 “Buyer reference” may occur more than once, and XML attachments are allowed in the core invoice (KoSIT).
KoSIT names the dissolution of the strict relationship “one order – one delivery – one invoice” as a key aspect of the new core invoice model (KoSIT). For wholesale and industry, this is the heart of the change: in future, an invoice can be structured the way the business it bills was actually done. Depending on the sector, KoSIT says, the new functions may have far-reaching effects on how invoices are created and processed (KoSIT). For a B2B shop this is less about the storefront than about the data behind it: whatever is not captured cleanly at ordering and shipping cannot be supplied by the invoice at the end of the month.
Timeline: 3.0 stays valid, 4.0 arrives in 2027
Five dates matter for planning. XRechnung 3.0 has been in force since 01.02.2024 (KoSIT). Because there was no normative release in summer 2026, this version remains in force at least until 31.07.2027 (KoSIT). The final version 4.0 is expected in spring 2027, published as a bundle together with the technical components (KoSIT). It still depends on preparatory work by the European standards body CEN: the syntax binding documents have been published, while the CEN validation artefacts are still pending (KoSIT).
| Date | Milestone | What it means for shop and ERP |
|---|---|---|
| 01.02.2024 | XRechnung 3.0 enters into force | current standard for outgoing invoices |
| 15.09.2026 | XRechnung 4.0 pre-release | read fields and rules, find data gaps, no production use |
| Spring 2027 (expected) | XRechnung 4.0 bundle with technical components | mapping and validation against the final version |
| 31.07.2027 (at least) | XRechnung 3.0 remains in force until then | existing invoice generation stays usable |
| March 2029 | end of the planned parallel use of both EN 16931-1 editions | outer frame for the transition periods |
Parallel use of the previous and the new edition of EN 16931-1 is planned until March 2029 (KoSIT). The exact transition periods for XRechnung will be set within that frame and announced with the 4.0 bundle (KoSIT). So far, there is no single cut-over date on which all invoice issuers switch at once. For planning, it therefore makes sense to be able to generate both versions side by side for a while, depending on what each customer can receive.
If you issue the hybrid ZUGFeRD format instead of XRechnung, you are affected as well, because ZUGFeRD from version 2.0.1 is based on the EN 16931 series (BMF). The German e-invoicing forum FeRD already added functionality from the upcoming EN 16931-1:2026 to the EXTENDED profile starting with ZUGFeRD 2.5 (FeRD). According to FeRD, the next ZUGFeRD release is expected in autumn 2026 and is to contain further functions from the new revision of EN 16931 (FeRD). If you issue both formats, it makes sense to plan the switch for both together.
A pre-release is work in progress
Why the format matters for VAT
German VAT law ties the e-invoice to a format. Its structured electronic format must comply with the European standard on electronic invoicing, or be agreed between issuer and recipient and then allow correct and complete extraction of the mandatory details into a format that complies with the standard or is interoperable with it (§ 14 Abs. 1 Satz 6 UStG). In the tax authority’s view, XRechnung and, under certain conditions, ZUGFeRD meet the requirements of an invoice that complies with EN 16931 (BMF). Which permitted format is used is a civil-law matter that only the contracting parties decide (BMF).
The obligation to issue e-invoices arrives in stages. Invoices for supplies made in 2025 and 2026 may still be sent on paper, or in another electronic format with the recipient’s consent, until 31 December 2026 (§ 27 Abs. 38 UStG). For supplies made in 2027, this relief only applies if the issuer’s total turnover in the previous year did not exceed EUR 800,000 (§ 27 Abs. 38 UStG). What the obligation means for shop and ERP in detail is covered in our article on the e-invoicing mandate for B2B shops. Invoices to business customers in other EU countries are covered in the article on e-invoicing customers elsewhere in the EU.
One more point matters when the format changes: a file that fails the requirements for the structured format because of format errors counts as an “other invoice” in a different electronic format (BMF). Moving to a new version is therefore not purely an IT topic. If the system produces a version the recipient cannot process, queries follow, and in the worst case the invoice has to be issued again.
Collective invoices: several orders on one document
For VAT purposes, a collective invoice can be issued as an e-invoice too (BMF). The calendar month in which the goods were delivered may be stated as the time of supply (§ 31 Abs. 4 UStDV). That suits the monthly invoice many B2B shops use for regular customers buying on account. One restriction, however, concerns exactly the tool that used to keep collective invoices lean: the tax authority only accepts a reference to the delivery note as the description of the goods for an “other invoice” (BMF). Likewise, only “other invoices” may leave the time of supply to the delivery note; in an e-invoice, that information must be contained in the prescribed structured data format (BMF).
So the e-invoice itself has to carry what used to be spread across several documents. XRechnung 3.0 allows at most one purchase order reference (BT-13) in the invoice header (KoSIT). In a collective invoice covering ten orders, the other numbers therefore often end up in line texts or notes. That makes life hard for the customer’s invoice checking: their system is supposed to match every line to an order and a goods receipt, but only finds the number as free text.
The pre-release solves this with references per invoice line. The purchase order reference sits either in the header (BT-13) or on each line (BT-188), but not in both places (KoSIT). Delivery notes get a reference in the header (BT-197) and on each line (BT-198), with the same either-or rule (KoSIT). Delivery details such as recipient, delivery location and actual delivery date (BT-187) can be stated per line in group BG-37, again either in the header or on the lines (KoSIT).
| Information | XRechnung 3.0 | 4.0 pre-release | Data source |
|---|---|---|---|
| Customer purchase order number | at most one, in the header (BT-13) | in the header (BT-13) or per line (BT-188) | checkout, EDI or catalogue order |
| Delivery note | no field of its own, only despatch advice (BT-16) | in the header (BT-197) or per line (BT-198) | ERP, shipping |
| Delivery date | once in the header (BT-72) | per line in BG-37 (BT-187) | ERP, goods issue |
| Buyer reference | exactly one (BT-10) | several allowed (BT-10) | customer master, checkout |
| Cash discount | coded string in text field BT-20 | group BG-35 with date, percentage, amount | payment terms in the ERP |
| Late payment interest | no field of its own | group BG-36 | payment terms in the ERP |
For a B2B shop this leads to a clear division of labour. Whatever the customer enters when ordering, the shop has to capture and pass to the ERP unchanged. Whatever arises during picking and shipping, the ERP has to assign to the right invoice line. If either is missing, even a good invoicing interface cannot fill the new fields.
Order reference per line: what shop and ERP must supply
The most important piece of information for a collective invoice is the customer’s purchase order number. Many purchasing departments generate it in their own system and check incoming invoices against it. In the shop, this calls for a checkout field that is filled in for every order and is mandatory for customers who require it. If the order arrives via EDI or a catalogue interface, the customer supplies the number; it must then land in the ERP order as a field of its own, not in a comment. Our articles on EDI in the B2B shop and on framework contracts and call-off orders show how such channels are connected.
Customer purchase order number
One field per order in the checkout, switchable to mandatory per customer account, with length and character checks so that the number later lands unchanged in BT-13 or BT-188.
Order line
If the customer uses line numbers in their purchase order, the invoice needs them as well. Field BT-132 references a single line of the purchase order.
Delivery note number
The ERP has to know which delivery note contains which invoice line, including partial deliveries in which one order is split across two delivery notes.
Delivery date per line
The actual date from goods issue, not the order date from the shop. For monthly invoices the calendar month is enough for VAT, but the new field takes the exact day.
Delivery address per line
If a customer is supplied at several sites or plants, the address belongs on the line. Group BG-37 takes recipient, delivery location and address per line.
Buyer reference
Department, cost centre or routing ID: whatever the customer needs for internal routing is held in the customer master and can be passed on several times in future (BT-10).
One point is easily overlooked with collective invoices: the order in which the data is created. The purchase order number exists at checkout, the delivery note at shipping, the invoice only at month end. If the shop writes the purchase order number only into the order confirmation and does not pass it to the ERP as a field of its own, it is lost by month end. A simple check: take three real orders from last month and see whether the customer’s number reappears in the ERP order, the delivery note and the invoice line.
For public-sector buyers the buyer reference is already taken: the routing ID (Leitweg-ID) uses the Buyer Reference field, which is mandatory in XRechnung (KoSIT), as our article on public-sector buyers in the B2B shop also describes. In B2B use, your own buyer references can be placed there (KoSIT). According to the tax authority, a missing entry in BT-10 is irrelevant for VAT purposes (BMF), yet it is often decisive for routing at the customer’s end. The pre-release allows several buyer references plus an optional identifier for the scheme used (KoSIT).
Cash discounts become a data field
Cash discounts for early payment (Skonto) are common in German B2B trade but have not been part of the European standard so far. The XRechnung 3.0.2 specification states that the EN 16931 data model currently provides no structured information elements for discount information (KoSIT). The German committees therefore agreed a convention for the payment terms text field (BT-20): each discount tier is one line such as #SKONTO#TAGE=14#PROZENT=2.25#, with the segments SKONTO, TAGE (days) and PROZENT (percent) (KoSIT). If the discount only applies to part of the amount due, BASISBETRAG (base amount) follows as a fourth segment (KoSIT). All details must be in capital letters, and additional whitespace is not allowed (KoSIT).
For tax purposes, a note on the invoice such as “2 % Skonto bei Zahlung bis” (2 % discount for payment by) is enough to satisfy the mandatory disclosure of any reduction in consideration agreed in advance (BMF). The discount amount does not have to be shown, neither based on the gross amount nor on the net amount plus VAT (BMF). If the customer takes the discount, the taxable amount is reduced, and no correction of the invoice is required (BMF).
The XRechnung 4.0 pre-release replaces the previous discount convention with the new group BG-35 “Early Payment Discount” (KoSIT). Each discount tier has an end date for the discount period (BT-170), a percentage (BT-171) and an amount (BT-172); the end date is mandatory, while percentage and amount are optional (KoSIT). The group may occur several times, so a tiered discount can be shown, and the percentages of different tiers do not add up (KoSIT). The percentage refers to the invoice total including VAT (BT-112), and if both percentage and amount are given, the amount has to match the percentage arithmetically (KoSIT).
Days turn into dates
- Collective invoice dated 30.11.2026 for EUR 11,900 gross, terms 2 percent within 14 days and 1 percent within 28 days (worked example).
- So far in BT-20: the lines #SKONTO#TAGE=14#PROZENT=2.00# and #SKONTO#TAGE=28#PROZENT=1.00# (worked example).
- With BG-35: tier 1 until 14.12.2026 with 2.00 percent and EUR 238.00, tier 2 until 28.12.2026 with 1.00 percent and EUR 119.00 (worked example).
- Reference amount so far: the amount due for payment (BT-115) unless a BASISBETRAG is given; in the pre-release: the invoice total including VAT (BT-112). If amounts already paid are offset on the invoice, the ERP should know both values separately (KoSIT).
Our articles on B2B payment methods with invoice purchase and credit limits and on the annual rebate in the customer portal show where payment terms and retrospective rebates become visible in the shop. For the e-invoice, what counts is that the same terms exist as data in the ERP: one set of terms per customer, a tier table with days and percentages and a rule stating whether the discount applies to the whole amount or only to part of it. The payment methods we set up in the checkout for this are described on our page on B2B payment methods.
Late payment interest, third-party charges, XML attachments
With group BG-36 “Late Payment Penalty”, late payment rules get their own fields as well: a start date (BT-181), a yearly interest percentage based on the invoice total including VAT (BT-182) and a fixed amount (BT-183) (KoSIT). For transactions not involving a consumer, German law sets an interest rate of nine percentage points above the base rate for payment claims (§ 288 Abs. 2 BGB) and, towards debtors who are not consumers, a lump sum of 40 euros (§ 288 Abs. 5 BGB). Whether and in what form such details belong on the invoice is a joint decision for sales, accounting and legal advice. Technically, a fixed percentage in the field has to be calculated when the invoice is generated, because the base rate is not fixed.
Charges on behalf of a third party are amounts that are not part of the invoice but are meant to be paid with it; group BG-34 holds them with an amount (BT-179) and a description (BT-180) (KoSIT). Whether such amounts occur in your business should be clarified with your tax adviser before a field for them is created in the ERP. Another new point is that XML attachments are allowed in the core invoice (KoSIT). KoSIT sees them mainly where information has to be placed in the invoice logic itself and is relevant for other requirements, for example reporting scenarios (KoSIT). For B2B shops with sector-specific data, this can be a way to pass on additional structured details when a customer asks for them.
Timeline and test plan for shop and ERP
Because the final version is not expected before spring 2027 (KoSIT), preparation can be split into stages. A sensible order is to repair the data at its source first and only then adapt the invoicing interface:
- By the end of 2026: field inventory. For each invoice type (single invoice, collective invoice, partial delivery, corrective invoice), record where purchase order number, delivery note, delivery date, delivery address and discount terms come from and where they get lost today.
- Early 2027: repair data at the source. Checkout field for the purchase order number, handover to the ERP as a field of its own, line reference to the delivery note, discount terms as days and percentages instead of free text.
- With the 4.0 bundle: mapping and validation. Map the business fields to the final field numbers and check every test invoice with the technical components of the bundle.
- Parallel operation: record for each customer which version and which format they receive, and be able to generate both versions as long as both are permitted.
- Switch per customer: after agreeing with the customer, and with a sample invoice before the first real collective invoice in the new format.
A single sample case is not enough for testing. A collective invoice behaves differently from a single invoice, and errors in a tiered discount often only show up in the second tier. These test cases cover the new fields:
- Collective invoice with three orders and two delivery notes, purchase order reference only per line
- Partial delivery: one order split across two delivery notes and two invoices
- Delivery to two different addresses within one invoice
- Tiered discount with two tiers, percentage and amount, rounded to two decimal places
- Corrective invoice referring to a preceding collective invoice
- Customer with a Leitweg-ID or with several buyer references
Every test invoice should be validated against format and business rules. Exercising the care of a prudent businessperson, a trader may rely on the technical result of a validation by a suitable application, and keeping the validation report is advisable as evidence (BMF). Where invoices, delivery notes and reports are stored and for how long is covered in our article on the document archive in the customer account.
How we prepare shop and ERP
We set up invoice generation in Shopware CE so that purchase order number, line references and payment terms from shop and ERP arrive complete in the e-invoice, and we connect it to your ERP via the right integrations. For XRechnung 4.0 this mainly means groundwork on the data: checkout field and customer master in the shop, line references and discount terms in the ERP, test cases for every invoice type. How we set up e-invoicing projects is described on our page on e-invoicing in the B2B shop. If your customers should also retrieve invoices and delivery notes in the customer portal, we plan that in the same step. For an assessment of how far your data reaches today, reach us via the contact page.
Related Articles
E-Invoicing for Business Customers in Other EU States 2027
Germany’s e-invoicing mandate stops at the border. What business customers in Belgium, France and Poland receive and how your shop sets the format per country.
E-Invoicing Mandate 2027: Prepare B2B Shop and ERP
E-invoicing mandate from 2027: how to generate ZUGFeRD and XRechnung per EN 16931 in your B2B store, receive invoices and connect to ERP and accounting.
B2B Shop for Businesses Only: Excluding Consumers Properly
How a B2B shop excludes consumers effectively: a notice on every page, a mandatory company field and a separate confirmation. What German courts have decided.