Peppol BIS 3.0 in Germany: Format, Specification & XML Example

Germany’s e-invoicing mandate is live. If the organisation transmits e-invoices to public sector entities, a thorough understanding of Peppol BIS 3.0 is essential. Many participants frequently conflate this format with XRechnung or employ both without distinguishing between their specific roles. This format is described in depth in this page, together with its technical requirements, German operational context, and a useful example of a UBL 2.1 XML invoice.

Key Takeaways

• OpenPeppol published release 3.0.18 of Peppol BIS Billing 3.0 in November 2024, with the German National Ruleset taking effect on February 17, 2025. These regulations take effect immediately when suppliers and customers are in Germany.
• In the German Peppol network, Peppol BIS 3.0 and XRechnung (UBL version) can now essentially take the place of one another. XRechnung in CII syntax is not interchangeable.
• Germany specific DE-R rules layer on top of the base specification. They cover mandatory payment instructions, seller contact details, buyer reference, invoice type codes, and payment terms format.
• Within the Peppol network, Peppol BIS Billing 3.0 is the preferred invoicing format for Germany. XRechnung requirements are now incorporated through the German National Ruleset within Peppol BIS 3.0. While XRechnung in CII format remains valid for certain domestic use cases, it is not supported as a standard document type within Peppol BIS 3.0.

What is Peppol BIS 3.0 in Germany?

Peppol BIS 3, the standard format for e-invoices on the Peppol network, is mandatory in Germany for B2G invoicing. It follows EN 16931 and employs UBL 2.1, and  XML. For cross-border EU invoicing via Peppol, it is the one format that works everywhere.

“Peppol BIS Billing 3.0” vs. "Peppol BIS 3.0"

These terms are basically the same. Although Peppol BIS Billing 3.0 is its full name, "Billing" is typically omitted. In practical terms, "Peppol BIS Billing 3.0" and "Peppol BIS 3.0" are identical; they match comparable OpenPeppol-maintained specifications.  Generally, people skip ‘Billing’ and just address it as “Peppol BIS 3.0”.

If a partner wants a Peppol BIS 3.0 invoice, they mean a Peppol BIS Billing 3.0 document. And remember, the business rules and XML structure don't change.

How Peppol BIS 3.0 Works in Germany

Germany uses a four-corner Peppol model. Using the Peppol BIS 3.0 format, invoices originate in your ERP or accounting system (Corner 1), are submitted to your Access Point (Corner 2), transmitted to the buyer's Access Point (Corner 3) through an SMP directory lookup, and delivered directly into the buyer's system (Corner 4). This eliminates manual entry, emails, and PDFs.

German participants use unique Peppol IDs (e.g., 9930:DE123456789), where "9930" is the ICD code for German VAT.

Errors often occur when ERP generated files fail Germany-specific DE-R validation rules. These failures cause late rejections, making pre-submission validation essential.

Peppol BIS 3.0 Specification in Germany

OpenPeppol published release 3.0.18 of the BIS Billing specification in November 2024. This release included the German National Ruleset (DE-NRS). However, the DE-NRS rules did not become mandatory until February 17, 2025, when they went live on the Peppol network.

1. The February 2025 update

The German National Ruleset (DE-NRS) became an integral part of the Peppol BIS Billing 3.0 on 17th February 2025. The German National Ruleset introduced special specifications for XRechnung into the Peppol structure while still keeping XRechnung as the German e-invoicing standard.

In practical terms, when both parties are based in Germany, Peppol BIS Billing 3.0 invoices are typically exchanged using the German CIUS, namely XRechnung, ensuring compliance with German e-invoicing requirements. 

This equivalence applies to UBL 2.1 syntax only, because Peppol BIS 3.0 uses UBL 2.1. What is being phased out are the now redundant XRechnung UBL document types (XRechnung UBL Invoice V3.0 and UBL Credit Note V3.0), since Peppol BIS 3.0 with the German National Ruleset now performs the same job. 

They remain usable in parallel during a transition period of roughly 12 to 24 months. XRechnung in CII (UN/CEFACT) syntax is a separate matter. It is not part of Peppol BIS 3.0 and is therefore not interchangeable with it, but it remains a valid XRechnung document type and can still be used. Many senders handle CII files through XRechnung directly rather than as a Peppol BIS 3.0 document. 

2. The Customisation ID

Every Peppol BIS 3.0 invoice must carry this exact value in the Customisation ID field:

urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0

This tells the receiving system exactly which specification version the invoice conforms to. Get this wrong and the invoice will be rejected before the receiver processes a single field.

3. The Profile ID

The ProfileID must be:

urn:fdc:peppol.eu:2017:poacc:billing:01:1.0

4. Mandatory Elements 

Every Peppol BIS 3.0 invoice must include:

• Invoice number (BT-1)
• Invoice issue date (BT-2)
• Invoice type code (BT-3) - use 380 for a standard commercial invoice.
• Invoice currency code (BT-5)
• Seller details: Name, Address, VAT number
• Buyer details: Name and Address
• For German Peppol and B2G e-invoicing, Buyer Reference (BT-10) is mandatory under DE-R-015 and must be provided. A Purchase Order Reference (BT-13) may be included where applicable.
• At least one invoice line.
• VAT breakdown.
• Invoice totals.

5. Germany-Specific Rules (DE-R)

When both supplier and buyer are in Germany, the German National Ruleset adds further requirements. Most of these are fatal errors that cause the invoice to be rejected if they fail. Note that DE-R-017 is a warning rather than a fatal error, so check the severity column before assuming a rule will block delivery.

6. Validation

Two schematron files govern Peppol BIS 3.0 validation:

1. CEN-EN16931-UBL.sch: Contains the EN 16931 core validation rules.
2. PEPPOL-EN16931-UBL.sch: Contains Peppol BIS Billing 3.0 validation rules.
3. DE-NRS (KoSIT): Applies the German National Ruleset (DE-R rules) required for German Peppol/XRechnung compliance.

Both are available at docs.peppol.eu. Most Access Point providers run these validations automatically. Before sending anything to a live endpoint, execute both if you are developing an internal integration.

Peppol BIS 3.0 Format & XML Example

Peppol BIS 3.0 is built upon UBL 2.1. Every invoice is a file in XML format. The following three core namespaces are present in every Peppol BIS 3.0 sample file: 

xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"

Peppol BIS Billing 3.0 Example: German B2G Invoice

A structurally accurate Peppol BIS 3.0 invoice from a German provider to a German federal authority is shown below. This Peppol BIS 3.0 sample file includes the minimum required fields and the German DE-R criteria.

Scenario: A German federal ministry purchases ten industrial sensor units from Müller Technik GmbH (Berlin) for €100 each. 

<?xml version="1.0" encoding="UTF-8"?>
<ubl:Invoice
  xmlns:ubl="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
  xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
  xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">

  <!-- BT-24: Specification identifier (fixed value - do not change) -->
  <cbc:CustomisationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0</cbc:CustomisationID>

  <!-- BT-23: Business process type (fixed value) -->
  <cbc:ProfileID>urn:fdc:peppol.eu:2017:poacc:billing:01:1.0</cbc:ProfileID>

  <!-- BT-1: Invoice number -->
  <cbc:ID>DE-INV-2025-00123</cbc:ID>

  <!-- BT-2: Invoice issue date (format: YYYY-MM-DD) -->
  <cbc:IssueDate>2025-11-10</cbc:IssueDate>

  <!-- BT-9: Payment due date -->
  <cbc:DueDate>2025-12-10</cbc:DueDate>

  <!-- BT-3: Invoice type code. 380 = Commercial Invoice. DE-R-017 lists the permitted values rather than requiring 380 specifically -->
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

  <!-- BT-5: Invoice currency code -->
  <cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>

<!-- BT-10: Buyer reference (mandatory in Germany per DE-R-015). For public sector buyers this is normally the Leitweg-ID. Ask the buyer for it before you invoice -->

  <cbc:BuyerReference>04011000-12345-67</cbc:BuyerReference>

  <!-- Seller Party -->
  <cac:AccountingSupplierParty>
    <cac:Party>

      <!-- BT-34: Seller electronic address. This is the Peppol routing identifier. Scheme 9930 = German VAT -->

     <cbc:EndpointID schemeID="9930">DE123456789</cbc:EndpointID>
      <cac:PartyIdentification>
        <!-- BT-29: Seller identifier (not the routing address) --> 
        <cbc:ID schemeID="9930">DE123456789</cbc:ID> 
      </cac:PartyIdentification>
      <cac:PartyName>
        <cbc:Name>Müller Technik GmbH</cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
        <cbc:StreetName>Berliner Strasse 45</cbc:StreetName>
        <cbc:CityName>Berlin</cbc:CityName>
        <cbc:PostalZone>10115</cbc:PostalZone>
        <cac:Country>
          <!-- DE here is what triggers the German National Ruleset -->
          <cbc:IdentificationCode>DE</cbc:IdentificationCode>
        </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
        <cbc:CompanyID>DE123456789</cbc:CompanyID>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
        <cbc:RegistrationName>Müller Technik GmbH</cbc:RegistrationName>
      </cac:PartyLegalEntity>
      <!-- BG-6: Seller contact (mandatory in Germany per DE-R-002) -->
      <cac:Contact>
        <cbc:Name>Anna Bauer</cbc:Name>
        <cbc:Telephone>+49 30 12345678</cbc:Telephone>
        <cbc:ElectronicMail>anna.bauer@muller-technik.de</cbc:ElectronicMail>
      </cac:Contact>
    </cac:Party>
  </cac:AccountingSupplierParty>

  <!-- Buyer Party -->
<cac:AccountingCustomerParty>

    <cac:Party>

      <!-- BT-49: Buyer electronic address. Mandatory, used for Peppol routing. Scheme 0204 = Leitweg-ID (DE:LWID). For public bodies this is the same Leitweg-ID value used in the buyer reference (BT-10) -->

      <cbc:EndpointID schemeID="0204">04011000-12345-67</cbc:EndpointID>

      <cac:PostalAddress>

        <cbc:StreetName>Scharnhorststrasse 34-37</cbc:StreetName>

        <cbc:CityName>Berlin</cbc:CityName>

        <cbc:PostalZone>10115</cbc:PostalZone>

        <cac:Country>

          <cbc:IdentificationCode>DE</cbc:IdentificationCode>

        </cac:Country>

      </cac:PostalAddress>

      <!-- BT-44: Buyer name. Mandatory, belongs in PartyLegalEntity -->

      <cac:PartyLegalEntity>

        <cbc:RegistrationName>Bundesministerium für Wirtschaft und Klimaschutz</cbc:RegistrationName>

      </cac:PartyLegalEntity>

    </cac:Party>

  </cac:AccountingCustomerParty>

  <!-- BG-16: Payment instructions (mandatory in Germany per DE-R-001) -->
  <cac:PaymentMeans>
    <!-- BT-81: 30 = Credit Transfer. There is no German rule restricting BT-81 to a fixed set of codes. DE-R-020 only requires a valid IBAN in BT-91 when SEPA direct debit (59) is used -->
    <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
    <cac:PayeeFinancialAccount>
      <cbc:ID>DE89370400440532013000</cbc:ID>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>

<!-- BT-20: Payment terms. If Skonto applies, Note must follow DE-R-018 format: #SKONTO#TAGE=N#PROZENT=N.NN# -->
  <cac:PaymentTerms>
    <cbc:Note>30 days net</cbc:Note>
  </cac:PaymentTerms>

  <!-- VAT Total -->
  <cac:TaxTotal>
    <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
    <cac:TaxSubtotal>
      <cbc:TaxableAmount currencyID="EUR">1000.00</cbc:TaxableAmount>
      <cbc:TaxAmount currencyID="EUR">190.00</cbc:TaxAmount>
      <cac:TaxCategory>
        <cbc:ID>S</cbc:ID>          <!-- S = Standard VAT rate -->
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:TaxCategory>
    </cac:TaxSubtotal>
  </cac:TaxTotal>

  <!-- Invoice Totals -->
  <cac:LegalMonetaryTotal>
    <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
    <cbc:TaxExclusiveAmount currencyID="EUR">1000.00</cbc:TaxExclusiveAmount>
    <cbc:TaxInclusiveAmount currencyID="EUR">1190.00</cbc:TaxInclusiveAmount>
    <cbc:PayableAmount currencyID="EUR">1190.00</cbc:PayableAmount>
  </cac:LegalMonetaryTotal>

  <!-- Invoice Line -->
  <cac:InvoiceLine>
    <cbc:ID>1</cbc:ID>
    <cbc:InvoicedQuantity unitCode="C62">10</cbc:InvoicedQuantity>
    <cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
    <cac:Item>
      <cbc:Description>Industrial sensor units, Type A</cbc:Description>
      <cbc:Name>Sensor Unit Type A</cbc:Name>
      <cac:ClassifiedTaxCategory>
        <cbc:ID>S</cbc:ID>
        <cbc:Percent>19</cbc:Percent>
        <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
      </cac:ClassifiedTaxCategory>
    </cac:Item>
    <cac:Price>
      <cbc:PriceAmount currencyID="EUR">100.00</cbc:PriceAmount>
    </cac:Price>
  </cac:InvoiceLine>

</ubl:Invoice>

A few things to note from this Peppol BIS Billing 3.0 example:

1. The Customisation ID is fixed. Do not modify it. It tells the receiving system the exact ruleset version in use.
2. The Buyer Reference (BT-10) is the reference the buyer provides, and you should ask for it before you invoice. Under DE-R-015 this field is fatal, so leaving it blank causes rejection. For federal and other public sector buyers this is normally the Leitweg-ID in its defined format, for example 04011000-12345-67, rather than a free-text purchase reference. The value shown here is illustrative only. 
3. The country code DE in both address blocks is what triggers the German National Ruleset (DE-R rules) during validation.
4. The VAT rate is 19%, Germany's standard rate. For reduced-rate items (7%), change the Percent value. The TaxCategory ID remains the same.
5. The unit Code C62 means 'units' (each). Change it to match the correct UN/ECE Recommendation 20 code for your goods or services.

XRechnung vs Peppol BIS 3.0

Both are CIUS (Core Invoice Usage Specification) standards derived from EN 16931. Both are accepted for German B2G invoicing. XRechnung is Germany’s national CIUS. Peppol BIS 3.0 is OpenPeppol’s European CIUS. Before February 2025, they had separate business rules and coexisted on the Peppol network as distinct document types. 

After Peppol BIS 3.0.18 went live, XRechnung rules were included in Peppol BIS 3.0 as the German National Ruleset. Inside Germany’s Peppol network and using UBL 2.1 syntax, they're the same thing now.

The critical practical point: If you want to invoice both German public authorities and European partners using the Peppol network, use Peppol BIS 3.0. One format, one integration, works everywhere. XRechnung is relevant only for Germany-domestic scenarios, particularly when transmitting outside the Peppol network, such as via email or upload portals like Bund.de or OZG-compliant portals.

One subtlety that catches people out. XRechnung has an extension that goes beyond EN 16931. That extension is not supported in Peppol BIS 3.0. If your business uses those extended fields, you cannot simply switch to Peppol BIS 3.0 and expect the same output. Check your invoice content before making any format decisions.

Conclusion

Peppol BIS 3.0 serves as a standardised ruleset that ensures consistent invoice fields across international borders. With the integration of German national rules as of February 2025, the standard has become even more robust for local requirements. To ensure successful implementation, organisations must verify the Customisation ID, secure the necessary BuyerReference, and apply the correct country code (DE) for German entities. 

It is essential to perform comprehensive schematron validations before transmission, as CII-syntax XRechnung files are not interchangeable with Peppol BIS 3.0. Ultimately, while the format itself is straightforward, maintaining strict validation discipline and accurate identification remains the critical success factor for compliant electronic invoicing.