Business Central
Ina Rogalev
6. May 2026
In mid-October, the Federal Ministry of Finance published examples of the electronic formats permitted in Germany. What is the difference between XRechnung and PEPPOL-BIS? What is the difference to ZUGFeRD? What are the national business rules? Let’s take another deep dive.
You can find the previous blog series on e-billing here:
PART 1: What does the e-bill mean?
PART 2: Transitional rules and timetable for e-billing
PART 3: Format differences of the e-bill
PART 4: Requirements for the transfer of the e-bill
PART 5: The e-bill in practice
PART 6: Processing the e-invoice in Microsoft Dynamics 365 Business Central / Navision
PART 7: Frequently asked questions about e-billing
The current letter with reference number “III C 2 – S 7287-a/23/10001 :007” and number “2024/0883282” gives examples of the formats permitted in Germany.
The BMF defines that the use of structured invoice formats that comply with the EN 16931 series of standards (see recitals 28 to 32) is always permissible. Likewise, structured electronic invoice formats that deviate from the EN 16931 series of standards can also be used under certain conditions, e.g. EDI procedures in accordance with Article 2 of Commission Recommendation 94/820/EC of October 19, 1994. According to recitals 33 and 34, EDIFACT invoices that are compatible with EN 16931, i.e. that transport the same content, can also continue to be used after the transitional periods.
The Federal Ministry of Finance cites XRechnung and ZUGfERD as examples of nationally permissible formats. Factur-X (France) and Peppol-BIS Billing are examples of European electronic invoice formats.
We would like to go into the differences in more detail.
We have already discussed the differences in the schema in Part 3 The structure of the e-bill. The following table compares the two national formats.
XInvoice | TRAINING | |
Type of file | Pure XML file. In other words, a simple text file that contains the invoice information in a machine-readable XML structure. The file only contains a machine-readable format. | Is a PDF/A-3 file. This is a human-readable PDF file in which a machine-readable XML structure is embedded. The file contains both a machine-readable and a human-readable format. A “normal” PDF file only contains the human-readable image. |
Schema of the XML structure | ISO/IEC 19845 Information technology – Universal | UN/CEFACT Cross Industry Invoice in XML Schemas 16B (CII) It must be version 2.0.1 or higher. The MINIMUM and BASIC-WL profiles are excluded. |
European alternatives | PEPPOL-BIS3 | Factur-X French format, which will be identical to ZUGfERD from September 18, 2024. Factur-X EN |
ZUGFeRD and Factur-X
Factur-X has been identical to ZUGfERD since September 18, 2024. The only difference is the name. Both are PDF/A-3 files that contain an XML according to the same schema.
Both formats are based on UBL. XRechnung is basically PEPPOL plus an extension/adaptation of the business rules applicable to XRechnung to include special German features.
The following therefore count for XInvoice
XRechnung and PEPPOL-BIS therefore do not differ from each other in terms of the UBL schema. XRechnung is based on PEPPOL-BIS, but applies additional business rules.
They define, for example, which mandatory content must be specified, or which content correlations exist and must match.
Rule origin | Examples |
Standard rules of EN 16961 | BR-30 BR-CO-15 |
PEPPOL-BIS applicable adapted rules | PEPPOL-EN16931-R046 PEPPOL-EN16931-R121 |
Additional supplementary national German business rules | BR-DE-4 BR-DE-19 |
Example: Business rule BR-DE-18 for cash discount
Let’s take an additional national rule that concerns the cash discount.
A cash discount is a reduction due to a shortened payment period. In Germany, the transmission of cash discount information is common practice in many industries – in other European countries, let alone third countries, it is rarely used.
The EN 16931 data model therefore does not currently provide for a corresponding process and therefore does not provide any structured information elements to map cash discount information in an appropriate form. According to the standard rule, it is a free text field.
The additional German national business rule BR-DE-18 therefore defines
The information for granting cash discounts must be transmitted as follows in the element “Payment terms” (BT-20):
“SKONTO” must be entered in the first segment, “DAYS=n” in the second, “PERCENT=n” in the third. Perpercent figures must be entered without a sign and separated by two decimal places.
If the amount to be calculated is not based on “Amount due for payment” (BT-115), but only part of the amount due on the invoice, the basic value for calculating the cash discount must be specified as the fourth segment “BASIC AMOUNT=n” in accordance with the semantic data type Amount.
Each entry begins with a #, the segments are separated by a # and a line ends with a #. An XML-compliant line break must follow the end of a complete cash discount entry.
All details for granting cash discounts must be in capital letters. Additional whitespace (spaces, tabs or line breaks) is not permitted. Characters or texts other than those specified above are not permitted.
In the case of other invoices, the information about the discount can be read, understood and implemented by the clerk.
If the discount was previously specified as “14 days 2%”, “2% discount for payment within the next 2 weeks” or “EUR 98.23 until November 8, 2024”, the clerk could apply the discount accordingly. He just had to read it and know what he was doing.
For machine-readable processing, “14 days 2%” or “2 percent within the next 2 weeks” makes a significant difference. This information therefore had to be standardized.
Standardization takes place via a business rule that
Example: Business rule BR-DE-17 for credit notes
Using the XRechnung standard, credit notes can be transmitted in accordance with Section 14 (2) sentence 2 UStG, i.e. the recipient of the service prepares the invoice (credit note procedure). This must be clearly distinguished from commercial credit notes and invoice corrections.
The semantic data model of the XRechnung provides the “Invoice type code” (BT-3) for unique identification. This is defined in business rule BR-DE-17.
This clearly identifies the following scenarios
Scenario | Code in BT-3 | Value according to UNTDID 1001 | Remark |
(Invoice) correction | 384 | Corrected invoice | Reference to original previous invoice or Credit note must be issued (see “PRECEDING INVOICE REFERENCE” (BG-3)) |
Voucher/credit bill | 381 | Credit note | Treatment as a commercial credit note. No reference on previous invoice necessary. |
Credit note according to UStG | 389 | Self-billed invoice | Treatment as a credit note pursuant to section 14 (2) sentence 2 UStG |
Further examples:
Other business rules take care of data consistency in the document, for example. For example, the sum of all lines must not deviate from the total sum. Or they define certain identifiers so that the document can be handled correctly.
What constitutes a valid invoice is defined by the German Value Added Tax Act – in principle, this does not change. Not valid therefore does not necessarily mean invalid.
Let’s stay with the cash discount. If the invoice issuer generates an electronic invoice with a cash discount in accordance with PEPPOL-BIS3 and the cash discount definition therefore does not comply with the additional national business rules, this does not turn the electronic invoice into an invalid invoice within the meaning of the VAT Act.
In all likelihood, manual reworking will be necessary.
The invoice is then not valid after checking, but is still valid according to VAT law.
The only actual requirement is that the format must comply with the EN 16931 series of standards. This is defined in the BMF letter “III C 2 – S 7287-a/23/10001 :007” and number “2024/0883282” in point 2.3 and margin note 24ff.
What happens with invalid documents must be clarified between the invoice issuer and invoice recipient
The national business rules for Germany are developed by the Coordination Office for IT Standards published.
The Kosit also lists the specific business rules and definitions for CIUS XRechnung and Extension.
Info box
CIUS – Core Invoice Usage Specification.
This is a specified, standardized form of electronic invoice (e-invoice) that was developed by the EU to ensure interoperability and compatibility. CIUS helps to define certain requirements and fields for electronic invoices in order to facilitate and standardize the exchange between companies and authorities in different countries.
According to XRechnung v.3.0.2, these are the rules that apply in addition to PEPPOL-BIS3
| ID | description |
| BR-DE-1 | An invoice (INVOICE) must contain information on “PAYMENT INSTRUCTIONS” (BG-16). |
| BR-DE-2 | The “SELLER CONTACT” group (BG-6) must be transmitted. |
| BR-DE-3 | The “Seller city” element (BT-37) must be transmitted. |
| BR-DE-4 | The element “Seller post code” (BT-38) must be transmitted. |
| BR-DE-5 | The “Seller contact point” element (BT-41) must be transmitted. |
| BR-DE-6 | The element “Seller contact telephone number” (BT-42) must be transmitted. |
| BR-DE-7 | The element “Seller contact email address” (BT-43) must be transmitted |
| BR-DE-8 | The “Buyer city” element (BT-52) must be transmitted. |
| BR-DE-9 | The element “Buyer post code” (BT-53) must be transmitted. |
| BR-DE-10 | The element “Deliver to city” (BT-77) must be transmitted if the group “DELIVER TO ADDRESS” (BG-15) is transmitted. |
| BR-DE-11 | The element “Deliver to post code” (BT-78) must be transmitted if the group “DELIVER TO ADDRESS” (BG-15) is transmitted. |
| BR-DE-12 | A zip code must be transmitted with the element “Deliver to post code” (BT-78). |
| BR-DE-13 | Not defined. |
| BR-DE-14 | The element “VAT category rate” (BT-119) must be transmitted. |
| BR_DE_15 | The “Buyer reference” element (BT-10) must be transmitted. |
| BR-DE-16 | If the tax codes S, Z, E, AE, K, G, L or M are used in an invoice, at least one of the elements “Seller VAT identifier” (BT-31), “Seller tax registration identifier” (BT-32) or “SELLER TAX REPRESENTATIVE PARTY” (BG-11) must be transmitted. |
| BR-DE-17 | With the element “Invoice type code” (BT-3), the following codes from the code list UNTDID 1001 should be transmitted:
|
| BR-DE-18 | The information for granting cash discount must be transmitted as follows in the element “Payment terms” (BT-20): Enter “SKONTO” in the first segment, “DAYS=n” in the second and “PERCENT=n” in the third. Percentages must be entered without a sign and separated by two decimal places. If the amount to be calculated is not based on “Amount due for payment” (BT-115), but only a part of the due amount of the invoice, the basic value for calculating the cash discount must be specified as the fourth segment “BASISBETRAG=n” in accordance with the semantic data type Amount. Each entry begins with a #, the segments are separated by a # and a line ends with a #. An XML-compliant line break must follow the end of a complete cash discount entry. All information on the granting of discounts must be given in capital letters. Additional Whitespace (spaces, tabs or line breaks) is not permitted. Characters or texts other than those specified above are not permitted. |
| BR-DE-19 | “Payment account identifier” (BT-84) should contain a correct IBAN if SEPA is requested in “Payment means type code” (BT-81) with the code 58. |
| BR-DE-20 | “Debited account identifier” (BT-91) should contain a correct IBAN if SEPA is requested in “Payment means type code” (BT-81) with the code 59. |
| BR-DE-21 | The element “Specification identifier” (BT-24) should syntactically correspond to the identifier of the XRechnung standard. |
| BR-DE-22 | The documents attached to a submitted invoice in “ADDITIONAL SUPPORTING DOCUMENTS” (BG-24) must have a unique file name in the “Attached document” element (BT-125) (not case-sensitive). |
| BR-DE-23 | If “Payment means type code” (BT-81) contains a key for credit transfers (30, 58), “CREDIT TRANSFER” (BG-17) must be transmitted. “PAYMENT CARD INFORMATION” (BG-18) and “DIRECT DEBIT” (BG-19) must not be transmitted in this case. |
| BR-DE-24 | If “Payment means type code” (BT-81) contains a key for card payments (48, 54, 55), exactly “PAYMENT CARD INFORMATION” (BG-18) must be transmitted. “CREDIT TRANSFER” (BG-17) and “DIRECT DEBIT” (BG-19) must not be transmitted in this case. |
| BR-DE-25 | If “Payment means type code” (BT-81) contains a key for direct debits (59), exactly “DIRECT DEBIT” (BG-19) must be transmitted. “CREDIT TRANSFER” (BG-17) and “PAYMENT CARD INFORMATION” (BG-18) must not be transmitted in this case. |
| BR-DE-26 | If code 384 (Corrected invoice) is transferred in the “Invoice type code” (BT-3) element, “PRECEDING INVOICE REFERENCE” (BG-3) should be present at least once. |
| BR-DE-27 | The element “Seller contact telephone number” (BT-42) should be used to transmit a valid telephone number. A valid telephone number should contain at least three digits. |
| BR-DE-28 | The element “Seller contact email address” (BT-43) is used to transmit a valid email address. Note: Technical details on implementation can be found in the XRechnung Schematron rule BR-DE-28. |
| BR-DE-29 | This rule has been replaced by PEPPOL-EN16931-R061 since XRechnung 3.0.0. |
| BR-DE-30 | The element “Bank assigned creditor identifier” (BT-90) must be transmitted if the group “DIRECT DEBIT” (BG-19) is transmitted. |
| BR-DE-31 | The element “Debited account identifier” (BT-91) must be transmitted if the group “DIRECT DEBIT” (BG-19) is transmitted. |
EU member states can supplement the semantic data model of EN standard 16931 with so-called extensions to cover industry-specific fields of application. The “Extension XRechnung” is particularly relevant for the construction industry due to the extensions, but other sectors can also benefit from its use. Further information can be found on the homepage of the Coordination Office for IT Standards.
Kosit has published some validators as open source on github: Coordination Center for IT Standards.
Tip: The Kosit Validator for XRechnung can also check ZUGFeRD XMLs according to national rules.
MARKUS WEILAND
project manager
Other articles that might be interesting for you
