NL-R-007:Dutch supplier must include payment instructions
Your invoice is from a Dutch supplier and has a positive amount due, but it does not include payment instructions. Dutch e-invoicing rules require that when a customer needs to pay you, your invoice must tell them how. You need to specify the payment method (for example, bank transfer or SEPA) and include your bank account details so the customer can pay.
Engine Classification
Business data required · Explicit input workflow · No assumptions made
Required input: Payment method, IBAN, Payment reference (optional)
What is NL-R-007?
NL-R-007 is a fatal validation rule defined in the NLCIUS (Netherlands) specification (NLD national rules). It validates the PaymentMeansCode — NLCIUS rule NL-R-007. For suppliers in the Netherlands, the supplier MUST provide a means of payment (cac:PaymentMeans with a valid PaymentMeansCode from UNCL 4461) if the payment is from customer to supplier. The rule only fires when the seller country is NL and the PayableAmount is greater than zero. For credit notes where the payable amount is zero or negative, payment means is not required. element in the UBL invoice XML.
When this rule fires, the invoice is non-compliant and will be rejected by Peppol access points and national validation services. The sending system receives a rejection response and the invoice does not reach the buyer.
Target path: XPath: cac:PaymentMeans/cbc:PaymentMeansCode — NLCIUS rule NL-R-007. For suppliers in the Netherlands, the supplier MUST provide a means of payment (cac:PaymentMeans with a valid PaymentMeansCode from UNCL 4461) if the payment is from customer to supplier. The rule only fires when the seller country is NL and the PayableAmount is greater than zero. For credit notes where the payable amount is zero or negative, payment means is not required.
Why This Error Matters
Invoice will be rejected by Dutch validation. Payment means is required for Dutch invoices.
NL-R-007 is a hard failure. Invoices that trigger this rule are rejected at the access point and never reach the recipient. In Peppol networks, this means your sending system receives an MLR (Message Level Response) with a rejection status. The invoice must be corrected and re-sent, adding delay to your payment cycle.
Validator Behavior
- ·Causes invoice rejection
- ·Error returned: NL-R-007
- ·Specification: NLCIUS (Netherlands)
How to Fix It
Choose your payment method
Select how your customer should pay. Most Dutch companies use SEPA credit transfer (code 58) or standard bank transfer (code 30). If you use automatic collection (incasso), choose direct debit (code 49).
Enter your IBAN
Provide the IBAN of the bank account where you want to receive payment. For Dutch accounts this starts with NL (e.g., NL91ABNA0417164300).
Optionally add a payment reference
If you want your customer to include a specific reference when paying (e.g., invoice number), add it as the PaymentID. This helps match incoming payments to invoices.
Re-validate
After adding payment means, re-validate the invoice to confirm the error is resolved.
Before / After
<Invoice> <!-- Issue: For suppliers in the Netherlands, the supplier MUST provide --> </Invoice>
<Invoice> <!-- Issue resolved per NLCIUS (Netherlands) --> </Invoice>
Technical Reference
XPath: cac:PaymentMeans/cbc:PaymentMeansCode — NLCIUS rule NL-R-007. For suppliers in the Netherlands, the supplier MUST provide a means of payment (cac:PaymentMeans with a valid PaymentMeansCode from UNCL 4461) if the payment is from customer to supplier. The rule only fires when the seller country is NL and the PayableAmount is greater than zero. For credit notes where the payable amount is zero or negative, payment means is not required.Common Causes
- ·Invoicing software does not export the PaymentMeans element for e-invoices
- ·Bank account details are stored in a separate system and not included in the invoice export
- ·Credit note template was used for a regular invoice (credit notes do not require payment means)
- ·Invoice was created manually without the payment section
Seeing this in production? The API handles NL-R-007 automatically. See the fix response →
Commonly Seen In
Related Errors
Last updated: 27 February 2026
Handle NL-R-007 Automatically in Your Pipeline
The compliance engine auto-remediates this error with controlled safety policies and evidence pack generation.