Reference
Markdown exportBT-87 Payment card primary account number
Masked primary account number of the payment card when card payment details are referenced.
Quick answer
Delivery and payment
Delivery dates, payment means, and the operational context around settlement.
Quick actions
In plain language
Only use this in rare card-payment scenarios and never expose the full card number.
What you usually enter here
Masked card number only
Typical valid values include: 123456******1234
Optional according to EN 16931-1, but BR-51 forbids exposing the full card number. Only masked values are acceptable.
Where the field sits
- Invoice
- cac:PaymentMeans
- cac:CardAccount
- cbc:PrimaryAccountNumberIDBT-87
- rsm:CrossIndustryInvoice
- rsm:SupplyChainTradeTransaction
- ram:ApplicableHeaderTradeSettlement
- ram:SpecifiedTradeSettlementPaymentMeans
- ram:ApplicableTradeSettlementFinancialCard
- ram:IDBT-87
What goes wrong often
Avoid values like: 4111111111111111
Relevant rule codes: BR-51
Valid Examples
- 123456******1234
Invalid Examples
- 4111111111111111
XML mapping and field facts
Open the technical reference if you need XML paths, validator rule codes, legal wording, or schema-specific mapping details.
Field ID:
BT-87
Data Type:
text
Cardinality:
0..1
Requirement:
Optional
Max Length:
35 characters
XML Implementation
/Invoice/cac:PaymentMeans/cac:CardAccount/cbc:PrimaryAccountNumberID/rsm:CrossIndustryInvoice/rsm:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:SpecifiedTradeSettlementPaymentMeans/ram:ApplicableTradeSettlementFinancialCard/ram:IDValidation Rules
BR-51
BR-51
Next step
Check whether your XRechnung sets BT-87 correctly
Upload the XML file to the free validator. It applies the KoSIT rules for XRechnung 3.0 and names each finding with its rule ID, for this field for example BR-51. Creating a new invoice instead? The converter checks the invoice against the same rules and shows the findings before download.
Free, no account needed. XML file up to 2 MB.