Attestwire › Rule reference › BR-51

BR-51 An invoice may show at most the first six and last four card digits

noun · EN 16931 · warning · BT-87

Your invoice carries a warning because it shows more of a payment card number than the standard allows. An invoice may show at most the first six and the last four digits, ten characters in all, and most invoices need only the last four. In the standard the field is BT-87, and BR-51 is the rule that limits it.

Business term

BT-87 — Payment card primary account number

Severity

warning

Applies to

All profiles

The fix

Truncate the number before it reaches the invoice: set payment.card.primaryAccountNumber to the last four digits, or to the first six and the last four. Never store or send the full number in this field.

What the rule requires

The payment card primary account number (BT-87) must never be written out in full. The card industry’s security standard (PCI DSS) allows at most the first six and the last four digits to be displayed, so BT-87 holds at most ten characters.

The field exists so that your customer can match the invoice to a charge on their card statement. For that, the last four digits are usually enough.

In this library the field is payment.card.primaryAccountNumber.

In accordance with card payments security standards an invoice should never include a full card primary account number (BT-87). 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.

A passing value

"card": { "primaryAccountNumber": "4111111111", "holderName": "M Mustermann" }

Why it exists

An invoice is forwarded, printed, archived and emailed by people who never think of it as cardholder data. A full card number inside one puts every system it passes through into the scope of PCI DSS, and if it leaks, the disclosure and the fines are yours. The rule keeps card data out of a document that was never built to protect it.

What the library returns

The full error returned by @attestwire/en16931. It includes the rule ID, affected field and suggested correction. Developers can use this object in their application:

{
  "rule": "BR-51",
  "field": "BT-87",
  "severity": "warning",
  "message": "The payment card primary account number (BT-87) is 16 characters long, and BR-51 admits at most 10. The PCI Security Standards Council permits an invoice to show the first six digits and the last four and nothing else, which is where the ten comes from. This is a warning rather than an error, so the document will be accepted — but an invoice is forwarded, archived, printed and emailed by people who never think of it as cardholder data, and a full PAN inside one puts every system it touches into PCI DSS scope. If it leaks, the disclosure obligation and the card-scheme fines are yours, not the validator's.",
  "fix": "Truncate before you build the payload: set payment.card.primaryAccountNumber to the first six and last four digits only, e.g. \"411111\" + \"1111\" as \"4111111111\", or simply the last four. Never store or transmit the full number here.",
  "example": "\"card\": { \"primaryAccountNumber\": \"4111111111\", \"holderName\": \"M Mustermann\" }",
  "xpath": "/ubl:Invoice/cac:PaymentMeans/cac:CardAccount/cbc:PrimaryAccountNumberID",
  "docsUrl": "https://attestwire.com/rules/BR-51"
}

xpath is always a UBL path. On a CII invoice, look for the matching CII field instead.

How our check differs

See also: BR-DE-24-a — the XRechnung rule that requires the card group for card payments.