BR-30: Das Enddatum des Positionszeitraums auf oder nach sein Anfangsdatum legen

Die kurze Antwort

BR-30 schlägt fehl, wenn die cac:InvoicePeriod einer Position einer Rechnung oder Gutschrift ein cbc:EndDate hat, das vor ihrem cbc:StartDate liegt. Korrigieren Sie die Leistungsdaten dieser Position so, dass der Anfang der erste und das Ende der letzte abgedeckte Tag ist, wie in der korrigierten Rechnung: 2026-08-01 bis 2026-08-15.

Der Befund nennt die Position, etwa cac:InvoiceLine[1]/cac:InvoicePeriod[1], und sagt Ihnen so auf einer langen Rechnung genau, welche Leistungsdaten Sie nachprüfen müssen.

Was die Regel prüft

Die Regel besucht jeden Positionszeitraum und vergleicht seine beiden Daten als Kalenderdaten, aber nur, wenn beide vorhanden sind. Im Versuch bestanden ein Positionszeitraum nur mit Anfangsdatum und einer nur mit Enddatum jeweils.

Gleiche Daten werden akzeptiert. Im Versuch bestand ein Positionszeitraum, der am 2026-08-15 beginnt und endet, alle Prüfschritte, und das Enddatum um einen Tag auf 2026-08-14 vorzuziehen meldete BR-30.

Die Position wird allein nach ihren eigenen zwei Daten beurteilt. Im Versuch meldete der umgekehrte Positionszeitraum BR-30 ebenso, nachdem der Rechnungszeitraum auf Dokumentenebene entfernt worden war.

Peppol vergleicht jedes Positionsdatum für sich mit dem Zeitraum des Dokuments, und ein umgekehrter Positionszeitraum kann beide Vergleiche bestehen. Im Versuch meldete ein Positionszeitraum von 2026-09-10 zurück bis 2026-07-20 in einem Rechnungszeitraum für August BR-30, aber weder PEPPOL-EN16931-R110 noch PEPPOL-EN16931-R111, weil sein Anfang nach dem 1. August und sein Ende vor dem 31. August liegt.

Wie es in einer Integration dazu kommt

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

• Die Positionsvorlage bildet Anfangs- und Endwert jeweils auf das Element des anderen ab, während der Zeitraum des Dokuments richtig abgebildet ist.
• Als Text gespeicherte Positionsdaten werden mit dem Monat zuerst gelesen, während die Quelle den Tag zuerst schreibt: Eine Position vom 12. Juli bis 3. August, gespeichert als 12/07/2026 und 03/08/2026, wird zu 7. Dezember bis 8. März.
• Eine Nutzungs- oder Abonnementposition berechnet ihr Enddatum aus Anfangsdatum und Dauer, und eine Kündigung ergibt eine negative Dauer.
• Eine Stornoposition, die aus einer früheren Rechnungsposition aufgebaut wird, vertauscht ihre Daten, um die Stornierung zu zeigen, statt den Zeitraum beizubehalten und die Menge negativ zu machen.

So korrigieren Sie das Dokument

1. Öffnen Sie die im Befund genannte Position und schlagen Sie im Quelldatensatz den Leistungszeitraum nach, den sie abrechnet.
2. Schreiben Sie den ersten Tag dieses Zeitraums in cbc:StartDate und den letzten Tag in cbc:EndDate innerhalb der cac:InvoicePeriod der Position, beide als YYYY-MM-DD.
3. Lesen Sie Textdaten mit einem ausdrücklichen Format ein, das zur Quelle passt, niemals mit einer Gebietsschema-Voreinstellung.
4. Behalten Sie bei einer Gutschrift oder Stornierung den Zeitraum in seiner natürlichen Reihenfolge und lassen Sie die negative Menge oder den negativen Betrag die Stornierung ausdrücken.
5. Prüfen Sie die Position erneut gegen den Zeitraum des Dokuments: Ihr Anfang darf nicht davor liegen (PEPPOL-EN16931-R110) und ihr Ende nicht darüber hinausgehen (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: Position 1 läuft vom 15. August zurück zum 1. August

<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>

Ausschnitt der korrigierten Rechnung: Position 1 umfasst den 1. bis 15. August

<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>

Die beiden Positionsdaten haben die Plätze getauscht: 2026-08-15 bis 2026-08-01 in der fehlerhaften Rechnung, 2026-08-01 bis 2026-08-15 in der korrigierten. Der Zeitraum des Dokuments für August ist in beiden gleich, und BR-30 ist der einzige Befund; jedes Positionsdatum liegt für sich weiterhin innerhalb dieses Zeitraums, daher haben die Peppol-Regeln für Positionszeiträume nichts zu melden.

Wo die Regel gilt

• Gilt für Invoice und CreditNote. In einer Gutschrift ist die Position eine cac:CreditNoteLine, deren Zeitraumelement weiterhin cac:InvoicePeriod heißt; im Versuch meldete ein umgekehrter Zeitraum dort BR-30 an cac:CreditNoteLine[1]/cac:InvoicePeriod[1].
• Eine Regel aus EN 16931, nur in diesem Prüfschritt gemeldet.
• Der Zeitraum auf Dokumentenebene hat für denselben Vergleich eine eigene Regel, BR-29.
• Ein Positionsdatum mit Zeitzone, etwa 2026-08-15Z, besteht die XSD-Prüfung und wird von PEPPOL-EN16931-F001 abgewiesen. Im Versuch mit beiden umgekehrten Daten in dieser Form wurden BR-30 und zwei Befunde PEPPOL-EN16931-F001 gemeldet.

Verwandte Regeln

• BR-29 führt denselben Vergleich für den Rechnungszeitraum des ganzen Dokuments durch
• BR-CO-20 weist einen Positionszeitraum ganz ohne Daten ab, den Fall, den diese Regel nicht betrachtet
• PEPPOL-EN16931-R110 weist einen Positionszeitraum ab, der vor dem Rechnungszeitraum beginnt
• PEPPOL-EN16931-R111 weist einen Positionszeitraum ab, der nach dem Rechnungszeitraum endet
• 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-28.1: Quelle geprüft am 2026-09-28, Erklärung zuletzt aktualisiert am 2026-09-28.

Die offizielle Definition von BR-30 (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.