Validation rules

UBL-SR-27 — UBL rule

A cac:PaymentMeans carries more than one cbc:PaymentMeansCode (BT-81) — each payment means states exactly one code.

Rule
UBL-SR-27 — official EN 16931 / XRechnung rule
Severity
error
Business term
BT-81 — Payment means code
Field in your JSON
invoice.payment.means_code
Detected by
tier 3 — KoSIT validator (authoritative)
Reachability
Only reachable when validating your own XML — normbill-generated documents cannot trigger it

The serializer emits exactly one PaymentMeansCode, from invoice.payment.means_code.

How to fix it

Keep a single PaymentMeansCode per cac:PaymentMeans.

UBL-SR-27 auf Deutsch — was bedeutet der Fehler?

Der KoSIT-Validator lehnt die Rechnung ab, weil ein cac:PaymentMeans mehrere cbc:PaymentMeansCode (BT-81) trägt — jeder Zahlungsweg nennt genau einen Code.

So beheben Sie den Fehler

Behalten Sie genau einen PaymentMeansCode je cac:PaymentMeans.

Related rules

  • BR-DE-1 — Payment instructions (BG-16) are missing. XRechnung requires them.
  • BR-DE-25-a — Payment means is a SEPA direct debit (code 59) but direct-debit information (BG-19) is missing.
  • NB-PAYMENT-MEANS-UNSUPPORTED — Card-payment means codes (48/54/55) need card information (BG-18) that normbill cannot express yet — KoSIT…
  • BR-CL-16 — The payment means code (BT-81) is not a UNTDID 4461 code.
  • BR-49 — Payment instructions (BG-16) are present but the payment means type code (BT-81) is missing.
  • BR-DE-24-a — The payment means is a card payment (code 48, 54 or 55), so card information (BG-18) is required.

Official sources

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.

Spotted something?

Bug, missing feature, wrong validation result — tell us. The page you're on is attached automatically; email optional.