NL-R-001: Reference the corrected invoice on a credit note from a Dutch supplier

The short answer

NL-R-001 fails when a UBL CreditNote from a seller whose postal address is in the Netherlands has no cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID. Add the billing reference with the number of the invoice that the credit note corrects.

The finding is reported at cbc:CreditNoteTypeCode, because that is the element the rule is attached to. What is missing is the billing reference.

What the rule checks

The rule applies only to CreditNote documents, and only when the seller postal address country code is NL. The VAT number prefix plays no part: when tried, the Dutch credit note with a GB VAT number still reported the rule, and with a GB postal address and an NL VAT number it passed.

It then looks for a cbc:ID inside cac:InvoiceDocumentReference in a document-level cac:BillingReference. An order reference does not count, and neither does a cac:SelfBilledInvoiceDocumentReference; when tried, both still reported NL-R-001.

Presence is all it asks for. An empty cbc:ID in that position satisfies this rule, but when tried it was reported by PEPPOL-EN16931-R008 instead.

An Invoice is never checked, whatever its type code. A credit note sent as an Invoice with type code 381 is rejected anyway: when tried, it reported BR-CL-01 and PEPPOL-EN16931-P0100.

How an integration ends up here

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

• Credit notes are raised as free-standing refunds or goodwill credits, with no link to an original invoice in the source.
• The link to the original invoice exists in the source but is mapped only to a note or to cac:OrderReference.
• A system serving several legal entities writes the billing reference only where it has been configured, and the Dutch entity was never set up for it.

How to fix it

1. Find the invoice the credit note corrects in the source system. If the credit relates to several invoices, give each one its own cac:BillingReference.
2. Write its number, exactly as issued, to cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID, with its issue date in cbc:IssueDate beside it.
3. Place cac:BillingReference after cbc:BuyerReference and any cac:OrderReference, and before the other document references and the parties, as the UBL sequence requires.
4. If the credit has no underlying invoice in your records, settle in the source which invoice it belongs to. A made-up number would pass the check and mislead the buyer.

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 credit note: a seller in the Netherlands and no billing reference

<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>BUYER-REF-001</cbc:BuyerReference>
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <!-- street, city and postcode omitted from this fragment -->
      <cac:Country>
        <cbc:IdentificationCode>NL</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- VAT and legal entity details omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

Fragment of the corrected credit note: the billing reference names the invoice being credited

<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
<cbc:DocumentCurrencyCode>GBP</cbc:DocumentCurrencyCode>
<cbc:BuyerReference>BUYER-REF-001</cbc:BuyerReference>
<cac:BillingReference>
  <cac:InvoiceDocumentReference>
    <cbc:ID>EXAMPLE-INV-001</cbc:ID>
    <cbc:IssueDate>2026-09-08</cbc:IssueDate>
  </cac:InvoiceDocumentReference>
</cac:BillingReference>
<cac:AccountingSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <!-- street, city and postcode omitted from this fragment -->
      <cac:Country>
        <cbc:IdentificationCode>NL</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <!-- VAT and legal entity details omitted from this fragment -->
  </cac:Party>
</cac:AccountingSupplierParty>

The corrected credit note has a cac:BillingReference naming invoice EXAMPLE-INV-001 of 2026-09-08; the failing one has none. NL-R-001 is its only finding: with no billing reference at all there is nothing for BR-55 to examine, and the EN 16931 layer passes.

Where it applies

• Applies to UBL CreditNote only. An Invoice from a Dutch seller is not checked by this rule.
• A Dutch national rule in Peppol BIS Billing 3.0, reported in the Peppol layer. Whether it applies depends only on the seller postal address being in the Netherlands.
• The same Dutch seller must also meet NL-R-003 for its legal entity identifier and NL-R-007 for payment means when the buyer has money to pay.
• Once a billing reference is present, EN 16931 checks it too: BR-55 rejects one that lacks the invoice number.

Related rules

• BR-55 rejects a billing reference that is present but has no invoice number
• NL-R-003 is the Dutch rule for the seller legal entity identifier on the same documents
• NL-R-007 is the Dutch rule that requires payment means when the buyer has to pay
• 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 NL-R-001 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.