Zum Inhalt springen

Ironfang Finance - Regelreferenz

BR-51: Die vollständige Kartennummer durch ihre letzten vier Ziffern ersetzen

Warnung: cbc:PrimaryAccountNumberID ist länger als 10 Zeichen, was auf eine vollständige Kartennummer hindeutet. Übermitteln Sie die letzten vier Ziffern; die Rechnung bleibt gültig.

EN 16931Warnung: Das Dokument bleibt gültigKernfelder

Auf dieser Seite

Die kurze Antwort

BR-51 ist eine Warnung und wird gemeldet, wenn cac:PaymentMeans/cac:CardAccount/cbc:PrimaryAccountNumberID nach dem Entfernen führender und nachgestellter Leerzeichen mehr als 10 Zeichen enthält. Ersetzen Sie den Wert durch eine gekürzte Kartennummer: Die letzten vier Ziffern genügen dem Käufer, um zu erkennen, welche Karte verwendet wurde.

Das Dokument ist weiterhin gültig und wird deswegen nicht abgewiesen. Die Warnung existiert, weil eine vollständige Kartennummer nicht in einer Rechnung unterwegs sein sollte, die von mehreren Beteiligten gespeichert und weitergegeben wird; behandeln Sie es als Problem des Datenumgangs, auch wenn die Zustellung nicht blockiert wird.

Was die Regel prüft

Die Regel liest jede cbc:PrimaryAccountNumberID innerhalb eines cac:CardAccount eines Zahlungsmittels und zählt ihre Zeichen nach dem Entfernen von Leerraum am Rand. Zehn oder weniger bestehen; elf oder mehr werden gemeldet.

Sie zählt Zeichen, nicht Ziffern. Ein maskierter Wert wie 411111XXXXXX1111 ist sechzehn Zeichen lang und wurde im Versuch gemeldet, XXXX1111 dagegen nicht; dasselbe galt mit Sternchen als Maskierung.

Auch Leerzeichen innerhalb des Werts zählen. 4111 1111 1111 1111 wurde im Versuch gemeldet, während Leerzeichen um einen zehnstelligen Wert ignoriert wurden.

Sonst wird nichts am Wert untersucht: weder, ob er maskiert ist, noch, ob er eine echte Kartennummer ist. Zehn unmaskierte Ziffern bestanden im Versuch ohne Warnung.

Wie lang die Nummer auch ist, das Ergebnis bleibt gültig. Dies ist eine Warnung im Prüfschritt EN 16931, und das aufgezeichnete Beispiel besteht jeden Prüfschritt.

BegriffBedeutungUBL-Element
BT-81Code für die Zahlungsartcac:PaymentMeans/cbc:PaymentMeansCode
BT-87Primäre Kontonummer der Zahlungskartecac:PaymentMeans/cac:CardAccount/cbc:PrimaryAccountNumberID

Wie es in einer Integration dazu kommt

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

  • Die Kartennummer wird aus einem Bestell- oder Zahlungsdatensatz kopiert, in dem sie vollständig erfasst wurde, statt aus dem gekürzten Wert, den der Zahlungsdienstleister zurückgibt.
  • Die maskierte Zeichenkette des Dienstleisters, mit einem Maskierungszeichen an der Stelle jeder verborgenen Ziffer, wird unverändert geschrieben und behält die volle Länge.
  • Eine mit Leerzeichen zwischen den Gruppen formatierte Nummer wird sowohl für die Anzeige als auch für das XML verwendet.

So korrigieren Sie das Dokument

  1. Nehmen Sie die letzten vier Ziffern aus der Antwort des Zahlungsdienstleisters oder aus seiner maskierten Kartenreferenz, nicht aus einem Speicher der vollständigen Nummer.
  2. Schreiben Sie nur diese Ziffern in cbc:PrimaryAccountNumberID, ohne Maskierungszeichen oder Leerzeichen. Lassen Sie cbc:NetworkID und cbc:HolderName unverändert.
  3. Entfernen Sie das Element nicht, um die Warnung zum Schweigen zu bringen. UBL verlangt es innerhalb von cac:CardAccount, und ohne es scheiterte das Dokument im Versuch am XSD-Prüfschritt.
  4. Wenn die vollständige Nummer das Rechnungssystem erreicht hat, entfernen Sie sie auch dort; das Rechnungs-XML ist nur einer der Orte, an die sie sonst kopiert würde.

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 Rechnung mit der Warnung: Das Kartenkonto enthält alle sechzehn Ziffern einer Testkartennummer

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>48</cbc:PaymentMeansCode>
  <cac:CardAccount>
    <cbc:PrimaryAccountNumberID>4111111111111111</cbc:PrimaryAccountNumberID>
    <cbc:NetworkID>VISA</cbc:NetworkID>
    <cbc:HolderName>Example Buyer</cbc:HolderName>
  </cac:CardAccount>
</cac:PaymentMeans>

Ausschnitt der korrigierten Rechnung: Nur die letzten vier Ziffern werden übermittelt

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>48</cbc:PaymentMeansCode>
  <cac:CardAccount>
    <cbc:PrimaryAccountNumberID>1111</cbc:PrimaryAccountNumberID>
    <cbc:NetworkID>VISA</cbc:NetworkID>
    <cbc:HolderName>Example Buyer</cbc:HolderName>
  </cac:CardAccount>
</cac:PaymentMeans>

Die Rechnung mit der Warnung enthält 4111111111111111, eine weithin veröffentlichte Testkartennummer, wo die korrigierte Rechnung deren letzte vier Ziffern enthält, 1111; sonst unterscheidet sich nichts. Diese Rechnung meldet nur diese Warnung und ist in jedem Prüfschritt gültig. Mit einer echten Karte hätte dieselbe Datei die vollständige Nummer an jeden weitergegeben, der die Rechnung empfängt oder speichert.

Was der Validator gemeldet hat

Aufgezeichnet mit phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, der Engine hinter dem kostenlosen Validator, mit synthetischen Daten. Ein aufgezeichnetes Ergebnis ist ein Regressionsnachweis für diese Dokumente, keine Zertifizierung.

Wo die Regel gilt

  • Gilt gleichermaßen für UBL Invoice und CreditNote. Eine Gutschrift mit einer sechzehnstelligen Kartennummer ergab im Versuch dieselbe Warnung.
  • Die Regel ist nicht an einen Code für die Zahlungsart gebunden: Sie läuft überall, wo ein cac:CardAccount erscheint. Verwenden Sie für Kartenzahlungen 48 (Bankkarte), 54 (Kreditkarte) oder 55 (Debitkarte); mit Code 30 und einem Kartenkonto wurde im Versuch zusätzlich BR-61 gemeldet, weil eine Überweisung ein Konto des Zahlungsempfängers braucht.
  • Eine leere cbc:PrimaryAccountNumberID löst diese Warnung nicht aus. Sie scheitert an PEPPOL-EN16931-R008, einer Regel mit dem Schweregrad fatal.
  • EN 16931 stützt diese Grenze auf Sicherheitsstandards der Kartenbranche, die einschränken, wie viel einer Kartennummer angezeigt werden darf. Der Validator prüft nur die Länge; das Bestehen dieser Prüfung sagt nichts über die Einhaltung dieser Standards aus.

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-24.1: Quelle geprüft am 2026-09-24, Erklärung zuletzt aktualisiert am 2026-09-24.

Die offizielle Definition von BR-51 (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.