BR-50 : Ajouter l'identifiant de compte au compte du bénéficiaire

La réponse courte

BR-50 échoue lorsqu'un cac:PaymentMeans avec le code 30 (virement) ou 58 (virement SEPA) contient un cac:PayeeFinancialAccount dont le cbc:ID est absent ou vide. Mettez le numéro du compte sur lequel l'acheteur doit payer, par exemple un IBAN ou un numéro de compte national, dans cbc:ID, comme premier enfant de cet élément de compte.

Un cbc:ID manquant fait aussi échouer BR-61 : les deux arrivent donc ensemble. Un élément présent mais vide fait échouer à la place cette règle et PEPPOL-EN16931-R008, sans BR-61.

Ce que la règle vérifie

La règle ne regarde que les moyens de paiement dont le cbc:PaymentMeansCode est 30 ou 58, et seulement lorsque ce moyen de paiement a un cac:PayeeFinancialAccount. Elle est satisfaite lorsque le compte contient un cbc:ID avec un texte autre que des espaces.

Le nom du compte dans cbc:Name et l'identifiant de la banque dans cac:FinancialInstitutionBranch ne comptent pas. La facture en échec enregistrée conserve les deux et échoue quand même.

Absent et vide sont signalés différemment. Sans aucun cbc:ID, BR-50 et BR-61 sont tous deux signalés. Avec un cbc:ID vide, ou ne contenant que des espaces, BR-61 est satisfait parce que l'élément existe, et cette règle est signalée avec PEPPOL-EN16931-R008 ; les deux cas ont été essayés.

Sans aucun cac:PayeeFinancialAccount, cette règle n'a rien à inspecter, et BR-61 signale seul le compte manquant.

La comparaison du code dans cette règle est exacte. Lors d'un essai avec un espace de part et d'autre de 30, cette règle est restée silencieuse et seul BR-61, qui supprime les espaces du code avant la comparaison, a signalé l'identifiant manquant.

Les autres codes de moyen de paiement sont hors du champ. Un compte sans identifiant sous le code 42 (paiement sur compte bancaire) a réussi toutes les étapes lors d'un essai.

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 :

• Le numéro de compte se trouve dans une table de coordonnées bancaires et la recherche échoue pour cette entité vendeuse ou cette devise, tandis que le nom du compte provient de la fiche de l'entreprise et est toujours écrit.
• Le sérialiseur omet un numéro de compte sans valeur mais conserve l'élément parent parce que ses autres enfants ont des valeurs.
• Le numéro de compte a été placé dans cac:FinancialInstitutionBranch/cbc:ID, qui est l'emplacement de l'identifiant de la banque, comme un BIC.
• Le numéro de compte a été écrit dans cbc:PaymentID ou dans une note, et l'élément de compte a été construit à partir des champs restants.

Comment corriger le document

1. Trouvez le compte sur lequel le vendeur veut être payé pour cette facture : l'IBAN ou le numéro de compte national tiré des propres coordonnées bancaires du vendeur pour l'entité et la devise de la facture.
2. Écrivez-le en tant que cbc:ID, premier enfant de cac:PayeeFinancialAccount, avant cbc:Name et cac:FinancialInstitutionBranch.
3. Conservez l'identifiant de la banque dans cac:FinancialInstitutionBranch/cbc:ID. Il se place à côté de l'identifiant de compte et ne le remplace pas.
4. Si l'acheteur ne paiera pas par virement, changez cbc:PaymentMeansCode pour le code du moyen réellement utilisé et retirez l'élément de compte, au lieu d'envoyer un virement sans compte.

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 compte du bénéficiaire a un nom et une agence, mais aucun identifiant de compte

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
    <cac:FinancialInstitutionBranch>
      <cbc:ID>EXAMPLE-BRANCH</cbc:ID>
    </cac:FinancialInstitutionBranch>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Fragment de la facture corrigée : l'identifiant de compte est le premier enfant du compte du bénéficiaire

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
    <cac:FinancialInstitutionBranch>
      <cbc:ID>EXAMPLE-BRANCH</cbc:ID>
    </cac:FinancialInstitutionBranch>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

La facture corrigée a <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID> au début de cac:PayeeFinancialAccount, et la facture en échec ne l'a pas ; rien d'autre ne diffère. Le document en échec signale aussi BR-61, la règle compagne qui exige un identifiant de compte pour les codes 30 et 58, qu'un élément de compte existe ou non. BR-50 est situé sur l'élément de compte et BR-61 sur le moyen de paiement, mais un seul élément manquant provoque les deux. EXAMPLE-ACCOUNT-001 est une valeur fictive, pas un format de numéro de compte.

Où la règle s'applique

• S'applique aussi bien à Invoice qu'à CreditNote en UBL. Lors d'un essai, un avoir avec un compte de virement sans identifiant a signalé BR-50 et BR-61.
• Les deux constats proviennent de l'étape EN 16931 ; l'étape Peppol réussit dans l'exemple enregistré.
• Chaque cac:PaymentMeans est contrôlé séparément, et l'emplacement du constat désigne celui qui n'a pas d'identifiant.
• Un code absent de la liste UNTDID 4461, comme BACS, fait échouer BR-CL-16 et sort le moyen de paiement du champ de cette règle : corriger le code en 30 peut donc faire apparaître ce constat ensuite.

Règles liées

• BR-61 exige l'identifiant de compte pour les deux mêmes codes et se déclenche avec cette règle lorsque l'ID manque
• PEPPOL-EN16931-R008 est signalé à la place de BR-61 lorsque l'élément ID du compte est présent mais vide
• BR-CL-16 vérifie le code de moyen de paiement qui décide si cette règle s'applique
• PEPPOL-EN16931-R061 est l'équivalent pour le prélèvement et exige une référence de mandat
• Parcourir toutes les règles de la référence
• Contexte (en anglais) : Understanding EN 16931 validation errors

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