NL-R-007 : Ajouter un moyen de paiement lorsqu'un fournisseur néerlandais doit être payé

La réponse courte

NL-R-007 échoue lorsque l'adresse postale du vendeur est aux Pays-Bas, que l'acheteur a de l'argent à payer et que le document n'a pas de cac:PaymentMeans. Ajoutez un bloc cac:PaymentMeans qui indique à l'acheteur comment payer, par exemple le code de virement 30 avec le compte du vendeur dans cac:PayeeFinancialAccount/cbc:ID.

Les conditions de paiement ne le remplacent pas. Lors d'un essai, remplacer le moyen de paiement par une mention dans cac:PaymentTerms a toujours signalé la règle.

Ce que la règle vérifie

La règle est évaluée sur cac:LegalMonetaryTotal dans un document dont le code de pays de l'adresse postale du vendeur est NL, et elle lit cbc:PayableAmount pour décider si de l'argent va de l'acheteur au vendeur.

Pour une Invoice, un montant à payer nul ou négatif n'exige aucun moyen de paiement. Lors d'un essai, une facture entièrement couverte par son montant payé d'avance, et une autre avec -10.00 à payer, ont toutes deux réussi sans moyen de paiement.

Pour un CreditNote, le signe est inversé : zéro ou plus n'en exige aucun, car le remboursement va à l'acheteur, tandis qu'un montant à payer négatif signifie que l'acheteur doit encore de l'argent. Lors d'un essai, un avoir néerlandais avec -10.00 à payer et sans moyen de paiement a signalé cette règle.

Tout cac:PaymentMeans la satisfait, quel que soit son code. Lors d'un essai, un bloc ne contenant que cbc:PaymentMeansCode 1 a réussi ; d'autres règles jugent ensuite le contenu, comme BR-61, qui exige un identifiant de compte pour les codes de virement 30 et 58.

Comment une intégration en arrive là

Causes possibles, déduites de la forme de la règle et non d'une utilisation mesurée :

• Les coordonnées bancaires sont imprimées sur le PDF à partir de l'en-tête de l'entreprise et ne sont jamais reportées dans le XML.
• L'export n'ajoute cac:PaymentMeans que pour les clients configurés avec un mode de paiement, et l'acheteur de cette facture n'en a pas.
• Le même export sert des vendeurs d'autres pays, où le validateur accepte une facture sans moyen de paiement, et rien ne l'ajoute pour l'entité néerlandaise.
• Un avoir qui laisse l'acheteur redevable est construit à partir du modèle d'avoir, qui n'a pas de moyen de paiement.

Comment corriger le document

1. Déterminez comment l'acheteur doit payer ce document, d'après la configuration de paiement du vendeur : virement, prélèvement, carte ou autre moyen.
2. Ajoutez cac:PaymentMeans avec le cbc:PaymentMeansCode correspondant. Pour un virement, utilisez 30 ou 58 et indiquez l'IBAN du vendeur dans cac:PayeeFinancialAccount/cbc:ID.
3. Placez-le après les parties et les éventuelles informations de livraison, et avant cac:PaymentTerms, tout cac:AllowanceCharge au niveau du document et cac:TaxTotal, comme l'exige l'ordre UBL.
4. Lorsque l'acheteur est aussi aux Pays-Bas, tenez-vous aux codes que NL-R-008 autorise : 30, 48, 49, 57, 58 et 59.
5. Conservez les coordonnées du compte au niveau de l'entité juridique néerlandaise, pas de chaque client, afin que chaque document qu'elle émet puisse les inclure.

Valider votre facture corrigée

Avant et après

Ce sont des extraits, pas des documents complets. Les documents synthétiques complets dont ils proviennent sont liés ci-dessous.

Fragment de la facture en échec : un vendeur néerlandais, 30.00 à payer et aucun moyen de paiement

<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 de la facture corrigée : un virement sur le compte du vendeur, placé avant le total de taxe

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

La facture corrigée ajoute cac:PaymentMeans avec le code 30 et le compte NL00EXAM0000000001 ; rien d'autre ne diffère. NL-R-007 est le seul constat, signalé sur cac:LegalMonetaryTotal, car c'est le montant à payer qui s'y trouve qui déclenche la règle. EN 16931 n'exige pas d'instructions de paiement, cette étape réussit donc. Le numéro de compte est synthétique ; une vraie facture porte l'IBAN du vendeur.

Où la règle s'applique

• S'applique à Invoice et à CreditNote, le signe de cbc:PayableAmount étant lu en sens inverse pour chacun.
• La règle appartient à la section nationale néerlandaise de Peppol BIS Billing 3.0 et apparaît dans l'étape Peppol. Lors d'un essai, la même facture avec une adresse du vendeur GB et sans moyen de paiement a réussi.
• Pour un acheteur également aux Pays-Bas, NL-R-008 restreint le code du moyen de paiement ; lors d'un essai, le code 1 l'a signalée.
• Le contenu du moyen de paiement est contrôlé par des règles EN 16931 comme BR-61, pour le compte d'un virement, et BR-CL-16, pour la liste de codes.

Règles liées

• BR-61 exige le compte du bénéficiaire lorsque le moyen de paiement ajouté est un virement
• BR-CL-16 vérifie que le code du moyen de paiement provient de la liste UNCL 4461
• NL-R-003 est la règle néerlandaise sur l'identifiant de l'entité juridique du vendeur, déclenchée par la même adresse
• Parcourir toutes les règles de la référence
• Contexte (en anglais) : How Peppol invoice validation actually works

Portée et source

Rédigé pour Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, tel qu'appliqué aux documents Invoice et CreditNote en UBL 2.1. D'autres profils, syntaxes et versions peuvent définir cet identifiant autrement. Version du catalogue d'aide 2026-09-24.1 : source vérifiée le 2026-09-24, explication mise à jour le 2026-09-24.

La définition officielle de NL-R-007 (en anglais) contient le texte normatif et le test. Cette page en est notre explication, pas une copie.

Cette aide ne modifie pas le verdict du moteur. Corriger ce constat ne signifie pas que le document passe toutes les étapes de validation, et la validation ne certifie pas la conformité juridique ou fiscale et ne transmet aucun document via Peppol.