# PEPPOL-EN16931-R002: Keep to one document-level note

Peppol allows one `cbc:Note` directly under the root unless seller and buyer both have German postal addresses. Merge the texts into one note.

- Layer: Peppol BIS Billing
- Severity: fatal (the document is invalid)
- Topics: Core fields
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-R002/
- Explanation last updated: 2026-09-24

## The short answer

`PEPPOL-EN16931-R002` fails when the `Invoice` or `CreditNote` root has two or more `cbc:Note` children and the seller and buyer are not both in Germany. Combine the texts into a single `cbc:Note`, or move each piece of information to the element that exists for it.

EN 16931 itself allows several invoice notes, which is why the EN 16931 layer passes. The limit is a Peppol restriction.

## What the rule checks

The rule counts only `cbc:Note` elements that are direct children of the root. Notes on lines, in payment terms or elsewhere are not counted: the corrected invoice has a line note and a payment terms note beside its one document note, and passes.

Empty notes count. An empty second note was reported by this rule and by `PEPPOL-EN16931-R008` when tried.

The exception needs the postal address country code of both parties to be `DE`. With only the seller, or only the buyer, set to `DE`, the rule still failed when tried. The VAT identifier prefix is not consulted.

There is one finding per document, at the root, however many notes there are; three notes gave a single finding when tried.

| Term | Meaning | UBL element |
|---|---|---|
| BT-22 | Invoice note | `cbc:Note` |
| 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:

- Each remark field in the source system, such as a delivery instruction, legal wording or a free comment, is written as its own `cbc:Note`.
- Payment instructions or bank details are sent as an extra note instead of in `cac:PaymentTerms` or `cac:PaymentMeans`.
- A mapping built for German domestic invoices, where several notes are allowed, is reused for other countries.
- A template adds a fixed note, and the export appends the user's comment as a second one.

## How to fix it

1. Collect everything that belongs in the document-level note and write it as one `cbc:Note`, with the parts separated by a line break or punctuation.
2. Move text that has its own home: payment terms to `cac:PaymentTerms/cbc:Note`, a remark about one line to that line's `cbc:Note`, and bank or remittance details to `cac:PaymentMeans`.
3. Drop notes that carry nothing, including empty ones.
4. Send several notes only when both parties' postal addresses really are in Germany; never change an address to reach the exception.

## Before and after

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

Fragment of the failing invoice: a second document-level note follows the first

```xml
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<!-- first document-level cbc:Note omitted from this fragment -->
<cbc:Note>Second example note</cbc:Note>
<cbc:TaxPointDate>2026-09-07</cbc:TaxPointDate>
```

Fragment of the corrected invoice: only the first note remains

```xml
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
<!-- the single document-level cbc:Note omitted from this fragment -->
<cbc:TaxPointDate>2026-09-07</cbc:TaxPointDate>
```

The failing invoice has a second `cbc:Note`, `Second example note`, after the first; the corrected invoice keeps the first note only. The failing document reports only `PEPPOL-EN16931-R002`. Both parties in the example have British postal addresses, so the German exception does not apply.

### What the validator reported

- The failing invoice reports **PEPPOL-EN16931-R002**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/PEPPOL-EN16931-R002-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/invoice-rich.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` and `CreditNote` alike; a credit note with two notes reported this rule when tried.
- When both postal countries were set to `DE`, this rule cleared and the Peppol German national rules asked for the delivery city and post code instead. Documents between German parties have their own set of requirements.
- Line notes have a separate limit: a second `cbc:Note` on one line is reported by `UBL-SR-34`, not by this rule.
- Document notes sit after the type code and before `cbc:TaxPointDate` and `cbc:DocumentCurrencyCode`. A note placed after `cbc:TaxPointDate` failed the XSD layer when tried.

## Related rules

- [PEPPOL-EN16931-R008 is also reported when one of the notes is empty](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)
- [BR-CL-14 checks the postal country codes that decide whether the German exception applies](https://ironfang.uk/docs/finance/rules/BR-CL-14.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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

[The official definition of PEPPOL-EN16931-R002](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-EN16931-R002/) 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.uk/docs/finance/rules/PEPPOL-EN16931-R002)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp