PEPPOL-EN16931-F001 : Écrire les dates au format simple YYYY-MM-DD, sans fuseau horaire

La réponse courte

PEPPOL-EN16931-F001 échoue lorsqu'un élément de date contient autre chose qu'une valeur YYYY-MM-DD de dix caractères. Dans l'exemple enregistré, la date d'échéance est 2026-10-08Z ; retirez le suffixe de fuseau horaire et écrivez 2026-10-08.

La XSD ne le détecte pas. Le type date d'UBL autorise un fuseau horaire facultatif : 2026-10-08Z et 2026-10-08+01:00 sont donc tous deux valides au regard du schéma, et seule cette règle Peppol les rejette.

Ce que la règle vérifie

La règle sélectionne chaque élément nommé cbc:IssueDate, cbc:DueDate, cbc:TaxPointDate, cbc:StartDate, cbc:EndDate ou cbc:ActualDeliveryDate, où qu'il se trouve, et signale chacun de ceux qui échouent à son propre emplacement. Lors d'un essai, un fuseau horaire sur la date de début d'une période de ligne, sur la date de livraison et sur la date d'émission de la facture antérieure dans cac:BillingReference a été signalé à chaque fois.

Une valeur réussit lorsqu'elle compte exactement dix caractères et qu'elle est une date valide. Tout ce qui est plus long échoue, espaces autour compris : lors d'un essai, 2026-10-08 a passé la XSD, qui réduit les espaces dans une date, et échoué à cette règle.

Les valeurs qui ne sont pas du tout des dates, comme 08/10/2026 ou 2026-10-08T00:00:00, n'arrivent jamais jusqu'ici. L'étape XSD les rejette comme erreurs de schéma, et les règles Peppol sont ignorées.

Les éléments hors de cette liste ne sont pas contrôlés. Lors d'un essai, un avoir dont cac:PaymentMeans/cbc:PaymentDueDate valait 2026-10-08Z a réussi toutes les étapes, bien que la page de syntaxe Peppol de cet élément mentionne cette règle.

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 dates sont sérialisées à partir d'un type horodatage, et la bibliothèque ajoute Z ou un décalage parce que la valeur porte un fuseau horaire.
• Un binding XML généré à partir du schéma UBL associe xs:date à un type calendaire qui écrit son fuseau horaire par défaut.
• La valeur est formatée par une routine ISO 8601 qui ajoute le décalage courant, comme +01:00 pendant l'heure d'été britannique.
• Un modèle ou un champ source à largeur fixe complète la date avec des espaces ou laisse un saut de ligne dans l'élément.

Comment corriger le document

1. Utilisez l'emplacement de chaque constat pour trouver l'élément. Il y a un constat par date incorrecte, la liste est donc complète.
2. Prenez d'abord la date calendaire dans le fuseau horaire d'activité de la facture, puis supprimez l'heure, afin que le retrait du suffixe ne décale pas aussi la date d'un jour.
3. Formatez-la à partir d'un simple type de date locale, sans heure ni fuseau, avec explicitement une année sur quatre chiffres, un mois sur deux chiffres et un jour sur deux chiffres, séparés par des tirets.
4. Écrivez la valeur sans rien d'autre dans l'élément : ni espaces, ni sauts de ligne.
5. Utilisez le même formateur pour chaque date du document, y compris les périodes de ligne, la date de livraison, la date d'émission de la facture antérieure et la date d'échéance d'un avoir, même si cette règle ne contrôle pas cette dernière.

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 : la date d'échéance porte le suffixe de fuseau horaire Z

<cbc:ID>EXAMPLE-INV-001</cbc:ID>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08Z</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

Fragment de la facture corrigée : la date d'échéance est une date simple

<cbc:ID>EXAMPLE-INV-001</cbc:ID>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

Seul cbc:DueDate diffère : 2026-10-08Z dans la facture en échec, 2026-10-08 dans la facture corrigée. Le document en échec ne signale que PEPPOL-EN16931-F001 ; les étapes XSD et EN 16931 réussissent toutes deux, car une date avec fuseau horaire reste un xs:date valide.

Où la règle s'applique

• S'applique à Invoice et à CreditNote. Lors d'un essai, une date d'émission d'avoir de 2026-09-08Z a été signalée. Un avoir n'a pas de cbc:DueDate au niveau racine : en ajouter un fait échouer la XSD, et sa date d'échéance va dans cac:PaymentMeans/cbc:PaymentDueDate, qui est hors du champ de cette règle.
• Une règle Peppol, signalée uniquement dans l'étape Peppol. L'étape EN 16931 a accepté toutes les dates avec suffixe essayées.
• Les dates que le schéma ne peut pas lire sont signalées comme erreurs de schéma XSD, jamais au titre de cette règle.

Règles liées

• BR-29 compare les dates de la période de facturation dont cette règle contrôle le format
• PEPPOL-EN16931-R110 compare les dates de début des périodes de ligne, un autre ensemble de dates dont cette règle contrôle le format
• BR-CO-03 décide si une date d'exigibilité de la TVA, l'un des éléments contrôlés, peut ou non être envoyée
• 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 PEPPOL-EN16931-F001 (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.