BR-51: Replace the full card number with its last four digits

The short answer

BR-51 is a warning, reported when cac:PaymentMeans/cac:CardAccount/cbc:PrimaryAccountNumberID holds more than 10 characters once leading and trailing spaces are removed. Replace the value with a truncated card number: the last four digits are enough for the buyer to recognise which card was used.

The document is still valid and is not rejected for this. The warning exists because a full card number should not travel in an invoice, which is stored and passed on by several parties; treat it as a data handling problem even though delivery is not blocked.

What the rule checks

The rule reads each cbc:PrimaryAccountNumberID inside a cac:CardAccount of a payment means and counts its characters after trimming. Ten or fewer passes; eleven or more is reported.

It counts characters, not digits. A masked value such as 411111XXXXXX1111 is sixteen characters long and was reported when tried, while XXXX1111 was not; the same held with asterisks as the mask.

Spaces inside the value count too. 4111 1111 1111 1111 was reported when tried, while spaces around a ten-character value were ignored.

Nothing else about the value is examined: not whether it is masked, not whether it is a real card number. Ten unmasked digits passed without a warning when tried.

However long the number, the outcome stays valid. This is a warning in the EN 16931 layer, and the recorded example passes every layer.

How an integration ends up here

Possible causes, from the shape of the rule rather than from measured usage:

• The card number is copied from an order or payment record where it was captured in full, instead of from the truncated value the payment provider returns.
• The provider's masked string, with a mask character in place of each hidden digit, is written as it is and keeps the full length.
• A number formatted with spaces between the groups is used for the XML as well as for display.

How to fix it

1. Take the last four digits from the payment provider's response or its masked card reference, not from any store of the full number.
2. Write only those digits to cbc:PrimaryAccountNumberID, with no mask characters or spaces. Leave cbc:NetworkID and cbc:HolderName as they are.
3. Do not remove the element to silence the warning. UBL requires it inside cac:CardAccount, and leaving it out failed the XSD layer when tried.
4. If the full number reached the invoicing system, remove it there as well; the invoice XML is only one of the places it would otherwise be copied to.

Validate your corrected invoice

Before and after

These are fragments, not complete documents. The complete synthetic documents they come from are linked below.

Fragment of the invoice with the warning: the card account carries all sixteen digits of a test card number

<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>

Fragment of the corrected invoice: only the last four digits are sent

<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>

The invoice with the warning carries 4111111111111111, a widely published test card number, where the corrected invoice carries its last four digits, 1111; nothing else differs. That invoice reports only this warning and is valid on every layer. With a real card, the same file would have handed the full number to everyone who receives or stores the invoice.

Where it applies

• Applies to UBL Invoice and CreditNote alike. A credit note with a sixteen-digit card number gave the same warning when tried.
• The rule is not tied to a payment means code: it runs wherever a cac:CardAccount appears. For card payments use 48 (bank card), 54 (credit card) or 55 (debit card); with code 30 and a card account, BR-61 was reported as well when tried, because a credit transfer needs a payee account.
• An empty cbc:PrimaryAccountNumberID does not raise this warning. It fails PEPPOL-EN16931-R008, which is fatal.
• EN 16931 bases this limit on card industry security standards, which restrict how much of a card number may be shown. The validator checks only the length; passing it says nothing about compliance with those standards.

Related rules

• BR-CL-16 checks the payment means code, where card payments use 48, 54 or 55
• BR-61 is reported as well when a card account sits under credit transfer code 30
• PEPPOL-EN16931-R008 rejects an empty card number element, which this warning does not cover
• Browse every rule in the reference
• Background: Understanding EN 16931 validation errors

Scope and source

Written for Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, as applied to UBL 2.1 Invoice and CreditNote documents. Other profiles, syntaxes and releases can define this identifier differently. Guidance version 2026-09-24.1: source checked 2026-09-24, explanation last updated 2026-09-24.

The official definition of BR-51 carries the normative wording and test. This page is our explanation of it, not a copy.

Guidance does not change the engine verdict. Fixing this finding does not mean the document passes every layer, and validation does not certify legal or tax compliance or transmit a document over Peppol.