"Your invoices need to be in UBL 2.1" and "your invoices need to be PINT-OM compliant" sound like the same requirement. They're not quite the same thing, and the difference is exactly where a lot of e-invoicing implementations go wrong. This is the non-developer version of what your invoices actually need to carry.

Why the format matters this much

Fawtara e-invoicing isn't "send a nicely formatted PDF." Every invoice moves through a Peppol network as a structured, machine-readable document that gets validated automatically at multiple points — by the sending Access Point, the receiving Access Point, and OTA itself via the Tax Data Document flow (see our complete Fawtara guide for the full network model). If the document doesn't carry the exact right structure and identifiers, it can fail validation and bounce — which is a compliance problem, not just a technical inconvenience.

UBL 2.1: the base structure

UBL (Universal Business Language) 2.1 is the underlying XML standard that defines the basic shape of an invoice document — header, supplier details, customer details, line items, tax totals, monetary totals. It's a well-established, internationally used standard; by itself, though, it's generic. UBL 2.1 alone doesn't know anything about Oman, VAT rates, or Fawtara-specific rules — it's the skeleton, not the finished document.

PINT-OM: the Oman-specific layer on top

PINT (Peppol International) is a framework Peppol built specifically so the same UBL-based structure could be adapted to different countries' tax rules without every country inventing its own incompatible format. PINT extends the base Peppol billing model with a layered validation system: universal rules apply everywhere, and each country gets its own specialization — its own set of extra rules — layered on top rather than replacing the base standard.

PINT-OM is that Oman-specific layer. It's what turns a generic UBL 2.1 document into one that satisfies Oman's actual VAT and Fawtara requirements. Concretely, a compliant Oman invoice carries specific identifiers that tell every system in the chain exactly which rule set to validate against:

A self-billed invoice (where the buyer issues the invoice on the supplier's behalf — a real, supported scenario) uses a different CustomizationID: urn:peppol:pint:selfbilling-1@om-1. Credit notes follow the equivalent pattern for their document type. Get the wrong identifier in there, and the document is telling every downstream validator to check it against the wrong rule set — even if every other field is perfect.

PDF/A-3: the human-readable half

A compliant invoice isn't just the XML. It's also delivered as a PDF/A-3 — the long-term-archival PDF standard, chosen specifically because PDF/A-3 allows a file to be embedded inside the PDF itself. That means the human-readable PDF and the machine-readable PINT-OM XML can travel as a single file, rather than as two separate documents that could theoretically drift out of sync.

What this means practically

If you're evaluating a provider or an in-house build, "we generate UBL invoices" is not the same claim as "we generate PINT-OM-compliant invoices." The questions worth asking are specific:

• Does the XML carry the exact urn:peppol:pint:billing-1@om-1 (or the self-billing equivalent) CustomizationID — not just a generic UBL namespace?
• Is the human-readable copy actually PDF/A-3, with the XML embedded, not a plain PDF generated separately?
• Does the system validate against the official Schematron rule packs for PINT-OM before submission, rather than assuming the XML is correct because it didn't error out?

Common mistakes

• Copying example XML values without checking them against the real code lists. Even official example files aren't immune to this — one widely circulated PINT-OM example set uses electronic-address-scheme code 0235 in a sample, which the standard Peppol EAS code list actually registers as "UAE Tax Identification Number," not an Oman identifier. It's an easy copy-paste artifact to inherit if you build from an example rather than the actual code list.
• Treating "UBL" and "PINT-OM" as interchangeable requirements. A document can be perfectly valid generic UBL 2.1 and still fail Oman-specific PINT-OM validation, because the jurisdiction-specific rules are additive, not automatic.
• Generating the PDF and the XML independently, rather than embedding the XML inside a genuine PDF/A-3 file — this technically produces two documents instead of the one compliant artifact the spec describes.
• Skipping self-billing and credit-note variants because the initial build only covered standard invoices — each document type has its own CustomizationID and its own Schematron rules; the ordinary-invoice pattern doesn't automatically extend to the others.

Where to go from here

For the legal and timeline side of all this, see our complete Fawtara guide. For how to check whether a provider is actually equipped to produce this format correctly — not just claim to — see our OTA-accredited service provider guide.

Unfamiliar term? Check our Oman e-invoicing glossary.

Sources: docs.peppol.eu/poac/om; test-docs.peppol.eu/pint/pint-om; Peppol PINT specification documentation.