PINT Oman (PINT OM): CustomizationID and ProfileID Reference

What is PINT OM?

PINT OM is Oman's national specialisation of the Peppol International Invoice (PINT) — the invoice format the Oman Tax Authority requires under the Fawtara e-invoicing programme. It says which identifiers a document must carry, which fields Oman makes mandatory on top of the international baseline, and which rules a document must pass before it can be reported to the Authority and delivered over Peppol. The ruleset in force is version 1.0.1, published by OpenPeppol and stamped in the Schematron itself as "[PINT-OM-META] Ruleset version 1.0.1 — Authority: Tax Authority Oman".

Three identifiers do the work. The CustomizationID says which specialisation the document follows, the ProfileID says which business process it belongs to, and the document type code says whether it is an invoice, a credit note or a debit note. Get any of the three wrong and the document is rejected by rule, not by opinion.

The rest of this page is the reference itself: every value, the rule that enforces it, and the validation pack that carries the rule. Bookmark it, paste it into your design docs, link it from your validator config.

These identifiers are validated automatically by our Peppol Oman service, which runs the PINT OM Schematron on every document.

If your question is the broader one — how PINT relates to Peppol BIS and why a national specialisation exists at all — Peppol vs PINT: the difference explained answers it. This page assumes that is settled and gives you the Oman values.

For the higher-level context, read the Oman Fawtara readiness guide and the TDD deep-dive. If you are still choosing who will send these documents for you, the Oman e-invoicing provider checklist is the buyer's-side version of this page. When the specification version moves, what changes and what has to be re-tested covers the readiness work. For the global picture, the e-invoicing mandates 2026 tracker is the index.

The five document types

Direction of travel: billing documents go supplier → buyer, self-billing documents go buyer → supplier under a self-billing agreement, and the TDD goes from the issuer to the Tax Authority.

Each value above is asserted by a named rule, so a rejection tells you exactly which line of this table you missed:

Document type codes

Invoices and credit notes share a CustomizationID, so the document type code and the UBL root element are what separate them. The element name differs by root: an Invoice carries cbc:InvoiceTypeCode, a CreditNote carries cbc:CreditNoteTypeCode. There is no cbc:DocumentTypeCode in UBL 2.1, and searching for one is a wasted afternoon.

Rule ibr-cl-01 enforces the code list per pack, and the lists are not the same width. The billing invoice pack accepts the UNTDID invoice-type list, which includes 380 and the debit note 383; the billing credit-note pack accepts 81 83 381 396 532. The self-billing packs accept exactly one value each — 389 for the invoice and 261 for the credit note — so a self-billed document carrying 380 fails even though 380 is valid one pack over.

The TDD is a separate document with its own root and namespace (pxs:), not a UBL invoice, and it carries no invoice type code at all.

Schematron packs

The official PINT OM artefacts are compiled to XSLT and run in-process. There are four invoice-family packs, each holding two Schematrons, plus the TDD Schematron — nine compiled stylesheets in total:

The split inside each pack matters when you read a rejection. PINT-UBL-validation-preprocessed carries the PINT baseline and the code lists — its rule identifiers start ibr-. PINT-jurisdiction-aligned-rules carries Oman's own layer, titled "PINT Oman E-Invoice Validation Rules (IBR-OM)" — its identifiers start ALIGNED-IBRP- and end -OM. A rule identifier therefore tells you whether you have broken an international rule or an Omani one before you have read the message.

Each Schematron is run with Saxon-HE 12.4. A Schematron-level error blocks; a warning is logged for audit.

How the validator picks the pack

Two things select the pack: the CustomizationID decides billing versus self-billing, and the UBL root element decides invoice versus credit note.

is_self_billing = "selfbilling" in customization_id.lower()
is_credit_note  = root_element == "CreditNote"

pack = ("selfbilling-" if is_self_billing else "") + \
       ("creditnote" if is_credit_note else "invoice")

The Tax Data Document is routed separately, on urn:peppol:taxdata:om-1, because it is not a UBL invoice.

The PINT OM packs skip the baseline CEN EN 16931 + Peppol BIS 3.0 Schematrons by design — the rule families are restated inside the PINT Schematron itself.

Which rule pack runs on which leg of the exchange

The billing and self-billing packs run twice on the invoice leg — once at the sending access point before transmission, and again at the receiving access point on arrival. The TDD Schematron runs once, at the Tax Authority's access point. No invoice pack ever runs on the tax-reporting leg, and the TDD pack never runs on an invoice.

Oman's model is three exchanges, not one. The Oman Solution Reference Architecture v1.0.1 sets them out as the invoice exchange C1 → C2 → C3 → C4, and two tax-data exchanges, (C1 →) C2 → C5 → C6 and (C4 →) C3 → C5 → C6. Each leg has its own validation duty:

The architecture states the two duties in the same words each time. The receiving access point "MUST be able to validate (using the Schematrons) the Invoice Business Documents, that it has registered in the Dynamic Discovery on behalf of its End-Users". The Authority's access point "MUST be able to validate the Oman TDD Business Document (using the Oman TDD Schematron - and not for Tax compliance etc.)" — the parenthesis is the specification's own, and it is the point: C5 checks that the report is a well-formed TDD, not that the tax on it is right.

Three consequences fall out of that table, and each one is a support ticket somewhere.

The pack is named in the envelope before any Schematron opens the document. The Peppol document type identifier embeds the CustomizationID after a double hash — urn:oasis:names:specification:ubl:schema:xsd:Invoice-2::Invoice##urn:peppol:pint:billing-1@om-1::2.1 for the billing invoice, …CreditNote-2::CreditNote##urn:peppol:pint:billing-1@om-1::2.1 for the credit note, and the same two forms with selfbilling-1@om-1 for the self-billing pair. The identifier scheme is peppol-doctype-wildcard. The TDD is separate again: scheme busdox-docid-qns, identifier urn:peppol:schema:om-taxdata:1.0::TaxData##urn:peppol:taxdata:om-1::1.0.

Registration decides which packs can ever run at the receiver. For a domestic Omani participant, receiving capability for the PINT invoice and the PINT credit note is mandatory; the self-billed invoice and self-billed credit note are optional, registered only where the receiver has agreed to accept them. So a self-billed invoice addressed to a participant who never registered that document type does not fail validation — it fails discovery, before a Schematron is loaded.

A validation failure on the invoice leg suppresses the tax report. The architecture's own summary of the receiving access point's scenarios pairs the negative Message Level Status with a one-line note: "No TDD is exchanged with C5." The same note appears against a delivery failure. A rejected invoice is not reported and then corrected; it is not reported at all until it validates.

One asymmetry is worth knowing before you design around it. Where the seller is outside Oman and the buyer is inside it, the receiving access point produces no TDD, "because it cannot be guaranteed that the Invoice can provide all required data necessary for creating an OM TDD". The buyer issues a self-billed invoice for tax-reporting purposes instead — which is why the self-billing packs matter to importers who never intend to invoice anyone.

What happens when the CustomizationID is wrong or missing

A wrong or missing CustomizationID fails in one of two places, and the two failures look nothing alike.

If the value is not one of the four Oman publishes, the failure is at discovery. The receiver has no SMP registration matching that document type identifier, so the transmission never starts and there is no validation report to read — the same silent class of failure as using the wrong participant identifier scheme, described in the section above. If the value is a real Oman one but wrong for the document in hand — a self-billing identifier on a billing invoice, say — the failure is at validation, and it is reported.

Missing and wrong are the same failure. Rule ALIGNED-IBRP-001-OM tests starts-with() over the normalised element value, so an absent cbc:CustomizationID yields the empty string, the empty string does not start with the expected prefix, and the identical assertion fires. There is no separate "element missing" rule to look for. What tells the two apart is the diagnostic, which prints the value it found:

[ALIGNED-IBRP-001-OM] - Specification identifier (IBT-024) MUST start with the
value 'urn:peppol:pint:billing-1@om-1'.
Customization ID (cbc:CustomizationID)
  Found:    ''
  Expected: 'urn:peppol:pint:billing-1@om-1'
  Action:   Set CustomizationID to the expected value.

An empty Found means the element is absent. A populated one means it is present and wrong. The ProfileID rule behaves the same way and prints the same shape:

[ALIGNED-IBRP-002-OM] - Business process (IBT-023) must follow the expected
format 'urn:peppol:bis:billing'.
Profile ID (cbc:ProfileID)
  Found:    ''
  Expected: 'urn:peppol:bis:billing'
  Action:   Set ProfileID to the expected value.

Each pack states its own expected value in its own message, so the text of the rejection tells you which pack ran:

The invoice family matches on a prefix; the TDD matches exactly. ALIGNED-IBRP-001-OM and ALIGNED-IBRP-002-OM both use starts-with(), so a value carrying a suffix after the published string still passes. ibr-tdd-01 and ibr-tdd-02 compare for equality — normalize-space(cbc:CustomizationID) = 'urn:peppol:taxdata:om-1'. A suffixed identifier that a validator accepts on an invoice is therefore rejected on the tax report, which is a genuinely confusing hour if you have not seen it before.

There is no tolerant mode for an identifier. In the billing invoice jurisdiction pack, 140 of the 142 assertions carry flag="fatal". The two exceptions are ALIGNED-IBRP-S-09-OM-WARN and IBR-168-OM-WARN, and both are rounding tolerances whose messages begin "ACCEPTED WITH WARNING" — a VAT category total or a line VAT amount that does not exactly equal its calculated value. The identifier rules are not among them, and neither is the transaction type, the issue time or the preceding-invoice reference.

What the sender sees. A document rejected at the receiving access point comes back as a Message Level Status carrying response code RE, defined in the architecture as "Message rejected or delivery towards C4 failed". Codes AP and AB are the two success cases: delivered with confirmation, and delivered without one. The Message Level Status is requested as ALWAYS_SEND in the transmission envelope, so its absence within the network's own timeout is itself an exception the sender must handle, distinct from a rejection.

Identifier scheme conventions

The scheme is 0248, not 9959. This page said 9959 until 20 August 2026 and that was wrong. It is an expensive kind of wrong: 9959:1100012345 is not a registered participant, so the lookup on the Peppol network returns nothing and the document fails in transport with no validation message to explain it. Our Oman country guide carries the same correction, and the authoritative sources are the Oman SMP registration code, the Tax Authority's own sample invoices and the live SMP registrations.

Worked example — invoice header

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
  <cbc:CustomizationID>urn:peppol:pint:billing-1@om-1</cbc:CustomizationID>
  <cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>
  <cbc:ID>INV-2026-000123</cbc:ID>
  <cbc:IssueDate>2026-05-09</cbc:IssueDate>
  <cbc:IssueTime>09:41:00</cbc:IssueTime>
  <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>OMR</cbc:DocumentCurrencyCode>
  <cbc:TaxCurrencyCode>OMR</cbc:TaxCurrencyCode>
  <!-- … -->
</Invoice>

cbc:IssueTime is there deliberately: rule ALIGNED-IBRP-016-OM makes the invoice issue time (IBT-168) mandatory in Oman, where the international baseline does not. It is one of the commonest first failures for a team porting a working Peppol invoice into PINT OM.

Worked example — credit note header

The credit note keeps the billing CustomizationID and ProfileID unchanged. Three things move: the root element and namespace become CreditNote, the type code element becomes cbc:CreditNoteTypeCode carrying 381, and a reference to the invoice being credited becomes mandatory.

<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
            xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
            xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
  <cbc:CustomizationID>urn:peppol:pint:billing-1@om-1</cbc:CustomizationID>
  <cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>
  <cbc:ID>CN-2026-000045</cbc:ID>
  <cbc:UUID>edb781fe-e427-53e7-90ce-03e817b7ae57</cbc:UUID>
  <cbc:IssueDate>2026-05-09</cbc:IssueDate>
  <cbc:IssueTime>11:20:00</cbc:IssueTime>
  <cbc:CreditNoteTypeCode name="10000000000000000000">381</cbc:CreditNoteTypeCode>
  <cbc:DocumentCurrencyCode>OMR</cbc:DocumentCurrencyCode>
  <cbc:TaxCurrencyCode>OMR</cbc:TaxCurrencyCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>INV-2026-000123</cbc:ID>
      <cbc:UUID>24a23be4-7dfb-5107-a074-a72473c7e4e8</cbc:UUID>
      <cbc:IssueDate>2026-05-09</cbc:IssueDate>
      <cbc:DocumentStatusCode>OTH</cbc:DocumentStatusCode>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <!-- … -->
</CreditNote>

cac:BillingReference/cac:InvoiceDocumentReference/cbc:ID is not optional here. Rule ALIGNED-IBRP-028-OM, flagged fatal, requires a preceding invoice reference (IBG-03) whenever the type code is 381 (credit note), 383 (debit note) or 261 (self-billed credit note). The one document type that is a credit note and does not need it does not exist in PINT OM.

The cbc:UUID inside the billing reference is the credited invoice's own identifier, which both access points can compute independently: the invoice UUID is a version 5 UUID derived from the invoice's seller scheme and identifier, type code, number, date, total tax amount and total with tax, under a fixed namespace published in the architecture. Because it is derived rather than assigned, a credit note can carry the right reference even when the original invoice was not received over Peppol.

Worked example — self-billed invoice header

Self-billing is the buyer issuing the invoice on the supplier's behalf. Both identifiers change, and the type code changes with them.

<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
  <cbc:CustomizationID>urn:peppol:pint:selfbilling-1@om-1</cbc:CustomizationID>
  <cbc:ProfileID>urn:peppol:bis:selfbilling</cbc:ProfileID>
  <cbc:ID>SB-2026-000007</cbc:ID>
  <cbc:UUID>41bbdfa7-4756-51a7-af14-dbde07258e5a</cbc:UUID>
  <cbc:IssueDate>2026-05-09</cbc:IssueDate>
  <cbc:IssueTime>08:15:00</cbc:IssueTime>
  <cbc:InvoiceTypeCode name="10100000000000000000">389</cbc:InvoiceTypeCode>
  <cbc:DocumentCurrencyCode>OMR</cbc:DocumentCurrencyCode>
  <cbc:TaxCurrencyCode>OMR</cbc:TaxCurrencyCode>
  <!-- … -->
</Invoice>

The type code is where self-billing bites hardest. The self-billing packs accept exactly one invoice code, 389, and exactly one credit-note code, 261. A document that would validate perfectly as a billing invoice — same parties, same lines, 380 in the type code — fails ibr-cl-01 the moment it is sent under a self-billing CustomizationID, because 380 is not in that pack's list at all.

Note also what stays the same: the supplier is still the supplier. cac:AccountingSupplierParty carries the party whose sale is being invoiced, not the party that issued the document. Reversing them is the second commonest self-billing error after the type code.

Worked example — self-billed credit note header

The self-billed credit note is the intersection of the two cases above: the self-billing identifiers, the CreditNote root, code 261, and the mandatory reference to the document being credited.

<CreditNote xmlns="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
            xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2"
            xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
  <cbc:CustomizationID>urn:peppol:pint:selfbilling-1@om-1</cbc:CustomizationID>
  <cbc:ProfileID>urn:peppol:bis:selfbilling</cbc:ProfileID>
  <cbc:ID>SBCN-2026-000002</cbc:ID>
  <cbc:IssueDate>2026-05-09</cbc:IssueDate>
  <cbc:IssueTime>08:40:00</cbc:IssueTime>
  <cbc:CreditNoteTypeCode name="10100000000000000000">261</cbc:CreditNoteTypeCode>
  <cbc:DocumentCurrencyCode>OMR</cbc:DocumentCurrencyCode>
  <cac:BillingReference>
    <cac:InvoiceDocumentReference>
      <cbc:ID>SB-2026-000007</cbc:ID>
      <cbc:IssueDate>2026-05-09</cbc:IssueDate>
      <cbc:DocumentStatusCode>OTH</cbc:DocumentStatusCode>
    </cac:InvoiceDocumentReference>
  </cac:BillingReference>
  <!-- … -->
</CreditNote>

Sending any of the three documents above depends on the receiver having registered the matching capability. Invoice and credit note receiving are mandatory for domestic Omani participants; both self-billing types are optional, so confirm the registration before you build the flow rather than after the first rejection.

What the name attribute on the type code carries

Every worked header above puts a twenty-character string of ones and zeros in the name attribute of the type code element. That is the Oman transaction type, BTOM-001, and it is not decoration.

The packs read it from cbc:InvoiceTypeCode/@name or cbc:CreditNoteTypeCode/@name, whichever is present. ALIGNED-IBRP-000-OM makes it mandatory. IBR-001-OM requires exactly twenty characters drawn from 0 and 1. Its diagnostic spells out the intent: "A 20-character bitmap of '1' and '0' with at least one '1' marking an active transaction type. More than one '1' is allowed when several transaction types apply concurrently."

Rules that care about a particular position quote it as a mask with the rest of the string blanked. IBR-006-OM waives the seller tax identifier (IBT-031) only for an import of goods (XXXXXXXXXXXX1XXXXXXX), an import of service under reverse charge (XXXXXXXX1XXXXXXXXXXX) or a profit-margin self invoice (XXXXXXXXXX1XXXXXXXXX). IBR-007-OM uses the same three masks plus special-zone supplies (XXXXXXXXXXXXX1XXXXXX) to require the seller identifier and its scheme. Several VAT-breakdown rules — ALIGNED-IBRP-E-01-OM and ALIGNED-IBRP-O-01-OM among them — relax for a simplified tax invoice, which the packs read from the second position.

The practical consequence is that the bitmap changes which other rules apply to your document. Set it wrong and you will not get a message about the bitmap; you will get a message about a missing seller tax identifier on an import, or a missing VAT breakdown on an exempt line, and you will look in the wrong place. The transaction type is also what routes the substitute participant identifiers Oman uses for buyers who are not on the network — exports, deemed supplies and business-to-consumer sales each have their own — which is covered in the five-corner model explainer.

Cross-references

• Oman Fawtara readiness guide — programmatic context.
• Oman TDD deep-dive — TDD-specific detail.
• PINT OM version updates and re-testing — what to do when the version moves under you.
• Choosing an Oman e-invoicing provider — the buyer's checklist, if you are not building this yourself.
• Peppol vs PINT: the difference explained — comparative model.
• E-invoicing mandates 2026 tracker — global index.

What we ship at GoRoute

GoRoute compiles the PINT OM artefacts to XSLT at Docker build time — the four invoice-family packs and the TDD Schematron listed above — and runs them through Saxon-HE 12.4 at validation time. The rule layer in production is version 1.0.1. Received documents are validated against the same packs, so a Schematron violation on an inbound invoice is answered with a message-level response carrying the rule identifier that failed, rather than a silent drop.

Book a demo to see PINT OM validation against your sample invoices.

---

Sources: OpenPeppol PINT framework and the official PINT OM 1.0.1 artefacts, read directly for every identifier, rule identifier, rule severity, diagnostic message and code list on this page; the Oman Solution Reference Architecture v1.0.1 of 22 May 2026, published by OpenPeppol with the Oman Tax Authority, for the corner model, the validation duty on each leg, the document type and process identifiers, the Message Level Status response codes and the UUID derivation; Oman Tax Authority Fawtara documentation; Peppol BIS Billing 3.0 for ProfileID semantics. Last checked against the shipped 1.0.1 rule packs on 27 August 2026.