BR-DE-24-aWenn BT-81 "Payment means type code" einen Schlüssel für Kartenzahlungen enthält (48, 54, 55), muss genau BG-18 "PAYMENT CARD INFORMATION" übermittelt werden.

Official rule text

For a card payment (BT-81 with code 48, 54 or 55) the document must carry group BG-18 with the card details. What goes inside it is BR-51's business: the last digits of the card number, never the full PAN.

Severity
Error
Applies to
CII, UBL
Rule set
v2026-08-31
Checked on

Written and checked against the official KoSIT rule set by Dmytro Yalanskyi, NormAPI.

Why does BR-DE-24-a happen?

Card payment is rare in invoicing flows; when the code is set anyway (say, because payment was already taken by card), the matching group is almost always missing. The expression below gives none of that away: it is just cac:CardAccount, the bare existence of the group. The three codes live in the rule's context, in the pattern on cac:PaymentMeans, and each payment route is judged on its own.

What the validator checks

The expression the official KoSIT rule set evaluates — not paraphrased, but read from the Schematron file it ships. UBL and CII address different document trees, so the same rule reads differently in each.

UBL
cac:CardAccount
CII
ram:ApplicableTradeSettlementFinancialCard

Source: rule set v2026-08-31

How do you fix BR-DE-24-a?

Transmit BG-18 with the masked card number (BT-87, last digits only — never the full PAN): cac:PaymentMeans/cac:CardAccount in UBL, ram:ApplicableTradeSettlementFinancialCard in CII.

In the XML

A UBL fragment. The CII path is named above — same change, different element names.

Fails
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>54</cbc:PaymentMeansCode>
</cac:PaymentMeans>
Fixed
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>54</cbc:PaymentMeansCode>
  <cac:CardAccount>
    <cbc:PrimaryAccountNumberID>******1234</cbc:PrimaryAccountNumberID>
    <cbc:NetworkID>NA</cbc:NetworkID>
  </cac:CardAccount>
</cac:PaymentMeans>

Related rules

NormAPI provides technical validation, not tax or legal advice.