BR-29: Einen Abrechnungszeitraum korrigieren, der endet, bevor er beginnt

Die kurze Antwort

BR-29 schlägt fehl, wenn die cac:InvoicePeriod direkt unter der Dokumentwurzel ein cbc:EndDate hat, das vor ihrem cbc:StartDate liegt. Schreiben Sie den ersten Tag des Zeitraums, den die Rechnung abdeckt, als Startdatum und den letzten Tag als Enddatum, und entnehmen Sie beide dem Abrechnungsdatensatz.

Ein eintägiger Zeitraum ist erlaubt: Beginn und Ende dürfen auf dasselbe Datum fallen. Die Regel beanstandet nur, wenn das Ende zuerst kommt.

Was die Regel prüft

Die Regel liest die cac:InvoicePeriod auf Dokumentenebene, und nur dann, wenn sie sowohl ein cbc:StartDate als auch ein cbc:EndDate enthält. Ein Zeitraum mit nur einem der beiden Daten wird gar nicht verglichen.

Die beiden Werte werden als Kalenderdaten verglichen, nicht als Text. Das Enddatum besteht, wenn es auf denselben Tag wie das Startdatum oder einen beliebigen späteren Tag fällt; im Versuch wurde ein Zeitraum, der am 2026-08-01 begann und endete, akzeptiert.

Positionszeiträume liegen außerhalb dieser Regel. Im Versuch meldete eine cac:InvoicePeriod einer Position mit vertauschten Daten BR-30, das Gegenstück auf Positionsebene, und nicht BR-29.

Ein Wert, der gar kein Datum ist, etwa 31/08/2026, scheitert am XSD-Prüfschritt, und die Geschäftsregeln, diese eingeschlossen, werden dann übersprungen.

Wie es in einer Integration dazu kommt

Mögliche Ursachen, abgeleitet aus der Form der Regel und nicht aus gemessener Nutzung:

• Start- und Endwert werden in der Exportvorlage jeweils dem Element des anderen zugeordnet.
• Als Text gespeicherte Daten werden mit vertauschtem Tag und Monat eingelesen: Ein Zeitraum vom 5. Januar bis 2. Februar, gespeichert als 05/01/2026 und 02/02/2026, wird zu 1. Mai bis 2. Februar, wenn der Monat zuerst gelesen wird.
• Das Enddatum wird aus dem Startdatum plus einer Dauer berechnet, und ein gekündigtes oder storniertes Abonnement ergibt eine Dauer von null oder eine negative Dauer.
• Eine Gutschrift übernimmt den Zeitraum der Rechnung, die sie korrigiert, füllt aber den Beginn aus dem alten Enddatum und das Ende aus dem alten Startdatum.

So korrigieren Sie das Dokument

1. Stellen Sie fest, woher der Abrechnungszeitraum stammt: aus der Laufzeit des Abonnements, den Leistungsdaten oder dem Abrechnungslauf.
2. Schreiben Sie den ersten Tag dieses Zeitraums in cac:InvoicePeriod/cbc:StartDate und den letzten Tag in cac:InvoicePeriod/cbc:EndDate, beide als YYYY-MM-DD.
3. Wenn Daten als Text ankommen, lesen Sie sie mit einem expliziten Format ein, das zur Quelle passt, nie mit einer Standardeinstellung des Gebietsschemas.
4. Ist der Quelldatensatz selbst falsch, korrigieren Sie ihn dort. Die beiden Werte im XML zu tauschen ist nur dann richtig, wenn sie lediglich in die falschen Elemente geschrieben wurden.
5. Prüfen Sie etwaige Positionszeiträume gegen den korrigierten Dokumentzeitraum: Peppol weist einen Positionszeitraum ab, der vor ihm beginnt (PEPPOL-EN16931-R110) oder nach ihm endet (PEPPOL-EN16931-R111).

Korrigierte Rechnung prüfen

Vorher und nachher

Dies sind Ausschnitte, keine vollständigen Dokumente. Die vollständigen synthetischen Dokumente, aus denen sie stammen, sind unten verlinkt.

Ausschnitt der fehlerhaften Rechnung: Der Zeitraum läuft vom 31. August zurück zum 1. August

<cbc:BuyerReference>BUYER-REF-001</cbc:BuyerReference>
<cac:InvoicePeriod>
  <cbc:StartDate>2026-08-31</cbc:StartDate>
  <cbc:EndDate>2026-08-01</cbc:EndDate>
</cac:InvoicePeriod>

Ausschnitt der korrigierten Rechnung: Der Zeitraum beginnt am 1. August und endet am 31. August

<cbc:BuyerReference>BUYER-REF-001</cbc:BuyerReference>
<cac:InvoicePeriod>
  <cbc:StartDate>2026-08-01</cbc:StartDate>
  <cbc:EndDate>2026-08-31</cbc:EndDate>
</cac:InvoicePeriod>

Die beiden Daten haben die Plätze getauscht: Die korrigierte Rechnung beginnt den Zeitraum am 2026-08-01 und beendet ihn am 2026-08-31. Sonst unterscheidet sich nichts, und BR-29 ist der einzige Befund, den das fehlerhafte Dokument meldet; der XSD- und der Peppol-Prüfschritt bestehen, weil jedes Datum für sich wohlgeformt ist und die Rechnung keine Positionszeiträume hat.

Wo die Regel gilt

• Gilt gleichermaßen für UBL Invoice und CreditNote. Im Versuch meldete eine Gutschrift mit demselben umgekehrten Zeitraum BR-29 bei ihrer cac:InvoicePeriod.
• Es ist eine Regel aus EN 16931 und wird im Prüfschritt EN 16931 gemeldet.
• Positionszeiträume haben eine eigene Regel, BR-30, die denselben Vergleich innerhalb jeder cac:InvoiceLine oder cac:CreditNoteLine anstellt.
• Ein Datum mit Zeitzonensuffix, etwa 2026-08-31Z, besteht das XSD, wird aber im Peppol-Prüfschritt von PEPPOL-EN16931-F001 abgewiesen.

Verwandte Regeln

• BR-CO-19 verlangt mindestens ein Datum in einem Abrechnungszeitraum, dessen Reihenfolge diese Regel dann sichert
• PEPPOL-EN16931-R110 prüft, dass kein Positionszeitraum vor diesem Abrechnungszeitraum beginnt
• PEPPOL-EN16931-F001 weist Datumswerte des Zeitraums zurück, die keine reinen YYYY-MM-DD-Werte sind
• Alle Regeln der Referenz ansehen
• Hintergrund (auf Englisch): Understanding EN 16931 validation errors

Umfang und Quelle

Geschrieben für Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, angewendet auf Invoice- und CreditNote-Dokumente in UBL 2.1. Andere Profile, Syntaxen und Releases können diese Kennung anders definieren. Version des Hinweiskatalogs 2026-09-24.1: Quelle geprüft am 2026-09-24, Erklärung zuletzt aktualisiert am 2026-09-24.

Die offizielle Definition von BR-29 (auf Englisch) enthält den normativen Wortlaut und den Test. Diese Seite ist unsere Erklärung dazu, keine Kopie.

Die Erklärung ändert das Urteil der Engine nicht. Dass Sie diesen Befund beheben, heißt nicht, dass das Dokument jeden Prüfschritt besteht. Die Validierung bescheinigt keine rechtliche oder steuerliche Konformität und überträgt kein Dokument über Peppol.