Rule at a Glance
| ID | Severity | Context (XPath) |
|---|---|---|
| Series ref. BR-104 | Schematron ID: ibr-sr-05 | Fatal (error) | cac:PaymentTerms |
Assert text: [ibr-sr-05]-Payment terms (ibt-020) MUST occur maximum once.
Test: count(cbc:Note) <= 1
Classification
Transaction Data. The rule checks the shape of the payment terms block as assembled for one invoice, not how payment terms are configured or stored in the source system.
What the Rule Is Checking
Payment Terms (IBT-020) is a free-text description of the invoice's payment conditions — net terms, early-settlement discount conditions, or similar wording — carried in a single cbc:Note element under cac:PaymentTerms. The rule counts how many Note elements appear in that block and fails if there is more than one. Zero is permitted — payment terms are not mandatory on every invoice — but the field cannot carry two competing descriptions of the same condition.
Why This Rule Exists
Payment terms text is read by both a human accounts-payable reviewer and, increasingly, by automated AP matching logic that parses due-date and discount conditions out of the note. Two Note elements under the same payment terms block create an ambiguity that neither reading path can resolve safely: which note is authoritative if a 30-day term appears in one and a 45-day term in the other. Constraining the field to a single occurrence forces the sender to consolidate the payment condition into one unambiguous statement before the invoice is transmitted, rather than leaving two partial or conflicting descriptions for the recipient to reconcile.
UAE Data Example
PASSES ✓
<cac:PaymentTerms>
<cbc:Note>Payment due within 30 days of invoice date. 2% discount if paid within 10 days.</cbc:Note>
</cac:PaymentTerms>FAILS ✗
<cac:PaymentTerms>
<cbc:Note>Payment due within 30 days of invoice date.</cbc:Note>
<cbc:Note>2% discount if paid within 10 days.</cbc:Note>
</cac:PaymentTerms>The same underlying condition is split across two separate Note elements instead of being consolidated into one. The payment condition itself is accurate; the failure is purely structural.
What Your ERP / IT Team Must Ensure
- Check how the ERP's payment terms configuration maps to the invoice mapping layer — systems that store net-terms text and discount-terms text as separate fields internally need those concatenated into a single note before serialisation, not written out as two elements.
- Standardise the wording template used to combine multiple payment conditions into one note, so the consolidated text stays readable rather than becoming a run-on string of unrelated clauses.
- Test invoices where payment terms are set at both a customer master level and an order level, since dual-source configurations are a common cause of two notes reaching the mapping layer instead of one merged value.
- Remember this rule permits zero occurrences — if payment terms genuinely do not apply to a transaction, omitting the block entirely is valid; the failure only occurs when more than one note is present.