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

Warning: `cbc:PrimaryAccountNumberID` is longer than 10 characters, which points to a full card number. Send the last four digits; the invoice stays valid.

- Layer: EN 16931
- Severity: warning (the document stays valid)
- Topics: Core fields
- Official definition: https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-51/
- Explanation last updated: 2026-09-24

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

| Term | Meaning | UBL element |
|---|---|---|
| BT-81 | Payment means type code | `cac:PaymentMeans/cbc:PaymentMeansCode` |
| BT-87 | Payment card primary account number | `cac:PaymentMeans/cac:CardAccount/cbc:PrimaryAccountNumberID` |

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

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

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

```xml
<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.

### What the validator reported

- The invoice with the warning is valid, and reports the warning **BR-51**. The corrected document passes every layer with no findings.
  - [Download the XML with the warning](https://ironfang.uk/finance/rule-examples/BR-51-warning.xml)
  - [Download the corrected XML](https://ironfang.uk/finance/rule-examples/card-payment-valid.xml)

Recorded on phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, the engine behind the free validator, using synthetic data. A recorded result is regression evidence for these documents; it is not a certification.

## 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](https://ironfang.uk/docs/finance/rules/BR-CL-16.md)
- [BR-61 is reported as well when a card account sits under credit transfer code 30](https://ironfang.uk/docs/finance/rules/BR-61.md)
- [PEPPOL-EN16931-R008 rejects an empty card number element, which this warning does not cover](https://ironfang.uk/docs/finance/rules/PEPPOL-EN16931-R008.md)

## 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](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/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.

## Links

- [This rule as a web page](https://ironfang.uk/docs/finance/rules/BR-51)
- [Free Peppol invoice validator](https://ironfang.uk/tools/peppol-validator)
- [Rule index](https://ironfang.uk/docs/finance/rules.md)
- [Ironfang Finance API docs](https://ironfang.uk/docs/finance)
- The same rule is available to MCP clients as the tool `finance.rule.get` on https://mcp.ironfang.uk/mcp