What Format Must an Oman E-Invoice Be In?

An Oman e-invoice must be a UBL 2.1 XML document conforming to the Peppol PINT Oman profile. Not a PDF, not a scanned image, and not JSON on the wire. UBL 2.1 supplies the structure — which elements exist, and where — and the Oman profile adds the country's own rules on top of it. Anything else may be a perfectly good invoice; it is not an e-invoice under Fawtara.

That is the whole answer. The rest of this page is what it means in practice: what "structured" buys you, where JSON legitimately fits, which four document types Oman defines, what the file has to carry, and how it is checked.

Why must it be structured rather than a PDF?

A PDF is a picture of an invoice. A person reads it; software guesses at it. Optical character recognition is a guess with a confidence score, and a tax system cannot be built on a guess.

A structured invoice is the same information with every field labelled, so the buyer's system knows that a particular number is the VAT amount for a particular line rather than inferring it from where it sits on the page. That is what makes the invoice postable without re-keying, and it is what makes automated checking possible at all.

This is worth stating because the substitution people reach for first — emailing a PDF — is precisely the thing the mandate replaces. A human-readable copy is still useful and can still be produced; it is a courtesy, not the document of record.

Is JSON an alternative to XML for an Oman e-invoice?

No, and the confusion is understandable enough that it shows up in the search data: people look for "xml/json structured invoice oman" because both words are in the air.

Here is the distinction that resolves it.

JSON is how you hand your invoice data to a provider. Most modern invoicing APIs, ours included, accept a plain JSON payload — seller, buyer, lines, tax — and return JSON telling you what happened. Nothing about that is wrong or unusual.

XML is what the invoice actually is. The provider renders your data into a UBL 2.1 XML document in the Oman profile, signs it, sends that document to your buyer over the Peppol network, and derives the Authority's tax data document from it. Your buyer receives XML. The rule packs Oman publishes are written against XML. The archived document is XML.

So JSON is a convenience at your own boundary, and if a supplier tells you Oman "accepts JSON invoices", ask them what travels to the buyer. The answer will be XML.

Which document types does Oman define, and do they share one format?

Four, and they share UBL 2.1 as their syntax while being validated by different rules.

Each of the four has its own rule pack in the validation set we ship. Which pack applies is decided by two things in the document itself: the root element — an invoice document and a credit-note document are different UBL document types, not one type with a flag — and the specification identifier the document carries, which is what marks self-billing.

The practical consequence for an integrator is that a self-billed document is not an ordinary invoice with a different code on it. It is validated against a different rule pack, and a document that names the wrong profile is checked against rules that were never meant for it.

The exact identifier strings, and the reason they matter more than they look, are in our PINT OM specification identifier reference. This page deliberately lists none of them: one page should own that detail, and that is the page.

What must the file carry?

Below the level of "UBL 2.1 XML" sits the part people actually trip on. These are taken from the Oman rule packs we ship and validate against, not from a summary of them.

The document has to say what it is. A specification identifier naming the Oman PINT profile, and a business process identifier. Between them they tell every system that handles the document which rules to apply. A document without them is not merely unlabelled; it is unroutable.

A unique identifier, and a specific kind of one. Oman requires a document UUID, and the rule pack requires it to be a version 5 UUID — the kind that is derived from a name rather than generated at random. That is why the identifier is reproducible: the same invoice produces the same UUID, so a retry is recognisable as a retry rather than filed as a second document.

An issue time, not only an issue date. Oman's aligned profile requires the invoice issue time as well as the date.

A transaction type, carried on the type code. Beyond the ordinary invoice type code, Oman carries a transaction type marking what kind of supply this is — export, import of goods, import of services under reverse charge, summary invoice, continuous supply, special zone supplies, profit margin, self-billing. Several of the rules that reject documents are conditional on it: an export invoice claiming re-export of goods must carry a supporting document reference; a summary invoice must carry an invoicing period whose start and end fall in the same calendar month; a special-zone supply must carry the seller's special-zone licence number as an identifier scheme.

Currency, and what follows from it. The document currency code is mandatory. If it is not the rial, the pack requires a VAT accounting currency and an exchange rate — and if it is the rial, the same pack requires the exchange rate to be absent. Both directions are enforced, which catches the common mistake of leaving a default exchange rate of 1 in a domestic document.

At least one line, and more on each line than the international rules ask for. Oman requires a VAT amount and a total including VAT on every line, carried in the item price extension. Most invoicing systems calculate those figures for display and never emit them; Oman wants them in the file.

Item classification, where it applies. Goods carry a 12-digit Oman HS code; services carry a code from Oman's service-type list. The scheme identifier has to say which of the two it is.

VAT categories from a fixed list, with a reason code where the line is zero-rated or exempt. A zero-rated line with no reason code fails.

How is the file checked, and in what order?

Four layers, and they run in order, because a failure at one makes the next meaningless.

The first two layers are syntax: does this parse, and does it match the UBL 2.1 schema for the document type it claims to be. The last two are business rules: 170 rules from the international PINT rule set, then 155 in the Oman jurisdiction pack — of which 108 carry Oman rule identifiers, 30 are profile-alignment rules, and 16 check values against Oman's own code lists. Those numbers are from the 2026-Q2 final packs we ship, counted on 20 August 2026 rather than recalled.

The distinction matters when you receive an error. A syntax failure means the document is malformed and no rule was evaluated. A business-rule failure means the document is structurally fine and says something the rules do not permit, and it comes back with the rule identifier attached, so the fix is a lookup rather than a hunt.

Not every rule is fatal. Oman's pack includes rules that accept a document with a warning — the rounding tolerances below are the clearest example — and the difference between "rejected" and "accepted, please confirm this was deliberate" is one an integrator needs to see rather than have flattened into a red cross.

Reading an actual result — which layer raised a finding, what the identifier means, and what to do with the two warnings — is a page of its own: how to test an Oman e-invoice before you send it.

Why do three decimal places matter in Oman?

Because the rial has 1,000 baisa rather than 100, and this is the single most common avoidable rejection we see in Oman implementations.

The rule pack permits amounts to three decimal places, and an exchange rate to seven. Line VAT is then checked against the rate times the net amount, with a tolerance of 0.001 rial per line; at the VAT-category level the tolerance is the same figure multiplied by the number of lines. VAT rates themselves are numeric, without a percentage sign, to a maximum of two decimals.

At two decimal places, ordinary retail prices cannot satisfy that. Three items at 5.500 rial with 5% VAT gives 0.825, which a two-decimal system rounds to 0.83 — outside the tolerance, and the line is refused. A system that has always rounded money to two decimals will produce a document that looks right to everyone who reads it and fails on arithmetic.

Does the Tax Authority receive the same file?

No, and this is the second thing people assume. The invoice goes to your buyer; a separate tax data document goes to the Authority, derived from the invoice and carrying it. Sending the invoice does not report it, and reporting it does not send it.

That document has its own structure and its own rule pack, and it has a page of its own: the Oman tax data document, field by field. The architecture that connects the two — five corners rather than the familiar four — is explained in Oman's Fawtara five-corner model.

What this page deliberately leaves to other pages

Four questions sit next to this one and are answered better elsewhere. Restating them here would put two GoRoute pages in competition for one search, and the newer page usually wins by being wrong more recently.

• When the mandate applies to you, including the dates and the annual-supplies threshold: Oman's 2027 e-invoicing dates and which wave am I in?
• The five-corner architecture and who exchanges what: the five-corner model explained
• The specification identifiers themselves, version by version: the PINT OM identifier reference
• The tax data document: the TDD deep dive
• What happens when the file fails one of those rules, identifier by identifier: why Oman e-invoices get rejected

One more sits alongside the format question and is easy to miss: the obligations on the system that produces the invoice — security, continuity and record-keeping — which are set out in Article 143 bis 1 and what it requires of your system. The format is the document; that article is the machine that issues it.

What is not settled here

Two honest gaps, marked rather than papered over.

Rule packs move. The figures above are from the 2026-Q2 final packs as we ship them today. Oman's profile has already gone through version changes, and it will again; the version history is tracked here. If you are reading this a year from now, the shape of the answer holds and the counts may not.

A rule pack is not a legal text. It is the machine-readable form of a specification, and where the two are read differently the specification and the Authority decide. Nothing on this page is a statement about your own compliance position.

What to do with this

If you are choosing how to integrate, the format is not usually the thing to solve yourself. Rendering UBL, applying 325 rules across two layers, signing, sending and filing is what an accredited service provider is for — and the file you would have written by hand is the file it produces.

The commercial ground — what Oman e-invoicing with GoRoute involves, and what the integration looks like — is on our Oman e-invoicing page. If you would rather test than read, a document can be validated against the full Oman rule set before you commit to anything: the free sandbox returns the same rule identifiers described above, and how to test an Oman e-invoice before you send it walks through running that check and reading what comes back.

And if your invoices start life in a spreadsheet rather than a system, the format requirements are unchanged but the work is much smaller than people expect: sending Oman e-invoices from Excel.

GoRoute is an accredited Oman Fawtara service provider and a certified Peppol Access Point, accredited on 29 July 2026 through Union Digital Technologies SPC.

Primary sources: Oman Tax Authority — the authority that publishes the Oman e-invoicing rules; OASIS UBL 2.1 — the underlying document syntax; Peppol technical documentation — the PINT specification this profile extends.