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

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.

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.

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

<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

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

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
• BR-CL-16 checks that the payment means code comes from the UNCL 4461 list
• NL-R-003 is the Dutch rule for the seller legal entity identifier, triggered by the same address
• 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-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.