Release notes for PINT OM Self-Billing

Version 1.0.1

Maintained by	Oman Tax Authority
Release Date	2026-07-29
Status	Final

Maintained by

Oman Tax Authority

Release Date

2026-07-29

Status

Final

Member Review amendments:

This revision of the 1.0.1 release notes incorporates the resolutions to the Oman Tax Authority (OTA) and other Members review comments, made within the Member Review cycle (no new version increment):

Transaction type (BTOM-001) bitmap retains the 1/0 encoding (0 for inactive positions); ALIGNED-IBRP-000-OM and IBR-001-OM are unchanged.
Tolerance is implemented in the Schematron only and is no longer part of the normative business-rule statements for IBR-168-OM and ALIGNED-IBRP-S-09-OM.
ALIGNED-IBRP-S-08-OM (taxable amount, IBT-116) and IBR-158-OM (total including VAT, BTOM-017) do not carry the Baisa tolerance; tolerance is confined to the VAT amount fields (IBT-117, BTOM-016).
The Tolerance-applied indicator business terms (BGOM-08, BTOM-035, BTOM-035-1, BTOM-200-OM) are excluded from OM PINT.

What’s new in this release?

Adapted all the changes from PINT General 1.1.3 to PINT OM 1.0.1:
- Schematron rules.
- Code lists updates.
- Documentation updates.
Rounding tolerance for tax-inclusive (B2C) scenarios
- Added bounded "Baisa Gap" tolerance handling (one baisa, 0.001 OMR, per invoice line) on the VAT amount fields only — BTOM-016 (IBR-168-OM) and IBT-117 (ALIGNED-IBRP-S-09-OM). The taxable amount (IBT-116) and total including VAT (BTOM-017) are not toleranced.
- Tolerance applies where systematic rounding artefacts arise from backward derivation of tax-exclusive values from tax-inclusive retail prices.
Three-tier validation outcome on the VAT amount fields
- IBR-168-OM and ALIGNED-IBRP-S-09-OM now classify each invoice as Accepted, Accepted with warning, or Rejected.
- An exact match is Accepted silently; a non-zero difference within tolerance is Accepted with warning; a difference beyond tolerance is Rejected.
- The acceptance boundary is evaluated at each field’s native precision — three decimals for the line VAT amount (BTOM-016), two decimals for the document-level VAT category tax amount (IBT-117).
No restrictions on Rounding Amount (IBT-114)
- IBT-114 (PayableRoundingAmount) is accepted as a free-form value and is not capped, equality-checked, or reconciled by any dedicated rule.
- The tolerance on IBR-168-OM and ALIGNED-IBRP-S-09-OM is applied independently of IBT-114; the sender is not required to report IBT-114 to benefit from the tolerance.
- This allows IBT-114 to absorb other rounding-off differences (for example, those arising from exchange-rate conversion).
Business Rule Logic Updates
- IBR-168-OM: the business rule states BTOM-016 (Line Item VAT amount) MUST equal IBT-131 × VAT rate. The per-line ±0.001 OMR tolerance is implemented in the Schematron only (surfaced as a warning) and is not part of the business-rule statement.
- ALIGNED-IBRP-S-09-OM: the business rule states IBT-117 (VAT category tax amount) MUST equal the sum of line VAT amounts plus charges' VAT minus allowances' VAT. The ±(0.001 × number of invoice lines) OMR tolerance is implemented in the Schematron only (surfaced as a warning).
- IBR-158-OM (BTOM-017) and ALIGNED-IBRP-S-08-OM (IBT-116) do not apply the Baisa tolerance; they retain standard exact reconciliation (two-decimal rounding only), consistent with the E/O/Z taxable-amount checks.
Business Terms excluded
- The Tolerance-applied indicator and related terms (BGOM-08, BTOM-035, BTOM-035-1, BTOM-200-OM) are excluded from OM PINT; no tolerance indicator is required or processed.
Schematron Enhancements
- Added centralized Baisa Gap tolerance constants and helper functions.
- Added warning-level assertions (IBR-168-OM-WARN, ALIGNED-IBRP-S-09-OM-WARN) that surface when a transaction is accepted within tolerance.
- Improved IBR-171-OM business rule check on current date and time.
Documentation and Validation Clarifications
- Added detailed guidance for tax-inclusive pricing and document-level rounding behaviour.
- Clarified compatibility and auditability behaviour for tax-inclusive rounding scenarios.
UUID validation corrected (IBR-002-OM, IBR-173-OM)
- IBR-002-OM (Invoice UUID, BTOM-002) previously required an RFC 4122 version 4 UUID. It now requires an RFC 4122 version 5 UUID. Version 4 is no longer accepted for BTOM-002.
- IBR-173-OM (Seller UUID, BTOM-004) previously tested ^[A-Za-z0-9-]+$, which is not a UUID check — it accepted any string of letters, digits and dashes. It now enforces proper UUID structure, accepting version 5.
- No other UUID-bearing element is format-checked.
UUID versions per business term
- BTOM-002 (Invoice UUID): version 5 only.
- BTOM-004 (Seller UUID): version 5 only.
BGOM-03 (Prepayment Document Reference) mapping change
- BGOM-03 mapping is changed from cac:OriginatorDocumentReference to cac:AdditionalDocumentReference with cbc:DocumentTypeCode as PDR.
Schematron review corrections
- IBR-158-OM (Total amount including VAT): aligned with IBR-038-OM — a simplified tax invoice line that omits the Line Item VAT amount (BTOM-016) is no longer rejected. The calculation now guards its numeric inputs and treats a missing line VAT amount as zero.
- IBR-171-A-OM: the YYYY-MM-DD date-format check now also covers the Payment due date (IBT-009, cbc:DueDate), matching the rule’s stated scope.
- Added defensive castable as xs:decimal guards to the standard-rate VAT breakdown calculations (ALIGNED-IBRP-S-08-OM, ALIGNED-IBRP-S-09-OM).
- Corrected diagnostic/message text and removed dead code (unused helper functions, an unused variable, and the inert debug phase / DOC-SUMMARY report). No change to validation outcomes.
Sample files
- New sample files added for tolerance logic.
- All sample UUIDs — Invoice UUID (BTOM-002) and Seller UUID (BTOM-004) — regenerated as valid RFC 4122 version 5 UUIDs; each sample now carries a distinct UUID (previously several samples shared one placeholder value, and a few carried malformed values such as r12f329f-…, which contains a non-hexadecimal character).
- Old samples updated to ensure the validation.
- Prepayment files are changed according to the BGOM-03 mapping change.

Overview

This release introduces bounded rounding-tolerance support for tax-inclusive (B2C) invoicing scenarios in PINT OM Self-Billing.

In Omani retail environments, commercial prices are typically expressed as tax-inclusive rounded values, while PINT calculations are derived using tax-exclusive arithmetic. Due to the OMR three-decimal precision model, backward derivation of net amounts may introduce a systematic rounding difference of one baisa (0.001 OMR) per invoice line.

PINT OM 1.0.1 absorbs these differences through a bounded tolerance on the VAT amount fields, without weakening validation integrity. On BTOM-016 (Line Item VAT amount) the tolerance is ±0.001 OMR per invoice line; on IBT-117 (VAT category tax amount) it is ±(0.001 × number of invoice lines) OMR. Each comparison is evaluated at the field’s native precision — three decimals for the line-level BTOM-016 and two decimals for the document-level IBT-117 — and the tolerance is applied independently of the Rounding Amount (IBT-114).

These two rules now produce a graduated outcome: an exact calculation is Accepted; a non-zero difference that remains within tolerance is Accepted with a warning, allowing the transaction to be identified; and a difference beyond tolerance is Rejected. The Rounding Amount (IBT-114 (PayableRoundingAmount)) remains available to record any residual difference for audit purposes, but no restriction is placed on its value, and it is not required for the tolerance to apply.

This release adds bounded tolerance handling to the VAT amount rules and supporting documentation while preserving existing strict validation behaviour.

Version Information

PINT General	1.1.3
PINT OM	1.0.1
Applies to	PINT OM Self-Billing
Reviewed	-

PINT General

1.1.3

PINT OM

1.0.1

Applies to

PINT OM Self-Billing

Reviewed

Changes

Rounding Amount (IBT-114) Handling

No restrictions are placed on IBT-114 (PayableRoundingAmount) in this release. Specifically, PINT OM 1.0.1 does not introduce:

a cap on the magnitude of IBT-114 relative to the number of invoice lines;
an equality requirement tying IBT-115 (PayableAmount) to IBT-112, IBT-113, and IBT-114; or
a rule requiring IBT-114 to equal a measured reconciliation gap.

Reason: the rounding amount may legitimately combine the systematic one-baisa-per-line tolerance with other rounding-off differences, including those arising from exchange-rate conversion. Constraining IBT-114 to the per-line tolerance alone would incorrectly reject otherwise valid invoices.

The 0.001 OMR tolerance continues to be enforced on the VAT calculation fields — VAT category tax amount (IBT-117) within ±0.001 × number of invoice lines, and Invoice-line VAT amounts (BTOM-016) within ±0.001 — independently of IBT-114.

UUID Validation (IBR-002-OM, IBR-173-OM)

Two rules validate a UUID, and both were incorrect — in different ways.

IBR-002-OM validated the Invoice UUID (BTOM-002) against an expression that hard-coded the version 4 nibble (…-4xxx-…), so structurally valid version 5 (name-based, SHA-1) UUIDs failed validation. BTOM-002 is now specified as a version 5 UUID.

IBR-173-OM validated the Seller UUID (BTOM-004, cbc:AdditionalAccountID) against ^[A-Za-z0-9-]+$. This is not a UUID check: it accepts any string of letters, digits and dashes (for example abc, ------, or an arbitrary account code). It let version 4 and version 5 UUIDs pass only because it let virtually everything pass. BTOM-004 now accepts version 5.

IBR-002-OM — Invoice UUID (BTOM-002), version 5 only

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-5[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$

IBR-173-OM — Seller UUID (BTOM-004), version 5

^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-5[0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}$

In both expressions the third group’s leading nibble carries the UUID version (5, or [45]), and the [89abAB] group enforces the RFC 4122 variant. No other UUID-bearing element (for example the UUIDs inside cac:OriginatorDocumentReference or cac:AdditionalDocumentReference) is format-checked.

Rule ID Syntax (XML location) Change Business Rule Reason

Rule ID	Syntax (XML location)	Change	Business Rule	Reason
IBR-002-OM	`ubl:Invoice \| cn:CreditNote` → `cbc:UUID`	Updated	The unique identifier (“UUID”, `BTOM-002`) MUST be provided and MUST be a valid UUID version 5.	The previous expression hard-coded the version 4 nibble. `BTOM-002` is specified as a name-based (version 5) UUID.
IBR-173-OM	`cac:AccountingSupplierParty/cbc:AdditionalAccountID`	Updated	If Buyer electronic address (`IBT-049`) is `997770000099`, the Seller UUID (`BTOM-004`) MUST be present and MUST be a valid UUID version 5.	The previous expression (`^[A-Za-z0-9-]+$`) accepted any alphanumeric/dash string and did not validate UUID structure at all.

IBR-002-OM

ubl:Invoice | cn:CreditNote → cbc:UUID

Updated

The unique identifier (“UUID”, BTOM-002) MUST be provided and MUST be a valid UUID version 5.

The previous expression hard-coded the version 4 nibble. BTOM-002 is specified as a name-based (version 5) UUID.

IBR-173-OM

cac:AccountingSupplierParty/cbc:AdditionalAccountID

Updated

If Buyer electronic address (IBT-049) is 997770000099, the Seller UUID (BTOM-004) MUST be present and MUST be a valid UUID version 5.

The previous expression (^[A-Za-z0-9-]+$) accepted any alphanumeric/dash string and did not validate UUID structure at all.

IBR-002-OM:

Previous Behavior: The assertion pinned the version nibble to 4, requiring a UUID version 4. A version 5 UUID failed validation.

New Behavior: The version nibble is 5. The Invoice UUID (BTOM-002) MUST be an RFC 4122 version 5 (name-based, SHA-1) UUID; version 4 is no longer accepted. The RFC 4122 variant ([89abAB]) continues to be enforced and the UUID remains mandatory.

Justification: BTOM-002 is specified as a deterministic, name-based identifier, which is what version 5 provides. Restricting the rule to version 5 makes the constraint match the specification.

IBR-173-OM:

Previous Behavior: The assertion tested matches(normalize-space(cac:AccountingSupplierParty/cbc:AdditionalAccountID), '^[A-Za-z0-9-]+$') — any non-empty string of letters, digits and dashes satisfied it. Version 4 and version 5 UUIDs passed, but so did values that are not UUIDs at all.

New Behavior: The Seller UUID (BTOM-004) is validated as a UUID whose version nibble is 5, accepting version 5. The conditional trigger (Buyer electronic address 997770000099) and the mandatory-presence check are unchanged.

Justification: The rule is stated as a Seller UUID check, so it must validate UUID structure. The previous expression tested only the character set and gave no structural guarantee. Restricting the rule to version 5 makes the constraint match the specification.

Business Rule Logic Updates

Rule ID Syntax (XML location) Change Business Rule Reason

Rule ID	Syntax (XML location)	Change	Business Rule	Reason
IBR-168-OM	Invoice line VAT calculations	Updated	`BTOM-016 (Line Item VAT amount)` MUST equal `IBT-131 × VAT rate`. (The per-line `±0.001 OMR` tolerance is implemented in the Schematron only — surfaced as a warning — and is not part of the business-rule statement. Evaluated at three-decimal precision, independently of `IBT-114`.)	Supports tax-inclusive pricing scenarios while keeping the business rule a strict equality and surfacing tolerance use through a Schematron warning.
IBR-158-OM	Invoice line totals	Clarified	`BTOM-017 (Total amount including VAT)` MUST equal line net amount plus VAT amount. No Baisa tolerance is applied; standard two-decimal rounding only.	Per OTA review: tolerance is not required on `BTOM-017`; it is confined to the VAT amount field `BTOM-016` (`IBR-168-OM`).
ALIGNED-IBRP-S-08-OM	VAT breakdown taxable amount	Clarified	`IBT-116 (VAT category taxable amount)` MUST equal the sum of line net amounts plus document-level charges minus allowances (for the category/rate). No Baisa tolerance is applied; standard two-decimal rounding only, consistent with the E/O/Z taxable-amount checks.	Per OTA review: tolerance is not required on `IBT-116`; it is confined to the VAT amount field `IBT-117` (`ALIGNED-IBRP-S-09-OM`).
ALIGNED-IBRP-S-09-OM	VAT breakdown tax amount	Updated	`IBT-117 (VAT category tax amount)` MUST equal the sum of line VAT amounts plus charges' VAT minus allowances' VAT. (The `±(0.001 × number of invoice lines) OMR` tolerance is implemented in the Schematron only — surfaced as a warning — and is not part of the business-rule statement. Evaluated at two-decimal precision, independently of `IBT-114`.)	Keeps the business rule a strict equality while surfacing tolerance use through a Schematron warning.

IBR-168-OM

Invoice line VAT calculations

Updated

BTOM-016 (Line Item VAT amount) MUST equal IBT-131 × VAT rate. (The per-line ±0.001 OMR tolerance is implemented in the Schematron only — surfaced as a warning — and is not part of the business-rule statement. Evaluated at three-decimal precision, independently of IBT-114.)

Supports tax-inclusive pricing scenarios while keeping the business rule a strict equality and surfacing tolerance use through a Schematron warning.

IBR-158-OM

Invoice line totals

Clarified

BTOM-017 (Total amount including VAT) MUST equal line net amount plus VAT amount. No Baisa tolerance is applied; standard two-decimal rounding only.

Per OTA review: tolerance is not required on BTOM-017; it is confined to the VAT amount field BTOM-016 (IBR-168-OM).

ALIGNED-IBRP-S-08-OM

VAT breakdown taxable amount

Clarified

IBT-116 (VAT category taxable amount) MUST equal the sum of line net amounts plus document-level charges minus allowances (for the category/rate). No Baisa tolerance is applied; standard two-decimal rounding only, consistent with the E/O/Z taxable-amount checks.

Per OTA review: tolerance is not required on IBT-116; it is confined to the VAT amount field IBT-117 (ALIGNED-IBRP-S-09-OM).

ALIGNED-IBRP-S-09-OM

VAT breakdown tax amount

Updated

IBT-117 (VAT category tax amount) MUST equal the sum of line VAT amounts plus charges' VAT minus allowances' VAT. (The ±(0.001 × number of invoice lines) OMR tolerance is implemented in the Schematron only — surfaced as a warning — and is not part of the business-rule statement. Evaluated at two-decimal precision, independently of IBT-114.)

Keeps the business rule a strict equality while surfacing tolerance use through a Schematron warning.

Validation Outcome Model (IBR-168-OM and ALIGNED-IBRP-S-09-OM)

The two VAT amount rules covered by the tolerance specification now resolve to one of three outcomes. Each comparison is evaluated at the field’s native precision — three decimals for the line-level BTOM-016 (IBR-168-OM) and two decimals for the document-level IBT-117 (ALIGNED-IBRP-S-09-OM):

Condition Outcome Schematron behaviour

Condition	Outcome	Schematron behaviour
The reported VAT amount equals the calculated amount exactly.	Accepted	No assertion is raised.
The difference is non-zero but within tolerance — `±0.001 OMR` per line for `BTOM-016`, or `±(0.001 × number of invoice lines) OMR` for `IBT-117`.	Accepted with warning	The warning assertion (`IBR-168-OM-WARN` / `ALIGNED-IBRP-S-09-OM-WARN`) is raised; the fatal assertion passes, so the document is not rejected.
The difference exceeds the tolerance.	Rejected	The fatal assertion (`IBR-168-OM` / `ALIGNED-IBRP-S-09-OM`) fails.

The reported VAT amount equals the calculated amount exactly.

Accepted

No assertion is raised.

The difference is non-zero but within tolerance — ±0.001 OMR per line for BTOM-016, or ±(0.001 × number of invoice lines) OMR for IBT-117.

Accepted with warning

The warning assertion (IBR-168-OM-WARN / ALIGNED-IBRP-S-09-OM-WARN) is raised; the fatal assertion passes, so the document is not rejected.

The difference exceeds the tolerance.

Rejected

The fatal assertion (IBR-168-OM / ALIGNED-IBRP-S-09-OM) fails.

The tolerance is determined entirely from the invoice arithmetic and does not depend on IBT-114 being reported. The normative business rule for both IBR-168-OM and ALIGNED-IBRP-S-09-OM remains the exact equality; the graduated outcome above is Schematron validation behaviour, not a relaxation of the business rule itself.

Schematron Enhancements

Component Change Description Rationale

Component	Change	Description	Rationale
Centralized constants	Added	Added `$baisaTolerance`, `$lineCount`, `$baisaCap`, and `$reportedRoundingAmount`.	Provides reusable centralized tolerance calculations across Schematron rules.
`u:baisaReconciled(…)`	Added	Helper function validating strict equality OR acceptance of a bounded residual difference within the Baisa cap.	Enables reusable tolerance logic for the VAT calculation rules.
`u:withinBaisaCap(…)`	Added	Helper function validating that a deviation falls within the Baisa Gap cap.	Supports reusable cap-only validation scenarios at line level.
`IBR-168-OM-WARN`, `ALIGNED-IBRP-S-09-OM-WARN`	Added	Warning-level assertions that are raised when the reported VAT amount is not exact but falls within tolerance. They use the existing `u:slack(…)` helper to test exact equality and the tolerance band.	Implements the Accepted with warning tier so tolerance use is surfaced without rejecting the document.

Centralized constants

Added

Added $baisaTolerance, $lineCount, $baisaCap, and $reportedRoundingAmount.

Provides reusable centralized tolerance calculations across Schematron rules.

u:baisaReconciled(…)

Added

Helper function validating strict equality OR acceptance of a bounded residual difference within the Baisa cap.

Enables reusable tolerance logic for the VAT calculation rules.

u:withinBaisaCap(…)

Added

Helper function validating that a deviation falls within the Baisa Gap cap.

Supports reusable cap-only validation scenarios at line level.

IBR-168-OM-WARN, ALIGNED-IBRP-S-09-OM-WARN

Added

Warning-level assertions that are raised when the reported VAT amount is not exact but falls within tolerance. They use the existing u:slack(…) helper to test exact equality and the tolerance band.

Implements the Accepted with warning tier so tolerance use is surfaced without rejecting the document.

IBR-168-OM:

Previous Behavior: BTOM-016 (Line Item VAT amount) required strict equality validation against IBT-131 × VAT rate within the standard tolerance model.

New Behavior: The reported line VAT amount is compared with the calculated amount at three-decimal (baisa) precision. An exact match is accepted; a non-zero difference within ±0.001 OMR for the line is accepted with a warning; a difference beyond ±0.001 OMR is rejected. The tolerance is per line and does not depend on IBT-114.

Justification: Tax-inclusive pricing scenarios may produce an unavoidable one-baisa rounding deviation per line during backward derivation of tax-exclusive values from inclusive retail prices. The warning makes such tolerance use visible while keeping the boundary strict.

IBR-158-OM:

Previous Behavior: BTOM-017 (Total amount including VAT) required strict equality validation using line net amount plus VAT amount calculations.

New Behavior (clarified per OTA review): No Baisa tolerance is applied to BTOM-017. The rule retains strict equality with the standard two-decimal rounding allowance only (identical to the E/O/Z taxable-amount checks). Tolerance is confined to the line VAT amount BTOM-016 (IBR-168-OM).

Justification: OTA confirmed tolerance is not required on the total including VAT; applying it only to the VAT amount field keeps the document totals exact and consistent with the PINT shared calculation rules.

ALIGNED-IBRP-S-08-OM:

Previous Behavior: Standard-rated VAT breakdown taxable amount calculations required strict equality validation against aggregated line-level taxable amounts.

New Behavior (clarified per OTA review): No Baisa tolerance is applied to IBT-116. The rule retains strict equality with the standard two-decimal rounding allowance only. Tolerance is confined to the VAT category tax amount IBT-117 (ALIGNED-IBRP-S-09-OM).

Justification: OTA confirmed tolerance is not required on the VAT category taxable amount; confining it to the tax amount field keeps the breakdown taxable amounts exact.

ALIGNED-IBRP-S-09-OM:

Previous Behavior: Standard-rated VAT breakdown tax amount calculations required strict equality validation against aggregated line-level VAT amounts.

New Behavior: IBT-117 (VAT category tax amount) is compared with the sum of line VAT amounts (plus charges' VAT minus allowances' VAT) at two-decimal precision, since IBT-117 is a document-level amount expressed at two decimals. An exact match is accepted; a non-zero difference within ±(0.001 × number of invoice lines) OMR is accepted with a warning; a difference beyond that is rejected. Because the difference between two 2-decimal amounts is a multiple of 0.01, this tolerance begins to permit a deviation only at 10 or more invoice lines (where the cap reaches 0.01). The tolerance does not depend on IBT-114.

Justification: Ensures consistency between aggregated VAT calculations and the line-level tolerance behaviour, scaling the permitted deviation with the number of lines, while surfacing tolerance use through a warning.

Documentation

Document Section Change Description Reason

Document	Section	Change Description	Reason
Release Notes	Rounding Amount (IBT-114) Handling	Added explanation that no restrictions are placed on `IBT-114`, and the rationale (tolerance plus other rounding-off differences such as exchange-rate conversion).	Clarifies the business and mathematical rationale behind the approach.
Validation Documentation	Schematron tolerance	Added guidance describing the bounded Baisa Gap tolerance behaviour on the VAT calculation fields.	Improves implementer understanding and troubleshooting capability.
Compatibility	Various	Added compatibility guidance for existing PINT OM implementations.	Clarifies upgrade impact and backward compatibility behaviour.
Business Rules / Web Specification	IBR-168-OM, ALIGNED-IBRP-S-09-OM, IBR-158-OM, ALIGNED-IBRP-S-08-OM	Removed tolerance wording from the normative business-rule statements (tolerance is Schematron behaviour); clarified that `IBT-116` and `BTOM-017` carry no Baisa tolerance.	Implements OTA review comments separating tolerance (Schematron) from the business rules.
Data Model / Web Specification	Business terms	Excluded the Tolerance-applied indicator terms (`BGOM-08`, `BTOM-035`, `BTOM-035-1`, `BTOM-200-OM`).	OTA assessed the indicator as added burden without value to taxpayers/service providers.
Business Processes	Core Header Rules → UUID Format	Added a "UUID Format (Version 5)" segment and made the generic UUID row specific: Invoice UUID (`BTOM-002`) MUST be version 5; Seller UUID (`BTOM-004`) MUST be version 5 as well. Includes the validation patterns and RFC 4122 background.	Documents the UUID version requirements now enforced by `IBR-002-OM` and `IBR-173-OM`.
Semantic Data Model	`BTOM-002`, `BTOM-004`	Extended the definitions of the Invoice UUID (`BTOM-002`, version 5) and Seller UUID (`BTOM-004`, version 5) with the required UUID version and rule references.	Aligns the data-model documentation with the corrected UUID validation rules.

Release Notes

Rounding Amount (IBT-114) Handling

Added explanation that no restrictions are placed on IBT-114, and the rationale (tolerance plus other rounding-off differences such as exchange-rate conversion).

Clarifies the business and mathematical rationale behind the approach.

Validation Documentation

Schematron tolerance

Added guidance describing the bounded Baisa Gap tolerance behaviour on the VAT calculation fields.

Improves implementer understanding and troubleshooting capability.

Compatibility

Various

Added compatibility guidance for existing PINT OM implementations.

Clarifies upgrade impact and backward compatibility behaviour.

Business Rules / Web Specification

IBR-168-OM, ALIGNED-IBRP-S-09-OM, IBR-158-OM, ALIGNED-IBRP-S-08-OM

Removed tolerance wording from the normative business-rule statements (tolerance is Schematron behaviour); clarified that IBT-116 and BTOM-017 carry no Baisa tolerance.

Implements OTA review comments separating tolerance (Schematron) from the business rules.

Data Model / Web Specification

Business terms

Excluded the Tolerance-applied indicator terms (BGOM-08, BTOM-035, BTOM-035-1, BTOM-200-OM).

OTA assessed the indicator as added burden without value to taxpayers/service providers.

Business Processes

Core Header Rules → UUID Format

Added a "UUID Format (Version 5)" segment and made the generic UUID row specific: Invoice UUID (BTOM-002) MUST be version 5; Seller UUID (BTOM-004) MUST be version 5 as well. Includes the validation patterns and RFC 4122 background.

Documents the UUID version requirements now enforced by IBR-002-OM and IBR-173-OM.

Semantic Data Model

BTOM-002, BTOM-004

Extended the definitions of the Invoice UUID (BTOM-002, version 5) and Seller UUID (BTOM-004, version 5) with the required UUID version and rule references.

Aligns the data-model documentation with the corrected UUID validation rules.

Rounding (Baisa Gap) Example

Component Amount

Component	Amount
Retail price (tax-inclusive)	0.050 OMR
Derived Net Price (`IBT-146`)	`0.050 / 1.05 → ROUND(_, 3) = 0.047 OMR`
Line VAT amount (`BTOM-016`)	`0.047 × 5% → ROUND(_, 3) = 0.002 OMR`
Invoice line total (`BTOM-017`)	`0.047 + 0.002 = 0.049 OMR`
Customer actually paid	0.050 OMR
Difference (Baisa Gap)	`0.001 OMR`

Retail price (tax-inclusive)

0.050 OMR

Derived Net Price (IBT-146)

0.050 / 1.05 → ROUND(_, 3) = 0.047 OMR

Line VAT amount (BTOM-016)

0.047 × 5% → ROUND(_, 3) = 0.002 OMR

Invoice line total (BTOM-017)

0.047 + 0.002 = 0.049 OMR

Customer actually paid

0.050 OMR

Difference (Baisa Gap)

0.001 OMR

Design Principles

Principle Description

Principle	Description
Mathematical integrity	Existing strict mathematical validation behaviour remains unchanged; each acceptance boundary is evaluated at the field’s native precision (three decimals for line-level VAT amounts, two decimals for document-level VAT amounts).
Bounded tolerance	The systematic rounding difference is tolerated only within a strict bound on the VAT amount fields: `±0.001 OMR` per line for `BTOM-016 (IBR-168-OM)`, and `±(0.001 × number of invoice lines) OMR` for `IBT-117 (ALIGNED-IBRP-S-09-OM)`.
Graduated outcome	On these two rules, an exact match is Accepted, a non-zero difference within tolerance is Accepted with warning, and a difference beyond tolerance is Rejected — making tolerance use visible without weakening the boundary.
Auditability	Any residual difference MAY be recorded in `IBT-114` for traceability, but `IBT-114` is not required for the tolerance to apply.
No restriction on IBT-114	`IBT-114 (PayableRoundingAmount)` carries no cap, equality, or reconciliation constraint, allowing it to absorb the tolerance plus other rounding-off differences (for example, exchange-rate rounding).
No manual flags	Tolerance is determined entirely by invoice data behaviour without introducing tax-inclusive indicators.

Mathematical integrity

Existing strict mathematical validation behaviour remains unchanged; each acceptance boundary is evaluated at the field’s native precision (three decimals for line-level VAT amounts, two decimals for document-level VAT amounts).

Bounded tolerance

The systematic rounding difference is tolerated only within a strict bound on the VAT amount fields: ±0.001 OMR per line for BTOM-016 (IBR-168-OM), and ±(0.001 × number of invoice lines) OMR for IBT-117 (ALIGNED-IBRP-S-09-OM).

Graduated outcome

On these two rules, an exact match is Accepted, a non-zero difference within tolerance is Accepted with warning, and a difference beyond tolerance is Rejected — making tolerance use visible without weakening the boundary.

Auditability

Any residual difference MAY be recorded in IBT-114 for traceability, but IBT-114 is not required for the tolerance to apply.

No restriction on IBT-114

IBT-114 (PayableRoundingAmount) carries no cap, equality, or reconciliation constraint, allowing it to absorb the tolerance plus other rounding-off differences (for example, exchange-rate rounding).

No manual flags

Tolerance is determined entirely by invoice data behaviour without introducing tax-inclusive indicators.

Compatibility

Transaction type (BTOM-001) continues to use the 1/0 bitmap encoding (inactive positions = 0); the encoding is unchanged and no re-encoding of instance data is required.
Existing strict validation pathways remain unchanged.
IBR-158-OM (Total amount including VAT, BTOM-017) no longer requires the Line Item VAT amount (BTOM-016) on a simplified tax invoice line, consistent with IBR-038-OM. This is a relaxation; invoices already providing the amount are unaffected.
IBR-171-A-OM now also validates that the Payment due date (IBT-009, cbc:DueDate), when present, is a valid YYYY-MM-DD date. This is a tightening; a malformed due date that previously passed will now be rejected.
IBR-002-OM now requires a UUID version 5 for the Invoice UUID (BTOM-002).
IBR-173-OM now enforces UUID structure on the Seller UUID (BTOM-004), accepting version 5. This is a tightening: values that satisfied the previous ^[A-Za-z0-9-]+$ expression but are not valid UUIDs will now be rejected where the Buyer electronic address is 997770000099. Senders already placing a genuine version 5 UUID in cbc:AdditionalAccountID are unaffected.
Tax-inclusive (B2C) invoices may now carry the systematic rounding artefact within the bounded tolerance on the VAT amount fields. Where the tolerance is used, IBR-168-OM and ALIGNED-IBRP-S-09-OM now return an Accepted with warning outcome rather than a silent acceptance; receivers should treat these warnings as informational, not as failures.
IBT-114 (PayableRoundingAmount) is accepted without restriction and is not required for the tolerance to apply.
The Tolerance-applied indicator business terms (BGOM-08, BTOM-035, BTOM-035-1, BTOM-200-OM) are excluded from OM PINT; no other business terms, syntax structures, or semantic data model elements have been removed.

Code Lists

No changes to code list values in this release. The transaction-type bitmap representation (CL-03-OM and the web specification) uses the 1/0 encoding for active/inactive positions.

Action Items for Implementers

Update validation environments to include the Baisa Gap tolerance handling on the VAT amount rules (IBR-168-OM, ALIGNED-IBRP-S-09-OM); note that IBT-116 and BTOM-017 carry no Baisa tolerance.
Ensure the validation pipeline surfaces, and does not reject, the Accepted with warning outcome from IBR-168-OM-WARN and ALIGNED-IBRP-S-09-OM-WARN.
Ensure IBT-114 (PayableRoundingAmount) is accepted as a free-form value without restriction.
Ensure no Tolerance-applied indicator (OM-TOLERANCE-APPLIED) is required or expected.
Verify handling of tax-inclusive pricing scenarios where a systematic one-baisa-per-line rounding artefact is present.
Migrate the Invoice UUID (BTOM-002) to an RFC 4122 version 5 (name-based, SHA-1) UUID. IBR-002-OM no longer accepts version 4; senders emitting a version 4 Invoice UUID will be rejected.
Ensure the Seller UUID (BTOM-004, cbc:AdditionalAccountID) is a valid UUID version 5 where the Buyer electronic address (IBT-049) is 997770000099. IBR-173-OM now validates its structure and no longer accepts arbitrary alphanumeric/dash values.

Support

For support and clarification:

https://peppol.org/tools-support/service-desk/