# PEPPOL-EN16931-P0112: Keep invoice type codes 326 and 384 for invoices between two German parties
Peppol accepts `326` (partial invoice) and `384` (corrected invoice) only when the seller and the buyer both have a postal address in Germany.
- Layer: Peppol BIS Billing
- Severity: fatal (the document is invalid)
- Topics: Code lists, Parties and addresses
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-P0112/
- Explanation last updated: 2026-09-28
## 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).
| Term | Meaning | UBL element |
|---|---|---|
| BT-3 | Invoice type code | `cbc:InvoiceTypeCode` |
| BT-40 | Seller country code | `cac:AccountingSupplierParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode` |
| BT-55 | Buyer country code | `cac:AccountingCustomerParty/cac:Party/cac:PostalAddress/cac:Country/cbc:IdentificationCode` |
## 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`.
## 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
```xml
384
1 Example Street
London
SW1A 1AA
GB
2 Example Street
London
SW1A 2AA
GB
```
Fragment of the corrected invoice: type code 380 for the same two parties
```xml
380
1 Example Street
London
SW1A 1AA
GB
2 Example Street
London
SW1A 2AA
GB
```
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.
### What the validator reported
- The failing invoice reports **PEPPOL-EN16931-P0112**. The corrected document passes every layer with no findings.
- [Download the failing XML](https://ironfang.com/finance/rule-examples/PEPPOL-EN16931-P0112-invalid.xml)
- [Download the corrected XML](https://ironfang.com/finance/rule-examples/invoice-minimal.xml)
Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.
## 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](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-P0100.md)
- [BR-CL-01 accepts 326 and 384 for any parties on the EN 16931 layer](https://ironfang.com/docs/finance/rules/BR-CL-01.md)
- [BR-CL-14 checks the postal address country codes that decide whether both parties are German](https://ironfang.com/docs/finance/rules/BR-CL-14.md)
- [PEPPOL-EN16931-P0101 keeps credit notes to their own list of type codes](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-P0101.md)
## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/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.
## Links
- [This rule as a web page](https://ironfang.com/docs/finance/rules/PEPPOL-EN16931-P0112)
- [Free Peppol invoice validator](https://ironfang.com/tools/peppol-validator)
- [Rule index](https://ironfang.com/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.com/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.com/mcp