BR-51In accordance with card payments security standards an invoice should never include a full card primary account number (BT-87).

Offizieller Regeltext

At the moment PCI Security Standards Council has defined that the first 6 digits and last 4 digits are the maximum number of digits to be shown.

KoSIT formuliert diese Regel in den beiden Dateien unterschiedlich. Oben steht die UBL-Fassung, hier die andere:

Wortlaut in CII

In accordance with card payments security standards an invoice should never include a full card primary account number (BT-97). At the moment PCI Security Standards Council has defined that the first 6 digits and last 4 digits are the maximum number of digits to be shown.

Die vollständige Kartennummer darf niemals in einer Rechnung stehen — umgesetzt ist das als schlichte Längengrenze: höchstens zehn Zeichen im Feld. Das entspricht den ersten sechs und letzten vier Ziffern, die PCI DSS als Maximum zulässt.

Schweregrad: Fehler
Gilt für: CII, UBL
Regelwerk: v2026-08-31
Geprüft am: 4. September 2026

Geschrieben und gegen das offizielle KoSIT-Regelwerk geprüft von Dmytro Yalanskyi, NormAPI.

Warum tritt BR-51 auf?

Die Kartennummer liegt im Zahlungssystem vollständig vor und wird beim Mapping unverändert übernommen, weil das Feld im Zielschema genau so heißt. Damit wandert ein Datum in ein Dokument, das per Mail verschickt und jahrelang archiviert wird. Der Regeltext oben nennt übrigens BT-97 — den Grund eines Abschlags auf Dokumentebene. Das ausgelieferte Regelwerk widerspricht sich hier: die UBL-Fassung von BR-51 schreibt BT-87, die CII-Fassung BT-97. Gemeint und geprüft ist in beiden die Kartennummer.

Was der Validator prüft

Der Ausdruck, den das offizielle KoSIT-Regelwerk auswertet — nicht paraphrasiert, sondern aus der ausgelieferten Schematron-Datei gelesen. UBL und CII adressieren verschiedene Dokumentbäume, deshalb steht dieselbe Regel je Syntax anders da.

UBL: string-length(normalize-space(.))<=10
CII: string-length(normalize-space(ram:ID)) <= 10

Quelle: Regelwerk v2026-08-31

Wie behebt man BR-51?

Maskieren Sie vor dem Schreiben und übermitteln Sie höchstens die letzten Stellen in cac:PaymentMeans/cac:CardAccount/cbc:PrimaryAccountNumberID (UBL) beziehungsweise ram:ApplicableTradeSettlementFinancialCard/ram:ID (CII). Die Maskierung gehört in die Erzeugung, nicht in eine spätere Bereinigung. Zählen Sie die Maskierungszeichen mit: „**** **** **** 1234“ hat neunzehn Zeichen und fällt durch, obwohl nichts Verwertbares darin steht. Die letzten vier Ziffern allein sind sicher.

Im XML

Ausschnitt in UBL. Der CII-Pfad steht oben im Text — dieselbe Änderung, andere Elementnamen.

Fehlerhaft

<cac:CardAccount>
  <cbc:PrimaryAccountNumberID>4111111111111111</cbc:PrimaryAccountNumberID>
  <cbc:NetworkID>NA</cbc:NetworkID>
</cac:CardAccount>

Korrigiert

<cac:CardAccount>
  <cbc:PrimaryAccountNumberID>******1111</cbc:PrimaryAccountNumberID>
  <cbc:NetworkID>NA</cbc:NetworkID>
</cac:CardAccount>

Warum tritt BR-51 auf?

Was der Validator prüft

Wie behebt man BR-51?

Im XML

Verwandte Regeln