Validation rules
UBL-SR-45 — UBL rule
The payment due date inside cac:PaymentMeans appears more than once — cbc:PaymentDueDate is allowed at most once in the document.
- Rule
UBL-SR-45— official EN 16931 / XRechnung rule- Severity
- error
- Business term
BT-9— Due date- Field in your JSON
invoice.due_date- Detected by
- tier 3 — KoSIT validator (authoritative)
- Reachability
- Only reachable when validating your own XML — normbill-generated documents cannot trigger it
The serializer writes the due date as document-level cbc:DueDate, never as PaymentMeans/PaymentDueDate.
How to fix it
Keep a single PaymentDueDate. In UBL invoices the due date (BT-9) is normally the document-level cbc:DueDate — that is where normbill writes invoice.due_date.
UBL-SR-45 auf Deutsch — was bedeutet der Fehler?
Der KoSIT-Validator lehnt die Rechnung ab, weil das Fälligkeitsdatum innerhalb von cac:PaymentMeans mehrfach vorkommt — cbc:PaymentDueDate ist höchstens einmal erlaubt.
So beheben Sie den Fehler
Behalten Sie höchstens ein PaymentDueDate. In UBL-Rechnungen gehört das Fälligkeitsdatum (BT-9) regulär in das dokumentweite cbc:DueDate — dort schreibt es auch normbill (invoice.due_date).
Related rules
BR-CO-25— An amount is due but neither a due date (BT-9) nor payment terms (BT-20) are present.UBL-SR-44— The document carries more than one distinct cbc:PaymentID value — the payment reference (BT-83) must be…UBL-SR-46— The payment means text (BT-82, the name attribute on cbc:PaymentMeansCode) appears more than once in the…UBL-SR-43— A schemeID attribute is set on an AdditionalDocumentReference/cbc:ID that is not an invoiced-object…UBL-SR-47— Several cac:PaymentMeans elements carry different cbc:PaymentMeansCode values — when the code (BT-81) is…UBL-SR-42— The supplier party carries more than two cac:PartyTaxScheme elements — at most two are allowed: the VAT…
Official sources
- XRechnung specification (KoSIT / xeinkauf.de)
- KoSIT validator on GitHub and the XRechnung validator configuration
Every 422 from the API lists the rule id, the path in your request JSON, a plain-language message and a suggested fix — see the docs overview for the report format.
Or try it live: drop any XRechnung XML on the free validator — same KoSIT-backed report, no account.