PEPPOL-EN16931-P0112: Keep invoice type codes 326 and 384 for invoices between two German parties

The short answer

PEPPOL-EN16931-P0112 fails when cbc:InvoiceTypeCode is 326 or 384 and the seller and the buyer are not both in Germany. Both codes are on the Peppol invoice type list, but this rule keeps them for domestic German invoices. Between any other parties, send an ordinary invoice, 380, and correct an earlier invoice with a credit note rather than with a corrected invoice.

Germany is decided by postal address alone. The rule reads the country code in the seller postal address and in the buyer postal address, trimmed and upper-cased, and both must be DE. VAT identifiers, a tax representative and the delivery address play no part.

What the rule checks

The rule runs on cbc:InvoiceTypeCode, trims it, and fails for 326 or 384 unless both postal address country codes are DE. Any other code is left to PEPPOL-EN16931-P0100; when tried, 326 with spaces around it was still reported here.

One German party is not enough. When tried, 384 with the seller address moved to Berlin and the buyer left in London failed, and so did a seller in London with the VAT identifier DE123456789 selling to a buyer in Munich.

The reverse holds as well: with both postal addresses in Germany, 384 passed this rule when tried although the seller VAT identifier began with GB.

Lower case counts as German here, because the country code is upper-cased first. When tried, de in both addresses cleared this rule, while BR-CL-14 rejected both codes.

Two German addresses also switch on the German national rules, which use the same test. When tried, the recorded example moved to Berlin and Munich with 384 passed this rule and drew DE-R-001 (payment instructions), DE-R-002 (seller contact) and the warning DE-R-026 (a reference to the invoice being corrected).

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

• An integration built for German customers, where both codes are in use, is reused for customers in other countries.
• Corrections are sent as a new invoice coded 384 instead of a credit note followed, if still needed, by a new invoice.
• Instalment or progress billing is coded 326, partial invoice, for customers outside Germany.
• The parties are German in the business system, but an address written to the invoice is not, for example a head office abroad.

How to fix it

1. Look at the country codes the invoice actually carries in both cac:PostalAddress groups. If both parties are in Germany and an address says otherwise, correct the address.
2. Otherwise choose another type code. A partial or instalment invoice can go as 380, commercial invoice. For a correction, send a credit note, 381, against the original and then a new invoice if an amount is still owed.
3. Refer to the invoice being corrected in cac:BillingReference/cac:InvoiceDocumentReference, on the credit note or on the new invoice.
4. If both parties are in Germany and you keep 326 or 384, meet the German national rules as well. When tried, the example in Berlin and Munich passed every layer once it had a payment means, a seller contact and a cac:BillingReference.

Validate your corrected invoice

Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the failing invoice: type code 384 between a seller and a buyer in the United Kingdom

<cbc:InvoiceTypeCode>384</cbc:InvoiceTypeCode>
<!-- currency and buyer reference omitted from this fragment -->
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- electronic address omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 1AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
  <cac:Party>
    <!-- electronic address omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>2 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 2AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

Fragment of the corrected invoice: type code 380 for the same two parties

<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<!-- currency and buyer reference omitted from this fragment -->
<cac:AccountingSupplierParty>
  <cac:Party>
    <!-- electronic address omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>1 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 1AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- tax scheme and legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
  <cac:Party>
    <!-- electronic address omitted from this fragment -->
    <cac:PostalAddress>
      <cbc:StreetName>2 Example Street</cbc:StreetName>
      <cbc:CityName>London</cbc:CityName>
      <cbc:PostalZone>SW1A 2AA</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

Only cbc:InvoiceTypeCode differs: 384 in the failing invoice, 380 in the corrected one, with both parties still in GB. The failing document reports this rule alone; BR-CL-01 and PEPPOL-EN16931-P0100 pass, because 384 is on both of their lists. Recoding suits this example, which is an ordinary invoice; a real correction outside Germany goes through a credit note.

Where it applies

• Applies to UBL Invoice only, since the rule reads cbc:InvoiceTypeCode. A credit note cannot use 384 at all: when tried, a cbc:CreditNoteTypeCode of 384 was rejected by BR-CL-01 and PEPPOL-EN16931-P0101.
• Reported on the Peppol layer. EN 16931 has no such condition, and both codes pass BR-CL-01 whoever the parties are.
• The test for a German invoice is the one the German national rules use to switch themselves on, so an invoice that passes this rule with 326 or 384 is always checked by those rules too.

Related rules

• PEPPOL-EN16931-P0100 checks the invoice type code against the Peppol list before this rule narrows two of its codes
• BR-CL-01 accepts 326 and 384 for any parties on the EN 16931 layer
• BR-CL-14 checks the postal address country codes that decide whether both parties are German
• PEPPOL-EN16931-P0101 keeps credit notes to their own list of type codes
• Browse every rule in the reference
• Background: How Peppol invoice validation actually works

Scope and source

Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-28.1: source checked 2026-09-28, explanation last updated 2026-09-28.

The official definition of PEPPOL-EN16931-P0112 carries the normative wording and test. This page is our explanation of it, not a copy.

Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.