PEPPOL-EN16931-F001: Daten als einfaches YYYY-MM-DD ohne Zeitzone schreiben

Die kurze Antwort

PEPPOL-EN16931-F001 schlägt fehl, wenn ein Datumselement etwas anderes als einen zehn Zeichen langen Wert YYYY-MM-DD enthält. Im aufgezeichneten Beispiel lautet das Fälligkeitsdatum 2026-10-08Z; entfernen Sie die Zeitzonenangabe und schreiben Sie 2026-10-08.

Die XSD erkennt das nicht. Der UBL-Datumstyp erlaubt eine optionale Zeitzone, daher sind 2026-10-08Z und 2026-10-08+01:00 beide gegenüber dem Schema gültig, und nur diese Peppol-Regel lehnt sie ab.

Was die Regel prüft

Die Regel wählt jedes Element mit dem Namen cbc:IssueDate, cbc:DueDate, cbc:TaxPointDate, cbc:StartDate, cbc:EndDate oder cbc:ActualDeliveryDate aus, wo immer es steht, und meldet jedes fehlerhafte an seiner eigenen Stelle. Im Versuch wurde eine Zeitzone am Anfangsdatum eines Positionszeitraums, am Lieferdatum und am Rechnungsdatum der vorausgegangenen Rechnung in cac:BillingReference jedes Mal gemeldet.

Ein Wert besteht, wenn er genau zehn Zeichen lang und ein gültiges Datum ist. Alles Längere schlägt fehl, umgebende Leerzeichen eingeschlossen: Im Versuch bestand 2026-10-08 die XSD, die Leerraum in einem Datum zusammenfasst, und schlug bei dieser Regel fehl.

Werte, die überhaupt keine Daten sind, etwa 08/10/2026 oder 2026-10-08T00:00:00, kommen hier nie an. Der XSD-Prüfschritt lehnt sie als Schemafehler ab, und die Peppol-Regeln werden übersprungen.

Elemente außerhalb dieser Liste werden nicht geprüft. Im Versuch bestand eine Gutschrift, deren cac:PaymentMeans/cbc:PaymentDueDate auf 2026-10-08Z gesetzt war, jeden Prüfschritt, obwohl die Peppol-Syntaxseite für dieses Element diese Regel aufführt.

Wie es in einer Integration dazu kommt

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

• Daten werden aus einem Zeitstempeltyp serialisiert, und die Bibliothek hängt Z oder einen Versatz an, weil der Wert eine Zeitzone trägt.
• Ein aus dem UBL-Schema erzeugtes XML-Binding bildet xs:date auf einen Kalendertyp ab, der seine Zeitzone standardmäßig schreibt.
• Der Wert wird mit einer ISO 8601-Routine formatiert, die den aktuellen Versatz anhängt, etwa +01:00 während der britischen Sommerzeit.
• Eine Vorlage oder ein Quellfeld mit fester Breite füllt das Datum mit Leerzeichen auf oder lässt einen Zeilenumbruch im Element.

So korrigieren Sie das Dokument

1. Finden Sie das Element über die Fundstelle in jedem Befund. Es gibt einen Befund je fehlerhaftem Datum, die Liste ist also vollständig.
2. Bestimmen Sie zuerst das Kalenderdatum in der geschäftlichen Zeitzone der Rechnung und lassen Sie dann die Uhrzeit weg, damit das Entfernen der Angabe das Datum nicht zusätzlich um einen Tag verschiebt.
3. Formatieren Sie es aus einem einfachen lokalen Datumstyp ohne Uhrzeit und ohne Zone, mit ausdrücklich vierstelligem Jahr, zweistelligem Monat und zweistelligem Tag, getrennt durch Bindestriche.
4. Schreiben Sie den Wert ohne weiteren Inhalt in das Element: keine Leerzeichen, keine Zeilenumbrüche.
5. Verwenden Sie denselben Formatierer für jedes Datum im Dokument, auch für Positionszeiträume, das Lieferdatum, das Rechnungsdatum der vorausgegangenen Rechnung und das Fälligkeitsdatum einer Gutschrift, obwohl diese Regel das letzte nicht prüft.

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: Das Fälligkeitsdatum trägt die Zeitzonenangabe Z

<cbc:ID>EXAMPLE-INV-001</cbc:ID>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08Z</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

Ausschnitt der korrigierten Rechnung: Das Fälligkeitsdatum ist ein einfaches Datum

<cbc:ID>EXAMPLE-INV-001</cbc:ID>
<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:DueDate>2026-10-08</cbc:DueDate>
<cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>

Nur cbc:DueDate unterscheidet sich: 2026-10-08Z in der fehlerhaften Rechnung, 2026-10-08 in der korrigierten. Das fehlerhafte Dokument meldet nur PEPPOL-EN16931-F001; die Prüfschritte XSD und EN 16931 bestehen beide, weil ein Datum mit Zeitzone weiterhin ein gültiges xs:date ist.

Wo die Regel gilt

• Gilt für Invoice und CreditNote. Im Versuch wurde ein Gutschriftsdatum von 2026-09-08Z gemeldet. Eine Gutschrift hat kein cbc:DueDate auf Wurzelebene: Wird eines hinzugefügt, schlägt die XSD fehl, und ihr Fälligkeitsdatum gehört in cac:PaymentMeans/cbc:PaymentDueDate, das außerhalb dieser Regel liegt.
• Eine Peppol-Regel, die nur im Peppol-Prüfschritt gemeldet wird. Der Prüfschritt EN 16931 akzeptierte jedes getestete Datum mit Zeitzonenangabe.
• Daten, die das Schema nicht lesen kann, werden als XSD-Schemafehler gemeldet, nie unter dieser Regel.

Verwandte Regeln

• BR-29 vergleicht die Daten des Rechnungszeitraums, deren Format diese Regel prüft
• PEPPOL-EN16931-R110 vergleicht die Anfangsdaten von Positionszeiträumen, weitere Daten, deren Format diese Regel prüft
• BR-CO-03 entscheidet, ob ein Datum der Steuerfälligkeit, eines der geprüften Elemente, überhaupt gesendet werden darf
• Alle Regeln der Referenz ansehen
• Hintergrund (auf Englisch): How Peppol invoice validation actually works

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 PEPPOL-EN16931-F001 (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.