Aller au contenu

Ironfang Finance - Référence des règles

BR-CL-16 : Utiliser un code de moyen de paiement UNTDID 4461

cbc:PaymentMeansCode doit être un code UNTDID 4461, comme 30 pour un virement ou 49 pour un prélèvement, et non un nom de système bancaire ou de produit.

EN 16931Erreur : le document n'est pas valideListes de codes

Sur cette page

La réponse courte

BR-CL-16 échoue lorsque cac:PaymentMeans/cbc:PaymentMeansCode contient autre chose qu'un code UNTDID 4461. Remplacez-le par le code correspondant à la façon dont l'acheteur va payer : 30 pour un virement sur le compte du vendeur, 58 pour un virement SEPA, 49 pour un prélèvement, 48 pour une carte bancaire, et ainsi de suite.

Un nom de système ou de produit comme BACS n'est pas un code. Si vous voulez que le nom figure sur la facture, placez-le dans l'attribut name du même élément, qui porte le libellé du moyen de paiement.

Ce que la règle vérifie

La valeur est débarrassée des espaces de début et de fin, puis doit correspondre exactement à un seul code. La liste figée contient les numéros 1 à 70, 74 à 78 et 91 à 98, plus ZZZ pour un moyen défini d'un commun accord.

La forme et la casse comptent. Lors d'un essai, zzz, 030, 71, 99, les mots Credit transfer et la paire 30 58 ont tous été rejetés, tandis que 30 entouré d'espaces a été accepté.

L'attribut name n'est pas contrôlé par cette règle. Un code 30 avec name="BACS" a passé toutes les étapes lors d'un essai.

Un cbc:PaymentMeansCode vide fait échouer cette règle et PEPPOL-EN16931-R008. Omettre complètement l'élément fait échouer l'étape XSD à la place, car UBL l'exige dans chaque moyen de paiement.

TermeSignificationÉlément UBL
BT-81Code de type de moyen de paiementcac:PaymentMeans/cbc:PaymentMeansCode
BT-82Libellé du moyen de paiementcac:PaymentMeans/cbc:PaymentMeansCode/@name

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 :

  • Un nom ou un code interne de moyen de paiement, comme BACS, BANK ou CARD, est écrit tel quel dans l'élément, sans table de correspondance.
  • Le code est stocké sous forme de nombre et formaté avec un zéro de tête ou un remplissage.
  • Le code provient d'une autre liste, par exemple des codes de type d'opération propres à une banque.
  • Le texte descriptif et le code ont été intervertis : le texte se retrouve dans l'élément et le code dans l'attribut name.

Comment corriger le document

  1. Dressez la liste des moyens de paiement que propose votre système et associez chacun à un code UNTDID 4461 dans une table explicite. Un paiement que l'acheteur envoie sur le compte bancaire du vendeur via Bacs ou Faster Payments est un virement, 30 ; un encaissement au titre d'une instruction Bacs Direct Debit est un prélèvement, 49.
  2. Écrivez le code en texte brut, sans remplissage. Placez tout libellé lisible dans l'attribut name.
  3. Vérifiez ce que le nouveau code entraîne. 30 et 58 exigent un identifiant du compte du bénéficiaire (BR-61), et 49 et 59 exigent une référence de mandat (PEPPOL-EN16931-R061).

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 : le code du moyen de paiement est le nom d'un système de compensation britannique

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>BACS</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
    <!-- account name and branch omitted from this fragment -->
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Fragment de la facture corrigée : code 30, virement

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
    <!-- account name and branch omitted from this fragment -->
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Seul cbc:PaymentMeansCode diffère : BACS dans la facture en échec, 30 dans la facture corrigée. Le document en échec ne signale que BR-CL-16. Le compte du bénéficiaire et son identifiant sont présents dans les deux documents : une fois le code à 30, les règles du virement ne trouvent donc rien de manquant.

Ce que le validateur a signalé

Enregistré avec phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, le moteur du validateur gratuit, sur des données synthétiques. Un résultat enregistré est une preuve de non-régression pour ces documents ; ce n'est pas une certification.

Où la règle s'applique

  • S'applique aussi bien à Invoice qu'à CreditNote en UBL ; lors d'un essai, un avoir avec BACS a signalé la même règle.
  • La règle est contrôlée pour chaque cbc:PaymentMeansCode du document, avec un constat par code absent de la liste.
  • Un code hors liste masque les contrôles qui dépendent du code. BR-61 et PEPPOL-EN16931-R061 recherchent des codes précis : lors d'un essai, un moyen de paiement codé BACS sans aucun compte n'a donc signalé que cette règle.
  • Certaines règles nationales Peppol restreignent la liste pour les factures nationales, comme NL-R-008 entre parties néerlandaises et DK-R-005 entre parties danoises. Ce sont des constats distincts qui s'ajoutent à celui-ci.

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 BR-CL-16 (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.