Sur cette page
La réponse courte
UBL-SR-44 échoue lorsque le document contient des éléments cbc:PaymentID avec plus d'une valeur distincte. Dans l'exemple enregistré, le second cac:PaymentMeans demande PAYMENT-002 là où le premier demande PAYMENT-001. Choisissez la référence unique que l'acheteur doit indiquer et écrivez exactement cette valeur dans chaque moyen de paiement.
Plusieurs moyens de paiement sont permis, par exemple un pour chaque compte bancaire sur lequel l'acheteur peut payer, et chacun peut répéter la référence. Ce que le modèle ne peut pas exprimer, c'est une seconde référence, différente : il n'a qu'un seul champ d'avis de paiement pour toute la facture.
Ce que la règle vérifie
La règle s'exécute une fois par document et rassemble chaque cbc:PaymentID, où qu'il se trouve. Elle compte les valeurs distinctes et échoue à partir de deux ; le constat pointe sur la racine du document, et lors d'un essai avec trois moyens de paiement demandant trois références différentes, il n'y a eu qu'un seul constat.
Les répétitions et les absences sont permises. Lors d'un essai, retirer cbc:PaymentID du second moyen de paiement a réussi, et la facture corrigée donne PAYMENT-001 dans les deux.
Les valeurs sont comparées telles qu'elles sont écrites. Lors d'un essai, PAYMENT-001 avec un espace final et payment-001 en minuscules ont chacun compté comme une seconde référence et fait échouer la règle.
Deux références différentes dans un seul moyen de paiement échouent doublement. Lors d'un essai, un unique cac:PaymentMeans contenant PAYMENT-001 et PAYMENT-002 a signalé cette règle et UBL-SR-26, qui n'admet qu'un cbc:PaymentID par moyen de paiement ; la même valeur écrite deux fois n'y a signalé que UBL-SR-26.
| Terme | Signification | Élément UBL |
|---|---|---|
| BT-83 | Avis de paiement | cac:PaymentMeans/cbc:PaymentID |
| BG-16 | Instructions de paiement | cac:PaymentMeans |
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 :
- La référence de paiement est générée par compte bancaire ou par canal de paiement, si bien que chaque
cac:PaymentMeansreçoit la sienne. - Les échéances sont modélisées comme des moyens de paiement distincts, chacun avec la référence de son échéance.
- Une référence est normalisée à un endroit et pas à un autre, ce qui laisse un espace final ou une casse différente dans une copie.
Comment corriger le document
- Déterminez la référence que l'acheteur doit indiquer en payant, par exemple le numéro de facture ou une référence créancier structurée.
- Écrivez exactement cette valeur, caractère pour caractère, dans le
cbc:PaymentIDde chaquecac:PaymentMeansqui en porte un, ou retirez-la de tous sauf un. - Si vous avez besoin de références différentes pour différents comptes ou échéances, le modèle n'a pas de place pour elles. Gardez une référence et décrivez l'arrangement dans les conditions de paiement,
cac:PaymentTerms/cbc:Note. - Nettoyez et normalisez la référence une seule fois, avant de la copier dans chaque moyen de paiement.
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 : deux comptes, chacun avec sa propre référence de paiement
<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>
<cac:PaymentMeans>
<cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
<cbc:PaymentID>PAYMENT-002</cbc:PaymentID>
<cac:PayeeFinancialAccount>
<cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
<cbc:Name>Example Supplier Ltd</cbc:Name>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>Fragment de la facture corrigée : les deux comptes demandent PAYMENT-001
<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>
<cac:PaymentMeans>
<cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
<cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
<cac:PayeeFinancialAccount>
<cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
<cbc:Name>Example Supplier Ltd</cbc:Name>
</cac:PayeeFinancialAccount>
</cac:PaymentMeans>Le second cac:PaymentMeans porte PAYMENT-002 dans la facture en échec et PAYMENT-001 dans la facture corrigée ; les deux documents proposent les deux mêmes comptes sous le code 30. Le document en échec ne signale que UBL-SR-44, sur la racine du document, puisque chaque moyen de paiement est complet et valide en lui-même.
Ce que le validateur a signalé
- La facture en erreur signale UBL-SR-44. Le document corrigé passe toutes les étapes de validation sans constat.Télécharger le XML en erreurTélécharger le XML corrigé
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 à
Invoiceet àCreditNote. Lors d'un essai, un avoir avec deux moyens de paiement demandant des références différentes a signalé cette règle. - Fait partie de la syntaxe UBL et est signalée à l'étape EN 16931 ; l'étape Peppol a validé la facture en échec enregistrée.
- Le code du moyen de paiement est soumis à la même restriction à une seule valeur, imposée par
UBL-SR-47. Lors d'un essai, modifier à la fois le code et la référence du second moyen de paiement a signalé les deux règles. - Un
cbc:PaymentIDvide compte aussi comme une valeur. Lors d'un essai, vider le second a signalé cette règle etPEPPOL-EN16931-R008.
Règles liées
- UBL-SR-47 exige le même code de moyen de paiement dans chaque moyen de paiement
- BR-61 exige un identifiant de compte dans chaque moyen de paiement par virement
- PEPPOL-EN16931-R008 signale un élément de référence de paiement laissé vide
- UBL-SR-45 n'admet une date d'échéance que dans un seul moyen de paiement, même lorsque les dates concordent
- 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-28.1 : source vérifiée le 2026-09-28, explication mise à jour le 2026-09-28.
La définition officielle de UBL-SR-44 (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.

