Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-51 | Fatal (error) | /ubl:Invoice | /cn:CreditNote |
Schematron ID: ibr-066 | Field: cac:PaymentMeans/cac:CardAccount (Payment Card Information, IBG-18) |
||
Classification
Syntax & Integration — a cardinality constraint on document structure. UBL 2.1 syntax happily allows the repetition; PINT-AE forbids it, and the gap between what the schema permits and what the rule allows is exactly where integration code goes wrong.
What the Rule Is Checking
The assert counts card blocks across the whole document: "An Invoice MUST contain maximum one Payment Card account (ibg-18)." An invoice may carry several cac:PaymentMeans elements — offering a bank transfer and a card option side by side is legitimate — but only one of them may contain a cac:CardAccount group. A second card block anywhere in the document is a fatal error.
Why This Rule Exists
Payment card information on an invoice records how the settlement was or will be made against one card. Two card accounts on a single invoice would leave the buyer's systems, and any downstream reconciliation, unable to say which card the payment belongs to. The constraint keeps the payment instruction machine-readable as a single unambiguous fact rather than a menu the receiving system must interpret.
Standard / Code List
Which payment means code triggers card data at all comes from the UNCL4461 list — covered in UNCL4461 Payment Means Codes in PINT-AE. The card block itself carries the primary account number (masked) and the network.
UAE Data Example
PASSES ✓: One cac:PaymentMeans with code 54 (credit card) containing a single cac:CardAccount with a masked PAN, alongside a second cac:PaymentMeans for bank transfer with no card block.
FAILS ✗: A POS-integrated billing flow where a payment was taken in two card transactions — a deposit and a balance — and the extract emits one cac:CardAccount per settlement record. The schema validates; ibr-066 rejects.
What Your ERP / IT Team Must Ensure
Map card details from the invoice-level payment terms, never by looping over settlement or clearing records. If a real business flow settles one invoice across multiple cards, emit the card block for one settlement or omit card data entirely — the e-invoice is not the payment ledger. Retail and hospitality flows where the payment engine sits outside the billing module deserve a specific test case, because that is where per-transaction card records leak into the invoice extract.
Related Rules
The same cardinality pattern applies to direct debit mandates in BR-52 (ibr-067). The payment means code list itself is covered in the UNCL4461 reference linked above.