UBL-SR-45 : Donner la date d'échéance dans un seul PaymentMeans au plus

La réponse courte

UBL-SR-45 échoue lorsque plus d'un cac:PaymentMeans du document contient un cbc:PaymentDueDate. Dans l'avoir enregistré, les deux moyens de paiement donnent 2026-10-08. Gardez la date dans un seul moyen de paiement et retirez-la des autres.

Un avoir n'a pas de cbc:DueDate propre ; sa date d'échéance se place donc bien dans cac:PaymentMeans/cbc:PaymentDueDate, une seule fois. Une facture indique sa date d'échéance en cbc:DueDate en haut du document et ne devrait pas la répéter du tout dans les moyens de paiement.

Ce que la règle vérifie

La règle s'exécute une fois sur la racine du document et compte les éléments cbc:PaymentDueDate directement à l'intérieur de cac:PaymentMeans. Elle échoue au-delà d'un, et le constat pointe sur la racine, quels que soient les moyens de paiement qui les portent.

Ce sont les éléments qui sont comptés, pas les valeurs distinctes : la même date deux fois échoue aussi sûrement que deux dates différentes. La référence de paiement et le code du moyen de paiement peuvent se répéter tant qu'ils concordent ; la date d'échéance, non. Lors d'un essai, 2026-10-08 dans un moyen de paiement et 2026-10-15 dans l'autre ont donné le même constat que deux dates égales.

Rien ne compare la date d'un moyen de paiement à la date d'échéance d'une facture. Lors d'un essai sur une facture, un unique cbc:PaymentDueDate au 2026-10-15 à côté d'un cbc:DueDate au 2026-10-08 n'a entraîné que l'avertissement UBL-CR-412, et des dates dans les deux moyens de paiement ont signalé cette règle, que cbc:DueDate soit présent ou non.

Seuls les moyens de paiement sont comptés. Lors d'un essai, un avoir portant sa date d'échéance dans un moyen de paiement et une seconde fois dans cac:PaymentTerms/cbc:PaymentDueDate a passé cette règle, avec seulement l'avertissement UBL-CR-463 pour l'élément des conditions de paiement. Deux dates d'échéance dans un même moyen de paiement n'atteignent jamais la règle : le schéma n'en admet qu'une à cet endroit, et l'étape XSD a rejeté le document 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 :

• La date d'échéance est écrite dans chaque cac:PaymentMeans par le même modèle, si bien qu'un second compte apporte une seconde copie.
• Un mapping conçu pour les avoirs, où la date d'échéance se place dans le moyen de paiement, est réutilisé pour des factures qui énumèrent plusieurs comptes.
• Des échéances à des dates différentes sont modélisées comme des moyens de paiement distincts, chacun avec sa propre date.

Comment corriger le document

1. Dans un avoir, gardez cbc:PaymentDueDate dans le premier cac:PaymentMeans seulement et laissez-le hors des autres.
2. Dans une facture, écrivez la date d'échéance une seule fois en cbc:DueDate, après cbc:IssueDate, et retirez cbc:PaymentDueDate de chaque cac:PaymentMeans ; l'avertissement UBL-CR-412 disparaît avec.
3. S'il y a vraiment plusieurs dates d'échéance, comme pour des paiements échelonnés, le modèle n'en accueille qu'une. Donnez la date du premier paiement et décrivez l'échéancier dans cac:PaymentTerms/cbc:Note.
4. Écrivez la date sous la forme simple YYYY-MM-DD : PEPPOL-EN16931-F001 contrôle ce format sur cbc:DueDate mais ne sélectionne pas cbc:PaymentDueDate.

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 l'avoir en échec : les deux moyens de paiement donnent la date d'échéance du 8 octobre

<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
<!-- currency, references and parties omitted from this fragment -->
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2026-10-08</cbc:PaymentDueDate>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2026-10-08</cbc:PaymentDueDate>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Fragment de l'avoir corrigé : la date d'échéance est donnée une fois, dans le premier moyen de paiement

<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
<!-- currency, references and parties omitted from this fragment -->
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2026-10-08</cbc:PaymentDueDate>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

L'avoir en échec donne cbc:PaymentDueDate 2026-10-08 dans les deux cac:PaymentMeans ; l'avoir corrigé le garde dans le premier et l'omet dans le second. Seul UBL-SR-45 est signalé, sur la racine du document : un avoir peut porter une date d'échéance de moyen de paiement, rien d'autre ne s'y oppose donc, et les étapes XSD et Peppol réussissent.

Où la règle s'applique

• S'applique à Invoice et à CreditNote, avec une différence. Lors d'un essai sur une facture, des dates d'échéance dans les deux moyens de paiement ont signalé cette règle avec l'avertissement UBL-CR-412, qui déconseille toute date d'échéance de moyen de paiement dans une facture ; avec la date dans un seul moyen de paiement, la facture était valide et gardait l'avertissement.
• Signalée par l'étape EN 16931 dans le cadre de la syntaxe UBL.
• Un avoir ne peut pas non plus déplacer la date au niveau du document. Lors d'un essai, ajouter cbc:DueDate à l'avoir a échoué à l'étape XSD.
• La référence de paiement et le code du moyen de paiement ont leurs propres règles de valeur unique, UBL-SR-44 et UBL-SR-47, que les mêmes moyens de paiement répétés peuvent enfreindre.

Règles liées

• UBL-SR-44 permet aux moyens de paiement de répéter une référence de paiement, mais pas d'en donner de différentes
• UBL-SR-47 exige le même code dans chaque moyen de paiement
• PEPPOL-EN16931-F001 contrôle le format de la date d'échéance de la facture dans cbc:DueDate
• 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-45 (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.