Release notes for PINT Self-Billing

Change 3 – IBR-044:

Previous Behavior: The rule was declared in the cac:AllowanceCharge[cbc:ChargeIndicator = true()] rule without a level condition and was therefore evaluated for document level charges as well as for Invoice line charges. A document level charge without a reason triggered both IBR-038 and IBR-044, reporting the same defect twice with different business terms.

New Behavior: The condition or not(exists(ancestor::cac:InvoiceLine|ancestor::cac:CreditNoteLine)) has been added, so that the rule is only evaluated for charges nested in cac:InvoiceLine or cac:CreditNoteLine.

Justification: Document level charges are covered by IBR-038 and line level charges by IBR-044. The corrected rule now uses the same construction as IBR-042 and IBR-043, which restrict the corresponding line level allowance rules in the same way.

Change 4 – IBR-056 and IBR-SR-57:

Previous Behavior: The Syntax Binding gives cac:TaxRepresentativeParty/cac:PartyTaxScheme and its cbc:CompanyID child a cardinality of 0..1, following an approved change that made the Seller tax representative tax identifier (ibt-063) optional. IBR-056 required cac:PartyTaxScheme/cbc:CompanyID to be present, and IBR-SR-57 applied to every cac:PartyTaxScheme in the document, including the one under cac:TaxRepresentativeParty. An instance that specified a cac:TaxRepresentativeParty/cac:PartyTaxScheme without a cbc:CompanyID child therefore triggered two fatal errors, even though the Syntax Binding permitted it.

New Behavior: IBR-056 has been removed. The context of IBR-SR-57 has been changed from //cac:PartyTaxScheme to //cac:PartyTaxScheme[not(ancestor::cac:TaxRepresentativeParty)]. The rule continues to apply unchanged to the Seller, the Buyer and any other party.

Justification: Restricting the rule context is preferred over adding an exception to the test expression, because any assertion added to this rule in a future release is then automatically scoped correctly. The uniqueness of ibt-063 remains enforced by IBR-SR-23, and the number of cac:PartyTaxScheme elements under the tax representative is now enforced by the new IBR-SR-64.

Related action item: IBR-056 has been removed.

Change 5 – IBR-079 evaluated first in the UBL-model pattern:

Previous Behavior: The rule was declared near the end of the UBL-model pattern. In Schematron, only the first rule of a pattern whose context matches an element is evaluated for that element. Any empty element that was already matched by an earlier rule therefore escaped the empty element check. As an example, an Item standard identifier (ibt-157) consisting only of blank spaces passed validation, because cac:InvoiceLine/cac:Item/cac:StandardItemIdentification/cbc:ID is matched by the IBR-064 rule, which is declared earlier in the pattern.

New Behavior: IBR-079 is now the first rule of the UBL-model pattern and is therefore evaluated for every empty element in the document. A comment has been added to the Schematron source recording that the position of this rule is significant and must be preserved.

Justification: This is a rule precedence issue rather than a defect in the rule expression itself, which is unchanged. Placing the rule first also ensures that an empty element is reported once, with the empty element message, rather than with a format or scheme message that is not meaningful for an element that has no value.

This change affects validation behaviour and is independent from Change 2, which makes the same rule visible in the semantic model documentation without touching the Schematron.

Related action item: verify that outgoing documents contain no empty elements.

Change 6 – IBR-073:

Previous Behavior: The rule validated the YYYY-MM-DD format of cbc:IssueDate, cbc:DueDate, cbc:TaxPointDate, cbc:StartDate, cbc:EndDate and cbc:ActualDeliveryDate. cac:PrepaidPayment/cbc:ReceivedDate (ibt-181) and cac:PaymentTerms/cbc:InstallmentDueDate (ibt-177) were not part of the rule context, so an incorrectly formatted value in either element passed validation.

New Behavior: cbc:ReceivedDate and cbc:InstallmentDueDate have been added to the rule context, and ibt-177 and ibt-181 have been added to the error message.

Justification: Both business terms are of datatype Date and must therefore follow the same format requirement as every other date in the specification.

Related action item: verify the newly validated elements.

Change 7 – IBR-126 and IBR-CL-03:

Previous Behavior: IBR-126 validated that all amount currencyID attributes equal the Invoice currency code (ibt-005). cac:PrepaidPayment/cbc:PaidAmount (ibt-180) and cac:InvoiceLine/cac:Item/cac:ClassifiedTaxCategory/cbc:PerUnitAmount (ibt-166) were not part of the rule context, so an amount stated in a currency other than the document currency passed validation. The same two elements were also absent from the context of IBR-CL-03, so their currencyID attribute was not validated against ISO 4217 either.

New Behavior: cbc:PaidAmount and cbc:PerUnitAmount have been added to the context of both rules.

Justification: Both business terms are always expressed in the document currency and must therefore be validated in the same way as every other amount in the specification. The extension of IBR-CL-03 keeps code list validation consistent with IBR-126.

Related action item: verify the newly validated elements.

Change 12 – IBR-SR-23:

Previous Behavior: The rule was declared in the cac:TaxRepresentativeParty rule with the test expression count(cac:Party/cac:PartyTaxScheme/cbc:CompanyID) ⇐ 1. The UBL 2.1 schema defines no cac:Party child element for cac:TaxRepresentativeParty, so the counted node set was always empty and the rule could never fail. An instance specifying more than one Seller tax representative tax identifier (ibt-063) therefore passed validation.

New Behavior: The test expression has been corrected to count(cac:PartyTaxScheme/cbc:CompanyID) ⇐ 1.

Justification: The corrected XPath matches the structure defined in the Syntax Binding, where cac:PartyTaxScheme is a direct child of cac:TaxRepresentativeParty.

Change 9 – IBR-017, IBR-105, IBR-106 and IBR-SR-19:

Previous Behavior: IBR-017 established that the Payee (ibg-10) must be different from the Seller (ibg-04) by comparing the Payee name with cac:AccountingSupplierParty/cac:Party/cac:PartyName/cbc:Name, which is the Seller trading name (ibt-028) and not the Seller name (ibt-027) referred to in the rule text. Party identifiers were compared by value only, so identifiers issued under different schemes were treated as equal. IBR-105, IBR-106 and IBR-SR-19 each contained the alternative condition or cac:PartyName/cbc:Name = ../cac:AccountingSupplierParty/cac:Party/cac:PartyLegalEntity/cbc:RegistrationName, which disabled the cardinality check whenever the Payee name matched the Seller name. As a result, neither the difference between the Payee and the Seller nor the maximum occurrence of the Payee legal identifier (ibt-061) was correctly enforced.

New Behavior: IBR-017 now compares the Payee and the Seller in the following order of precedence:

Comparison is case insensitive and whitespace normalised. The alternative condition has been removed from IBR-105, IBR-106 and IBR-SR-19, and their messages have been simplified accordingly.

Justification: Names are unreliable for comparison because of spelling, case and abbreviation variants, so registered identifiers are used first and the name is retained only as a last resort. Once IBR-017 requires the Payee to be different from the Seller, the alternative condition in the three cardinality rules is no longer meaningful and was preventing those rules from reporting genuine violations.

Related action item: verify Payee implementations.

Change 19 – IBR-124 and IBR-CO-14:

Previous Behavior: Both rules were declared in a rule whose context was /ubl:Invoice/cac:TaxTotal | /cn:CreditNote/cac:Taxtotal. The Credit Note branch used cac:Taxtotal with a lower-case t, which does not match the UBL 2.1 element name cac:TaxTotal. Neither rule was therefore evaluated for any Credit Note.

New Behavior: The rule context has been corrected to /ubl:Invoice/cac:TaxTotal | /cn:CreditNote/cac:TaxTotal.

Justification: XML element names are case sensitive. Both rules are Shared rules and are intended to apply to Invoices and Credit Notes alike.

Related action item: verify Credit Note implementations.

Change 10 – New cardinality rules (IBR-SR-64 to IBR-SR-70):

Previous Behavior: Following the design decision of keeping the semantic model independent from the syntax used to implement it, cardinality is enforced by Schematron validation rather than by the XML schema. For a number of elements the Syntax Binding specified a maximum cardinality of one, while the UBL 2.1 schema declares them maxOccurs="unbounded" and no Schematron rule enforced the restriction. Instances repeating those elements passed validation.

New Behavior: The Syntax Binding of the Invoice and of the Credit Note has been compared element by element against the UBL 2.1 schema. Seven elements were found to be restricted by PINT and unbounded in UBL 2.1 without a corresponding Schematron rule, and seven rules have been added to cover them: IBR-SR-64 to IBR-SR-70. All other elements restricted by the Syntax Binding were found to be covered by an existing rule.

Justification: Schematron validation is the only place where these cardinalities can be enforced, so any gap allows a non conformant instance to pass validation.

Related action item: review the new rules.

Change 1 – Decimal places in invoice amounts (IBR-091, IBR-121, IBR-122, IBR-123, IBR-124, IBR-125, IBR-CO-10 to IBR-CO-16):

Previous Behavior: Document level amounts were limited to a fixed maximum of 2 decimals, the same for every currency, and the totals arithmetic in the calculation rules rounded to 2 decimals with a hard coded round(x * 10 * 10) div 100. ISO 4217 defines an official number of minor units for every currency, and for seven currencies that number is 3: BHD, IQD, JOD, KWD, LYD, OMR and TND. An Omani invoice total of 1245.575 (1 Rial = 1000 baisa) was therefore rejected, even though the identical precision was accepted on the Invoice lines, which carry no decimal limit at all. Two accounting units, CLF and UYW, officially use 4 decimals and were limited in the same way.

New Behavior: The maximum number of decimals allowed for a document level amount is the official ISO 4217 precision of the applicable currency, and the calculation rules round to that same precision. Three helper functions have been added to the Schematron:

The currency of a document level total is taken from the Invoice currency code (ibt-005), and for cac:TaxTotal from the currencyID of the tax amount, so that a total stated in the Tax accounting currency (ibt-006) is judged against that currency.

Invoice line amounts are not affected. No rule constrains the number of decimals on an Invoice line amount today and none has been added. The six maximum-decimals rules apply to cac:LegalMonetaryTotal and cac:TaxTotal only. Aligning line item precision with the currency is not part of this release.

Justification: Currencies with 0 official decimals, and codes with no defined precision such as precious metals and IMF units, deliberately return 2 and are therefore treated exactly as they are today. For the 139 currencies that officially use 2 decimals, u:round returns the same value as the previous expression and u:currencyDecimals returns 2, so every invoice that is valid today remains valid. Deriving the limit from ISO 4217 rather than raising it to 3 for everyone means no currency is given more precision than it actually has, and the same request from Bahrain, Kuwait, Jordan, Iraq, Libya or Tunisia is already answered. Invoice line amounts continue to accept any number of decimals, unchanged from today.

Related action items: 3 decimal currencies, unchanged currencies, Invoice line amounts and ISO 4217 maintenance.

Change 2 – IBR-079 in the semantic model:

Previous Behavior: IBR-079 applies to every element of the document, but it was not referenced by any entry of the semantic model. It therefore did not appear under the Rules tab of any business group, and an implementer reading the specification for a group had no indication that its elements must not be empty.

New Behavior: IBR-079 has been added to the rule: list of every business group (ibg-nn) that carries child entries: 37 groups in the Invoice semantic model and 36 in the Credit Note semantic model. Where a group had no rule: list, one was created. Individual business terms are deliberately not linked, so the rule is documented once per segment rather than on every element of the document.

The last of those groups additionally carries a relatesTo: list naming all the other groups. The Rules page renders a single Targeted Semantic Element per rule, taken from the last rule: entry found for that rule identifier, while Related Semantic Elements is rendered as a full list. Without the relatesTo: list the Rules page for IBR-079 would name one group out of 37. This is a documentation workaround only and can be removed once the Rules page aggregates the targeted elements of a rule; the same limitation applies to IBR-068, IBR-073, IBR-084, IBR-126 and every other rule that is referenced from more than one semantic element.

Justification: A rule that applies to the whole document is of little use to an implementer if it is not visible anywhere in the specification. Linking it to the segments makes the requirement discoverable at the point where an implementer looks for it, without repeating the same rule on every business term. No Schematron logic was changed by this: the rule itself is unchanged, only its documentation links. This change is independent from Change 5, which corrects the position of the same rule in the Schematron and does affect validation behaviour.

Change 15 – Saxon warnings in the helper functions:

Previous Behavior: The helper functions u:gln, u:mod11, u:slack, u:mod97-0208 and u:abn are declared as="xs:boolean" and returned their result using xsl:value-of. xsl:value-of constructs a text node, which then has to be atomised and converted to the declared return type. Saxon reports a warning for each of these functions when the validation artefact is compiled.

New Behavior: xsl:value-of has been replaced with xsl:sequence in all five functions, in the Schematron source and in the generated XSLT.

Justification: xsl:sequence returns the boolean value directly, which matches the declared return type and removes the warnings. The evaluated result of each function is unchanged.

IBR-127:

Previous Behavior: The rule validating Swedish organization numbers existed but was not visible under the Rules tab and was not clearly linked to all applicable elements.

New Behavior: The rule is now correctly displayed under the Rules tab and linked to endpoints, party identification, and legal entity identifiers using schemeID 0007.

Justification: This change improves rule visibility and ensures consistent validation across all applicable business terms without altering the validation logic itself.

IBR-SR-45:

Previous Behavior: Schematron validation enforced that cbc:PaymentDueDate (ibt-009) MUST occur at most once in the document.

New Behavior: The Schematron rule enforcing the maximum occurrence of cbc:PaymentDueDate has been removed.

Justification: The UBL 2.1 schema already restricts cbc:PaymentDueDate to zero or one occurrence. Maintaining this rule in Schematron duplicated schema-level validation and added no additional implementation value.

IBR-082:

Previous Behavior: The allowance/charge indicator rule existed but was not visible under the Rules tab and was not consistently linked at document and line level.

New Behavior: The rule validating cbc:ChargeIndicator is now correctly displayed under the Rules tab and linked to Allowance/Charge Amount at both document and line level.

Justification: This ensures consistent validation of boolean values and improves transparency for implementers without changing the underlying business requirement.

IBR-004:

Previous Behavior: The rule validated presence of ibt-003, but the error message referenced only invoices:

An Invoice MUST have an Invoice type code (ibt-003).

This could be misleading when the same rule was triggered for credit notes.

New Behavior: The error message has been updated to explicitly cover both document types:

[ibr-004]-A Self-Billed Invoice MUST have an Self-Billed Invoice type code (ibt-003) / A Self-Billed Credit note MUST have a Self-Billed Credit note Type code (ibt-003).

Justification: This change improves diagnostic clarity by aligning the error message with the rule’s actual scope across both self-billed invoices and self-billed credit notes, without changing the validation logic itself.

IBR-CL-26:

Previous Behavior: The ISO 6523 ICD code list value 0244 was defined without a required trailing space in the validation artefact. As a result, instances containing the value `0244 ` (with the correct trailing space as defined in the maintained code list) could incorrectly fail validation.

New Behavior: A trailing space has been added to the ISO 6523 ICD code list value `0244 ` in the validation artefact. Validation now correctly aligns with the maintained ISO 6523 ICD code list representation.

Justification: The omission of the trailing space was a formatting inconsistency in the validation artefact. Adding the space ensures full consistency with the maintained ISO 6523 ICD code list and prevents unintended validation failures due to whitespace mismatches.

Code List Alignment (Schematron):

Previous Behavior: Schematron validation enforced code list values based on the previous versions of ISO 4217, ICD, and EAS code lists.

New Behavior: Validation artefacts have been updated to reflect the latest code list versions:

Justification: Ensures full alignment between maintained code lists and Schematron validation artefacts, preventing validation inconsistencies and supporting newly introduced identifiers and currency codes.

IBR-126:

Previous Behavior: The rule enforced that all amount currencyID attributes must match the DocumentCurrencyCode, with no exceptions for amounts inside cac:ItemPriceExtension. As a result, invoices using cac:ItemPriceExtension to carry line-level amounts in the Tax Accounting Currency (ibt-006) would incorrectly trigger a fatal validation error.

New Behavior: Amounts that are descendants of cac:ItemPriceExtension are now excluded from the ibr-126 check. All other amount elements continue to be validated against the DocumentCurrencyCode as before.

Justification: Some country extensions use cac:ItemPriceExtension to report line-level amounts in the Tax Accounting Currency (ibt-006). Since this is a shared rule, no country-specific currency enforcement has been added. Currency validation within cac:ItemPriceExtension remains the responsibility of the relevant country extension rules.