UBL-SR-45: Das Fälligkeitsdatum in höchstens einem PaymentMeans angeben

Die kurze Antwort

UBL-SR-45 schlägt fehl, wenn mehr als ein cac:PaymentMeans im Dokument ein cbc:PaymentDueDate enthält. In der aufgezeichneten Gutschrift nennen beide Zahlungsarten 2026-10-08. Behalten Sie das Datum in einer Zahlungsart und entfernen Sie es aus den anderen.

Eine Gutschrift hat kein eigenes cbc:DueDate, ihr Fälligkeitsdatum gehört also tatsächlich in cac:PaymentMeans/cbc:PaymentDueDate, einmal. Eine Rechnung nennt ihr Fälligkeitsdatum als cbc:DueDate weit oben im Dokument und sollte es in den Zahlungsarten gar nicht wiederholen.

Was die Regel prüft

Die Regel läuft einmal an der Wurzel des Dokuments und zählt die Elemente cbc:PaymentDueDate direkt innerhalb von cac:PaymentMeans. Sie schlägt bei mehr als einem fehl, und der Befund verweist auf die Wurzel, gleich welche Zahlungsarten sie tragen.

Gezählt werden Elemente, nicht unterschiedliche Werte, daher scheitert dasselbe Datum zweimal genauso wie zwei verschiedene Daten. Zahlungsreferenz und Code der Zahlungsart dürfen sich wiederholen, solange sie übereinstimmen; das Fälligkeitsdatum nicht. Im Versuch ergaben 2026-10-08 in der einen Zahlungsart und 2026-10-15 in der anderen denselben Befund wie zwei gleiche Daten.

Nichts vergleicht das Datum einer Zahlungsart mit dem Fälligkeitsdatum einer Rechnung. Im Versuch mit einer Rechnung brachte ein einzelnes cbc:PaymentDueDate von 2026-10-15 neben einem cbc:DueDate von 2026-10-08 nur die Warnung UBL-CR-412, und Daten in beiden Zahlungsarten meldeten diese Regel, ob cbc:DueDate vorhanden war oder nicht.

Gezählt werden nur Zahlungsarten. Im Versuch bestand eine Gutschrift mit ihrem Fälligkeitsdatum in einer Zahlungsart und noch einmal in cac:PaymentTerms/cbc:PaymentDueDate diese Regel, nur mit der Warnung UBL-CR-463 für das Element der Zahlungsbedingungen. Zwei Fälligkeitsdaten in einer Zahlungsart erreichen die Regel nie: Das Schema erlaubt dort eines, und der XSD-Prüfschritt lehnte das Dokument im Versuch ab.

Wie es in einer Integration dazu kommt

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

• Das Fälligkeitsdatum wird von derselben Vorlage in jedes cac:PaymentMeans geschrieben, sodass ein zweites Konto eine zweite Kopie mitbringt.
• Ein für Gutschriften gebautes Mapping, bei denen das Fälligkeitsdatum in die Zahlungsart gehört, wird für Rechnungen mit mehreren Konten wiederverwendet.
• Raten mit unterschiedlichen Fälligkeitsdaten werden als getrennte Zahlungsarten abgebildet, jede mit ihrem eigenen Datum.

So korrigieren Sie das Dokument

1. Behalten Sie in einer Gutschrift cbc:PaymentDueDate nur im ersten cac:PaymentMeans und lassen Sie es in den anderen weg.
2. Schreiben Sie in einer Rechnung das Fälligkeitsdatum einmal als cbc:DueDate, nach cbc:IssueDate, und entfernen Sie cbc:PaymentDueDate aus jedem cac:PaymentMeans; die Warnung UBL-CR-412 verschwindet damit.
3. Gibt es wirklich mehrere Fälligkeitsdaten, etwa bei Raten, hat das Modell Platz für eines. Geben Sie das Datum der ersten Zahlung an und beschreiben Sie den Zahlungsplan in cac:PaymentTerms/cbc:Note.
4. Schreiben Sie das Datum als einfaches YYYY-MM-DD: PEPPOL-EN16931-F001 prüft dieses Format an cbc:DueDate, wählt cbc:PaymentDueDate aber nicht aus.

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 Gutschrift: Beide Zahlungsarten nennen das Fälligkeitsdatum 8. Oktober

<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
<!-- currency, references and parties omitted from this fragment -->
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2026-10-08</cbc:PaymentDueDate>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2026-10-08</cbc:PaymentDueDate>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Ausschnitt der korrigierten Gutschrift: Das Fälligkeitsdatum steht einmal, in der ersten Zahlungsart

<cbc:IssueDate>2026-09-08</cbc:IssueDate>
<cbc:CreditNoteTypeCode>381</cbc:CreditNoteTypeCode>
<!-- currency, references and parties omitted from this fragment -->
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentDueDate>2026-10-08</cbc:PaymentDueDate>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Die fehlerhafte Gutschrift nennt cbc:PaymentDueDate 2026-10-08 in beiden cac:PaymentMeans; die korrigierte Gutschrift behält es in der ersten und lässt es in der zweiten weg. Gemeldet wird nur UBL-SR-45, an der Wurzel des Dokuments: Eine Gutschrift darf ein Fälligkeitsdatum in der Zahlungsart tragen, daher beanstandet sonst nichts, und der XSD- und der Peppol-Prüfschritt bestehen.

Wo die Regel gilt

• Gilt für Invoice und CreditNote, mit einem Unterschied. Im Versuch mit einer Rechnung meldeten Fälligkeitsdaten in beiden Zahlungsarten diese Regel zusammen mit der Warnung UBL-CR-412, die von jedem Fälligkeitsdatum in der Zahlungsart einer Rechnung abrät; mit dem Datum in einer Zahlungsart war die Rechnung gültig und behielt die Warnung.
• Gemeldet vom Prüfschritt EN 16931 als Teil der UBL-Syntaxbindung.
• Eine Gutschrift kann das Datum auch nicht auf die Dokumentenebene verlegen. Im Versuch scheiterte das Hinzufügen von cbc:DueDate zur Gutschrift am XSD-Prüfschritt.
• Zahlungsreferenz und Code der Zahlungsart haben eigene Regeln für einen einzigen Wert, UBL-SR-44 und UBL-SR-47, gegen die dieselben wiederholten Zahlungsarten verstoßen können.

Verwandte Regeln

• UBL-SR-44 lässt Zahlungsarten eine Zahlungsreferenz wiederholen, aber keine unterschiedlichen angeben
• UBL-SR-47 verlangt in jeder Zahlungsart denselben Code
• PEPPOL-EN16931-F001 prüft das Format des Fälligkeitsdatums der Rechnung in cbc:DueDate
• 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 UBL-SR-45 (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.