BR-30 : Placer la date de fin de la période de ligne le jour de sa date de début ou après

La réponse courte

BR-30 échoue lorsque le cac:InvoicePeriod d'une ligne de facture ou d'avoir a un cbc:EndDate antérieur à son cbc:StartDate. Corrigez les dates de service de cette ligne pour que le début soit le premier jour couvert et la fin le dernier, comme dans la facture corrigée : du 2026-08-01 au 2026-08-15.

Le constat nomme la ligne, par exemple cac:InvoiceLine[1]/cac:InvoicePeriod[1], et vous dit ainsi, sur une longue facture, exactement quelles dates de service revoir.

Ce que la règle vérifie

La règle parcourt chaque période de ligne et compare ses deux dates en tant que dates calendaires, mais seulement lorsque les deux sont présentes. Lors d'un essai, une période de ligne avec seulement une date de début et une autre avec seulement une date de fin ont chacune passé.

Des dates égales sont acceptées. Lors d'un essai, une période de ligne commençant et se terminant le 2026-08-15 a passé toutes les étapes, et avancer la fin d'un jour, au 2026-08-14, a signalé BR-30.

La ligne est jugée sur ses deux seules dates. Lors d'un essai, la période de ligne inversée a signalé BR-30 de la même façon après la suppression de la période de facturation au niveau du document.

Peppol compare chaque date de ligne séparément à la période du document, et une période de ligne inversée peut passer ces deux comparaisons. Lors d'un essai, une période de ligne allant du 2026-09-10 en arrière jusqu'au 2026-07-20, dans une période de facturation d'août, a signalé BR-30 mais ni PEPPOL-EN16931-R110 ni PEPPOL-EN16931-R111, car son début est après le 1er août et sa fin avant le 31 août.

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 modèle de ligne mappe les valeurs de début et de fin chacune sur l'élément de l'autre, alors que la période du document est mappée correctement.
• Des dates de ligne stockées en texte sont lues mois en premier alors que la source écrit le jour en premier : une ligne couvrant du 12 juillet au 3 août, stockée comme 12/07/2026 et 03/08/2026, devient du 7 décembre au 8 mars.
• Une ligne d'usage ou d'abonnement calcule sa date de fin à partir d'une date de début et d'une durée, et une résiliation produit une durée négative.
• Une ligne d'extourne construite à partir d'une ligne de facture antérieure intervertit ses dates pour montrer l'extourne, au lieu de garder la période et de rendre la quantité négative.

Comment corriger le document

1. Ouvrez la ligne nommée par le constat et retrouvez dans la fiche source la période de service qu'elle facture.
2. Écrivez le premier jour de cette période dans cbc:StartDate et le dernier jour dans cbc:EndDate à l'intérieur du cac:InvoicePeriod de la ligne, tous deux au format YYYY-MM-DD.
3. Analysez les dates en texte avec un format explicite qui correspond à la source, jamais avec un réglage régional par défaut.
4. Pour un avoir ou une extourne, gardez la période dans son ordre naturel et laissez la quantité ou le montant négatif exprimer l'extourne.
5. Revérifiez la ligne par rapport à la période du document : son début ne doit pas la précéder (PEPPOL-EN16931-R110) et sa fin ne doit pas la dépasser (PEPPOL-EN16931-R111).

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 ligne 1 va du 15 août en arrière jusqu'au 1er août

<cac:InvoicePeriod>
  <cbc:StartDate>2026-08-01</cbc:StartDate>
  <cbc:EndDate>2026-08-31</cbc:EndDate>
</cac:InvoicePeriod>
<!-- parties, VAT and totals omitted from this fragment -->
<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <!-- quantity and line net amount omitted from this fragment -->
  <cac:InvoicePeriod>
    <cbc:StartDate>2026-08-15</cbc:StartDate>
    <cbc:EndDate>2026-08-01</cbc:EndDate>
  </cac:InvoicePeriod>
  <!-- item and price omitted from this fragment -->
</cac:InvoiceLine>

Fragment de la facture corrigée : la ligne 1 couvre du 1er au 15 août

<cac:InvoicePeriod>
  <cbc:StartDate>2026-08-01</cbc:StartDate>
  <cbc:EndDate>2026-08-31</cbc:EndDate>
</cac:InvoicePeriod>
<!-- parties, VAT and totals omitted from this fragment -->
<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <!-- quantity and line net amount omitted from this fragment -->
  <cac:InvoicePeriod>
    <cbc:StartDate>2026-08-01</cbc:StartDate>
    <cbc:EndDate>2026-08-15</cbc:EndDate>
  </cac:InvoicePeriod>
  <!-- item and price omitted from this fragment -->
</cac:InvoiceLine>

Les deux dates de ligne ont échangé leurs places : du 2026-08-15 au 2026-08-01 dans la facture en échec, du 2026-08-01 au 2026-08-15 dans la facture corrigée. La période du document pour août est la même dans les deux, et BR-30 est le seul constat ; chaque date de ligne prise isolément reste dans cette période, donc les règles Peppol sur les périodes de ligne n'ont rien à signaler.

Où la règle s'applique

• S'applique aux documents Invoice et CreditNote. Dans un avoir, la ligne est un cac:CreditNoteLine, dont l'élément de période s'appelle toujours cac:InvoicePeriod ; lors d'un essai, une période inversée à cet endroit a signalé BR-30 à cac:CreditNoteLine[1]/cac:InvoicePeriod[1].
• Une règle EN 16931, signalée à cette seule étape.
• La période au niveau du document a sa propre règle pour la même comparaison, BR-29.
• Une date de ligne avec fuseau horaire, comme 2026-08-15Z, passe le XSD et est rejetée par PEPPOL-EN16931-F001. Lors d'un essai avec les deux dates inversées écrites ainsi, BR-30 et deux constats PEPPOL-EN16931-F001 ont été signalés.

Règles liées

• BR-29 fait la même comparaison pour la période de facturation du document entier
• BR-CO-20 rejette une période de ligne sans aucune date, le cas que cette règle n'examine pas
• PEPPOL-EN16931-R110 rejette une période de ligne qui commence avant la période de facturation
• PEPPOL-EN16931-R111 rejette une période de ligne qui se termine après la période de facturation
• 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 BR-30 (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.