Peppol in Germany: what a valid BIS 3.0 invoice additionally requires
When the seller and the buyer are both located in Germany, a Peppol BIS Billing 3.0 invoice has to pass more than EN 16931 and the general Peppol rules. The official OpenPeppol rule set adds 31 German national rules, the DE-R rules. Most are mandatory: if one fails, the invoice is invalid. A few are warnings.
This article lists what the German rules require, explains why “valid” always comes with a version number, and shows how SealDoc checks every German Peppol invoice before it exists.
When the German rules apply
Every DE-R rule starts with the same condition: both the supplier and the customer are located in Germany. An invoice from a German seller to a buyer in the Netherlands, or from a French seller to a German buyer, is checked against EN 16931 and the Peppol rules, but not against the DE-R rules.
What the German rules require
Grouped by part of the invoice, with the rule numbers from the official rule set, release 3.0.21.
Seller
| Rule | Requirement |
|---|---|
| DE-R-002 | The seller contact group (BG-6) is present |
| DE-R-005 | Seller contact point (BT-41) |
| DE-R-006 | Seller contact telephone number (BT-42) |
| DE-R-007 | Seller contact email address (BT-43) |
| DE-R-003, DE-R-004 | Seller city (BT-37) and post code (BT-38) |
| DE-R-016 | With VAT category S, Z, E, AE, K, G, L or M: the seller VAT identifier (BT-31), the tax registration identifier (BT-32) or a tax representative (BG-11) |
| DE-R-027, DE-R-028 (warnings) | A plausible telephone number (at least three digits) and a well-formed email address |
Buyer and delivery
| Rule | Requirement |
|---|---|
| DE-R-015 | Buyer reference (BT-10) |
| DE-R-008, DE-R-009 | Buyer city (BT-52) and post code (BT-53) |
| DE-R-010, DE-R-011 | If a delivery address (BG-15) is given: its city (BT-77) and post code (BT-78) |
Payment
| Rule | Requirement |
|---|---|
| DE-R-001 | Payment instructions (BG-16) |
| DE-R-023-1, DE-R-023-2 | Credit transfer (code 30 or 58): the credit transfer group (BG-17), and no card or direct debit group |
| DE-R-024-1, DE-R-024-2 | Payment card (code 48, 54 or 55): the card group (BG-18), and no other payment group |
| DE-R-025-1, DE-R-025-2 | Direct debit (code 59): the direct debit group (BG-19), and no other payment group |
| DE-R-030, DE-R-031 | Direct debit: the bank assigned creditor identifier (BT-90) and the debited account identifier (BT-91) |
| DE-R-018 | Skonto in the payment terms (BT-20) in a fixed format, for example #SKONTO#TAGE=14#PROZENT=2.00# |
| DE-R-019, DE-R-020 (warnings) | A valid IBAN for SEPA credit transfer (58) and SEPA direct debit (59) |
VAT and document
| Rule | Requirement |
|---|---|
| DE-R-014 | The VAT category rate (BT-119) for every VAT category |
| DE-R-017 (warning) | An invoice type code (BT-3) from a short list: 326, 380, 381, 384, 389, 875, 876 or 877 |
| DE-R-026 (warning) | A corrected invoice (384) refers to the preceding invoice (BG-3) |
| DE-R-022 | Attachments (BG-24) have unique file names |
| DE-R-T02 (warning) | An external document location (BT-124) is an absolute URL |
The Skonto rule is the one that surprises most teams. The format is strict: every entry starts and ends with a #, the segments are SKONTO, TAGE= and PROZENT= in capital letters, the percentage has a dot and two decimals, and no other text is allowed in that line.
Why “valid” has a version number
OpenPeppol publishes its rules in releases. A file that is valid under one release can be invalid under the next, because rules are added or tightened. Release 3.0.21 has been mandatory since 17 August 2026. Compared with 3.0.20 it adds one German rule, DE-R-T02.
So the honest answer to “is this invoice valid?” always includes two more words: against which rules, and in which release.
How SealDoc checks German Peppol invoices
SealDoc creates the Peppol BIS 3.0 invoice (UBL 2.1) from JSON, through the API with the profile PeppolBis3. Before the invoice exists, SealDoc checks it against EN 16931, the Peppol rules and the German rules. An invoice that does not pass is not created.
To be sure that our own check says what the official rules say, we had an independent validator check the result. On 2 October 2026 we ran phive, the open-source validation engine, with the official OpenPeppol rules 3.0.21 in an isolated container, against exactly the bytes SealDoc delivers:
- an invoice at 19%: valid, no errors, no warnings;
- an invoice with 19% and 7% on one invoice: valid, no errors, no warnings;
- a credit note: valid, no errors, no warnings.
And a counter-test: the same invoice without the seller’s email address. The validator rejects it on DE-R-007. That is how you know the German rules really run.
Sending via Peppol
Sending via Peppol directly from SealDoc is almost here. We are completing the final steps of the connection.
Frequently asked questions
Do the German rules apply to cross-border invoices?
They apply only when both the seller and the buyer are located in Germany. A cross-border invoice is checked against EN 16931 and the Peppol rules.
Does SealDoc also create XRechnung?
Yes. SealDoc creates XRechnung 3.0 (CII) as a PDF/A-3 with the XML embedded, in the browser with SealDoc Invoice and through the API. The XRechnung 3.0 compliance guide explains the German rules for that format.
Where do I start?
With the introduction to Peppol BIS 3.0 for the basics, and the developer page for the API.