# NL-R-007: Add payment means when a Dutch supplier is owed money

A seller in the Netherlands must include `cac:PaymentMeans` whenever the buyer has something to pay: an invoice due above zero or a credit note due below it.

- 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/NL-R-007/
- Explanation last updated: 2026-09-24

## The short answer

`NL-R-007` fails when the seller postal address is in the Netherlands, the buyer has money to pay, and the document has no `cac:PaymentMeans`. Add a `cac:PaymentMeans` block that tells the buyer how to pay, such as credit transfer code `30` with the seller account in `cac:PayeeFinancialAccount/cbc:ID`.

Payment terms are no substitute. When tried, replacing the payment means with a `cac:PaymentTerms` note still reported the rule.

## What the rule checks

The rule is evaluated at `cac:LegalMonetaryTotal` in a document whose seller postal address country code is `NL`, and it reads `cbc:PayableAmount` to decide whether money flows from buyer to seller.

For an `Invoice`, an amount due of zero or less needs no payment means. When tried, an invoice fully covered by its prepaid amount, and one with -10.00 due, both passed without any.

For a `CreditNote` the sign is reversed: zero or more needs none, because the refund goes to the buyer, while a negative amount due means the buyer still owes money. When tried, a Dutch credit note with -10.00 due and no payment means reported this rule.

Any `cac:PaymentMeans` satisfies it, whatever its code. When tried, a block holding only `cbc:PaymentMeansCode` `1` passed; other rules then judge the content, such as `BR-61`, which wants an account identifier for credit transfer codes `30` and `58`.

| Term | Meaning | UBL element |
|---|---|---|
| BG-16 | Payment instructions | `cac:PaymentMeans` |
| BT-81 | Payment means type code | `cac:PaymentMeans/cbc:PaymentMeansCode` |
| BT-115 | Amount due for payment | `cac:LegalMonetaryTotal/cbc:PayableAmount` |
| 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:

- Bank details are printed on the PDF from the company letterhead and never mapped into the XML.
- The export adds `cac:PaymentMeans` only for customers set up with a payment method, and the buyer on this invoice has none.
- The same export serves sellers in other countries, where the validator accepts an invoice without payment means, and nothing adds it for the Dutch entity.
- A credit note that leaves the buyer owing money is built from the credit note template, which has no payment means.

## How to fix it

1. Decide how the buyer is to pay this document, from the seller payment set-up: bank transfer, direct debit, card or another method.
2. Add `cac:PaymentMeans` with the matching `cbc:PaymentMeansCode`. For a bank transfer use `30` or `58` and give the seller IBAN in `cac:PayeeFinancialAccount/cbc:ID`.
3. Place it after the parties and any delivery details, and before `cac:PaymentTerms`, any document-level `cac:AllowanceCharge` and `cac:TaxTotal`, as the UBL sequence requires.
4. When the buyer is in the Netherlands too, keep to the codes `NL-R-008` allows: 30, 48, 49, 57, 58 and 59.
5. Hold the account details on the Dutch legal entity, not on each customer, so every document it issues can include them.

## 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 Dutch seller, 30.00 due and no payment means

```xml
<cac:AccountingSupplierParty>
  <!-- seller party with a postal address in NL omitted from this fragment -->
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
  <!-- buyer party omitted from this fragment -->
</cac:AccountingCustomerParty>
<cac:TaxTotal>
  <!-- VAT total and breakdown omitted from this fragment -->
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
  <!-- line, VAT and prepaid totals omitted from this fragment -->
  <cbc:PayableAmount currencyID="GBP">30.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
```

Fragment of the corrected invoice: a credit transfer to the seller account, placed before the tax total

```xml
<cac:AccountingSupplierParty>
  <!-- seller party with a postal address in NL omitted from this fragment -->
</cac:AccountingSupplierParty>
<cac:AccountingCustomerParty>
  <!-- buyer party omitted from this fragment -->
</cac:AccountingCustomerParty>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>NL00EXAM0000000001</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:TaxTotal>
  <!-- VAT total and breakdown omitted from this fragment -->
</cac:TaxTotal>
<cac:LegalMonetaryTotal>
  <!-- line, VAT and prepaid totals omitted from this fragment -->
  <cbc:PayableAmount currencyID="GBP">30.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>
```

The corrected invoice adds `cac:PaymentMeans` with code `30` and the account `NL00EXAM0000000001`; nothing else differs. `NL-R-007` is the only finding, reported at `cac:LegalMonetaryTotal` because the amount due there is what brings the rule into play. EN 16931 does not require payment instructions, so that layer passes. The account number is synthetic; a real invoice carries the IBAN of the seller.

### What the validator reported

- The failing invoice reports **NL-R-007**. The corrected document passes every layer with no findings.
  - [Download the failing XML](https://ironfang.uk/finance/rule-examples/NL-R-007-invalid.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/netherlands-supplier-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 `Invoice` and `CreditNote`, with the sign of `cbc:PayableAmount` read the opposite way for each.
- The rule belongs to the Dutch national section of Peppol BIS Billing 3.0 and appears in the Peppol layer. When tried, the same invoice with a GB seller address and no payment means passed.
- For a buyer in the Netherlands as well, `NL-R-008` restricts the payment means code; when tried, code `1` reported it.
- The content of the payment means is checked by EN 16931 rules such as `BR-61`, for the account of a credit transfer, and `BR-CL-16`, for the code list.

## Related rules

- [BR-61 requires the payee account when the payment means you add is a credit transfer](https://ironfang.uk/docs/finance/rules/BR-61.md)
- [BR-CL-16 checks that the payment means code comes from the UNCL 4461 list](https://ironfang.uk/docs/finance/rules/BR-CL-16.md)
- [NL-R-003 is the Dutch rule for the seller legal entity identifier, triggered by the same address](https://ironfang.uk/docs/finance/rules/NL-R-003.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-007](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/NL-R-007/) 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-007)
- [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