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

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.

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.

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: a second document-level note follows the first

<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

<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.

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
• BR-CL-14 checks the postal country codes that decide whether the German exception applies
• 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-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of 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.