BR-CO-20: In jeden Positionszeitraum ein Datum setzen oder den Zeitraum weglassen

Die kurze Antwort

BR-CO-20 schlägt fehl, wenn eine cac:InvoicePeriod innerhalb einer Position weder cbc:StartDate noch cbc:EndDate enthält. Tragen Sie die Leistungsdaten dieser Position ein, oder lassen Sie das Element bei Positionen weg, die keinen Zeitraum abrechnen.

Das aufgezeichnete Beispiel ist die leere <cac:InvoicePeriod/>, die eine Vorlage schreibt, wenn beide Daten null sind. Peppol weist dieses Element zusätzlich als leer ab, unter PEPPOL-EN16931-R008.

Was die Regel prüft

Die Regel besucht jede cac:InvoicePeriod einer Position, in cac:InvoiceLine oder cac:CreditNoteLine, und ist erfüllt, wenn mindestens eines der beiden Datumselemente vorhanden ist. Ein Anfangsdatum allein oder ein Enddatum allein genügt; im Versuch bestand jede der beiden Varianten alle Prüfschritte.

Nichts anderes in einem Positionszeitraum zählt. Im Versuch meldete ein Positionszeitraum nur mit cbc:DescriptionCode 35 die Regel BR-CO-20 mit der Warnung UBL-CR-523, und einer nur mit cbc:Description meldete sie mit UBL-CR-524.

Die Regel für Positionen ist strenger als die für das ganze Dokument. Im Versuch bestand ein Zeitraum nur mit cbc:DescriptionCode 35 auf Dokumentenebene, wo BR-CO-19 den Code als Code für das Abrechnungsdatum der Umsatzsteuer akzeptiert.

Leerraum macht das Element nicht weniger leer. Im Versuch meldeten ein öffnendes und ein schließendes Tag cac:InvoicePeriod auf getrennten Zeilen, mit nur Leerraum dazwischen, dieselben zwei Regeln wie das aufgezeichnete Beispiel.

Leere Datumselemente erreichen diese Regel nie: Ein leeres cbc:StartDate oder cbc:EndDate ist im UBL-Schema kein gültiges Datum, und im Versuch scheiterte der XSD-Prüfschritt, bevor eine Geschäftsregel lief.

Wie es in einer Integration dazu kommt

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

• Die Positionsvorlage schreibt cac:InvoicePeriod immer und füllt die Daten nur für Abonnement- oder Nutzungspositionen, sodass einmalige Artikel einen leeren Zeitraum erhalten.
• Der Serialisierer lässt Datumsfelder mit null weg, behält aber ihr Elternelement.
• Eine Bezeichnung des Abrechnungszeitraums, etwa ein Monatsname, wird an der Position in cbc:Description geschrieben, statt in Daten umgewandelt zu werden.
• Das Mapping für den Zeitraum des Dokuments, der einen Code für das Abrechnungsdatum der Umsatzsteuer tragen kann, wurde für Positionen wiederverwendet, wo der Code keinen Platz hat.

So korrigieren Sie das Dokument

1. Finden Sie die Position über die Fundstelle, zum Beispiel cac:InvoiceLine[1]/cac:InvoicePeriod[1].
2. Rechnet die Position einen Leistungszeitraum ab, schreiben Sie dessen ersten Tag in cbc:StartDate und den letzten Tag in cbc:EndDate als YYYY-MM-DD, oder zumindest das eine Datum, das die Quelle hat.
3. Ist die Position an keinen Zeitraum gebunden, entfernen Sie cac:InvoicePeriod aus ihr. Die Gruppe ist an einer Position optional.
4. Geben Sie das Element nur aus, wenn eines seiner Daten einen Wert hat, damit ein null nie wieder eine leere Gruppe erzeugt.
5. Halten Sie Zeitraumbezeichnungen aus der Position heraus: cbc:Description und cbc:DescriptionCode liegen dort außerhalb des Modells und ziehen Warnungen nach sich.

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 hat ein leeres Zeitraumelement

<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
  <cac:InvoicePeriod/>
  <!-- item and price omitted from this fragment -->
</cac:InvoiceLine>

Ausschnitt der korrigierten Rechnung: Der Positionszeitraum läuft vom 1. bis 15. August

<cac:InvoiceLine>
  <cbc:ID>1</cbc:ID>
  <cbc:InvoicedQuantity unitCode="C62">2</cbc:InvoicedQuantity>
  <cbc:LineExtensionAmount currencyID="GBP">25.00</cbc:LineExtensionAmount>
  <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 fehlerhafte Rechnung hat an Position 1 eine leere <cac:InvoicePeriod/>, wo die korrigierte ein Anfangsdatum 2026-08-01 und ein Enddatum 2026-08-15 hat; der Zeitraum des Dokuments für August ist in beiden gleich. Neben BR-CO-20 meldet das fehlerhafte Dokument PEPPOL-EN16931-R008 am selben Element, weil ein Element ohne Inhalt nicht erlaubt ist. Die Daten einzutragen oder das Element zu entfernen behebt beide.

Wo die Regel gilt

• Gilt für Invoice und CreditNote. Im Versuch meldete ein leerer Zeitraum an einer cac:CreditNoteLine auf dieselbe Weise BR-CO-20 und PEPPOL-EN16931-R008.
• Der Zeitraum des ganzen Dokuments ist Sache von BR-CO-19: Im Versuch meldete eine leere cac:InvoicePeriod unter dem Wurzelelement diese Regel, nicht die hier beschriebene.
• Sind beide Daten vorhanden, prüft BR-30 ihre Reihenfolge, und gegenüber einem Zeitraum des Dokuments prüfen PEPPOL-EN16931-R110 und PEPPOL-EN16931-R111, dass die Position darin bleibt.

Verwandte Regeln

• BR-CO-19 ist die Datumsanforderung für den Rechnungszeitraum des ganzen Dokuments
• BR-30 prüft, dass ein Positionszeitraum mit beiden Daten nicht endet, bevor er beginnt
• PEPPOL-EN16931-R008 weist den leeren Positionszeitraum des aufgezeichneten Beispiels ab
• PEPPOL-EN16931-R110 vergleicht jedes Anfangsdatum einer Position mit dem Beginn des Rechnungszeitraums
• 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-CO-20 (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.