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

When the seller address is in the Netherlands, a credit note must carry the number of the invoice it corrects in `cac:BillingReference`.

- Layer: Peppol BIS Billing
- Severity: fatal (the document is invalid)
- Topics: Process and references
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/NL-R-001/
- Explanation last updated: 2026-09-24

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

| Term | Meaning | UBL element |
|---|---|---|
| BT-3 | Invoice type code | `cbc:CreditNoteTypeCode` |
| BT-25 | Preceding Invoice reference | `cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID` |
| BT-40 | Seller country code | `cac:AccountingSupplierParty/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:

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

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

```xml
<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

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

### What the validator reported

- The failing credit note reports **NL-R-001**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/NL-R-001-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/netherlands-supplier-credit-note-valid.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 `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](https://ironfang.uk/docs/finance/rules/BR-55.md)
- [NL-R-003 is the Dutch rule for the seller legal entity identifier on the same documents](https://ironfang.uk/docs/finance/rules/NL-R-003.md)
- [NL-R-007 is the Dutch rule that requires payment means when the buyer has to pay](https://ironfang.uk/docs/finance/rules/NL-R-007.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 NL-R-001](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/NL-R-001)
- [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