BR-51In accordance with card payments security standards an invoice should never include a full card primary account number (BT-87).
Official rule text
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 words this rule differently in the two files. Above is the UBL wording; here is the other:
Wording 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.
A full card primary account number must never appear in an invoice — implemented as a plain length limit: at most ten characters in the field. That matches the first six and last four digits PCI DSS allows at most.
- Severity
- Error
- Applies to
- CII, UBL
- Rule set
- v2026-08-31
- Checked on
Written and checked against the official KoSIT rule set by Dmytro Yalanskyi, NormAPI.
Why does BR-51 happen?
The payment system holds the number in full and the mapping copies it across unchanged, because the target field has exactly that name. A number then travels into a document that is emailed and archived for years. Note that the rule text above cites BT-97, which is the document level allowance reason. The shipped rule set contradicts itself here: the UBL copy of BR-51 says BT-87, the CII copy says BT-97. Both mean and check the card number.
What the validator checks
The expression the official KoSIT rule set evaluates — not paraphrased, but read from the Schematron file it ships. UBL and CII address different document trees, so the same rule reads differently in each.
- UBL
string-length(normalize-space(.))<=10- CII
string-length(normalize-space(ram:ID)) <= 10
Source: rule set v2026-08-31
How do you fix BR-51?
Mask before writing and transmit at most the trailing digits in cac:PaymentMeans/cac:CardAccount/cbc:PrimaryAccountNumberID in UBL, ram:ApplicableTradeSettlementFinancialCard/ram:ID in CII. The masking belongs in the generation, not in a later clean-up. Count the masking characters while you do: “**** **** **** 1234” is nineteen characters and fails, though it reveals nothing. The last four digits alone are safe.
In the XML
A UBL fragment. The CII path is named above — same change, different element names.
<cac:CardAccount>
<cbc:PrimaryAccountNumberID>4111111111111111</cbc:PrimaryAccountNumberID>
<cbc:NetworkID>NA</cbc:NetworkID>
</cac:CardAccount><cac:CardAccount>
<cbc:PrimaryAccountNumberID>******1111</cbc:PrimaryAccountNumberID>
<cbc:NetworkID>NA</cbc:NetworkID>
</cac:CardAccount>Related rules
NormAPI provides technical validation, not tax or legal advice.