BR-CO-19: Dem Rechnungszeitraum ein Anfangsdatum, ein Enddatum oder beides geben

Die kurze Antwort

BR-CO-19 schlägt fehl, wenn das cac:InvoicePeriod auf Dokumentenebene weder ein cbc:StartDate noch ein cbc:EndDate hat. Ergänzen Sie die Daten des Zeitraums, den die Rechnung abdeckt, oder entfernen Sie cac:InvoicePeriod, wenn sich die Rechnung auf keinen Zeitraum bezieht.

Text wie August 2026 in cbc:Description erfüllt die Regel nicht, und dieses Element liegt ohnehin außerhalb des Modells EN 16931. Die einzige Ausnahme ist ein Zeitraum, dessen einziger Inhalt ein Code für das Datum der Steuerfälligkeit in cbc:DescriptionCode ist; das ist eine andere Information als der Zeitraum selbst.

Was die Regel prüft

Die Regel liest das cac:InvoicePeriod unterhalb des Wurzelelements. Sie besteht, wenn der Zeitraum ein Anfangsdatum, ein Enddatum oder beides enthält; im Versuch wurden ein Zeitraum nur mit cbc:StartDate und einer nur mit cbc:EndDate jeweils akzeptiert.

Sie besteht auch, wenn der Zeitraum ein cbc:DescriptionCode und keine Daten enthält. Dieser Code ist der Code für das Datum der Steuerfälligkeit (BT-8), den die UBL-Syntaxbindung in den Rechnungszeitraum legt; im Versuch bestand ein Zeitraum, der nur den Code 3 enthielt, alle Prüfschritte.

Sonst zählt nichts im Zeitraum. Ein cbc:Description allein schlägt fehl, und ein leeres <cac:InvoicePeriod/> schlägt ebenfalls fehl, zusammen mit PEPPOL-EN16931-R008 für das leere Element.

Ein leeres cbc:StartDate oder cbc:EndDate erreicht diese Regel nie: Ein Datumselement ohne Wert ist gegen das UBL-Schema ungültig, daher schlägt der XSD-Prüfschritt fehl, und die Geschäftsregeln werden übersprungen.

Zeiträume auf Positionsebene prüft BR-CO-20, das keine Ausnahme für einen Code kennt. Im Versuch meldete ein Positionszeitraum, der nur cbc:DescriptionCode enthielt, BR-CO-20 und die Warnung UBL-CR-523.

Wie es in einer Integration dazu kommt

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

• Das Abrechnungssystem speichert den Zeitraum als Bezeichnung, etwa als Monatsnamen, und der Export schreibt diese Bezeichnung in cbc:Description, statt sie in Daten umzuwandeln.
• Die Vorlage gibt cac:InvoicePeriod immer aus und füllt die Daten nur bei Abonnement- oder Dienstleistungsrechnungen, sodass andere Rechnungen einen leeren Zeitraum oder einen Zeitraum nur mit Beschreibung tragen.
• Die Datumsfelder sind bei einer einmaligen Berechnung null, und der Serialisierer verwirft die leeren Daten, behält aber ihr Elternelement.

So korrigieren Sie das Dokument

1. Entscheiden Sie, ob die Rechnung tatsächlich einen Zeitraum abdeckt. Wenn nicht, entfernen Sie cac:InvoicePeriod vollständig.
2. Wenn ja, schreiben Sie den ersten Tag in cbc:StartDate und den letzten Tag in cbc:EndDate im Format YYYY-MM-DD, abgeleitet aus dem Abrechnungszeitraum in der Quelle. Aus einer Bezeichnung wie August 2026 wird 2026-08-01 bis 2026-08-31.
3. Entfernen Sie cbc:Description aus dem Zeitraum. Ist der Wortlaut für den Käufer wichtig, gehört Freitext in die Bemerkung zur Rechnung, cbc:Note.
4. Existiert der Zeitraum nur, um den Code für das Datum der Steuerfälligkeit zu tragen, behalten Sie den Code und lassen Sie die Daten weg. Das besteht diese Regel, aber der Code darf nicht neben einem cbc:TaxPointDate stehen (BR-CO-03).

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 ist in Worten beschrieben und hat keine Daten

<cbc:BuyerReference>BUYER-REF-001</cbc:BuyerReference>
<cac:InvoicePeriod>
  <cbc:Description>August 2026</cbc:Description>
</cac:InvoicePeriod>

Ausschnitt der korrigierten Rechnung: Der Zeitraum hat ein Anfangs- und ein Enddatum

<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 korrigierte Rechnung ersetzt cbc:Description durch cbc:StartDate 2026-08-01 und cbc:EndDate 2026-08-31. Das fehlerhafte Dokument meldet außerdem UBL-CR-015, eine Warnung, dass cbc:Description innerhalb von cac:InvoicePeriod nicht Teil des Modells EN 16931 ist. Im Versuch blieb diese Warnung auch dann bestehen, wenn beide Daten neben der Beschreibung ergänzt wurden; erst das Entfernen der Beschreibung behebt sie.

Wo die Regel gilt

• Gilt für Invoice und CreditNote: Eine Gutschrift verwendet dasselbe Element cac:InvoicePeriod, und im Versuch meldete eine Gutschrift, die nur eine Beschreibung enthielt, ebenfalls BR-CO-19 und UBL-CR-015.
• Gemeldet im Prüfschritt EN 16931.
• Die Ausnahme für einen Code allein ist eng. Der Code muss 3, 35 oder 432 sein, sonst schlagen BR-CL-06 und PEPPOL-EN16931-CL006 fehl, und das Dokument darf nicht zusätzlich cbc:TaxPointDate tragen, sonst schlägt BR-CO-03 fehl.
• Sind beide Daten vorhanden, prüft BR-29, dass das Enddatum nicht vor dem Anfangsdatum liegt.

Verwandte Regeln

• BR-29 prüft die Reihenfolge der beiden Daten, sobald beide angegeben sind
• BR-CO-03 verbietet den Code für das Datum der Steuerfälligkeit, hier die einzige Alternative zu Daten, neben einem Datum der Steuerfälligkeit
• PEPPOL-EN16931-R008 wird zusätzlich gemeldet, wenn das Element des Rechnungszeitraums völlig leer bleibt
• 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-CO-19 (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.