Xero E-Invoicing in Oman: What Your Books Send, and What Fawtara Adds

The short answer

If your finance team runs Xero, the connection is not the hard part — the data is. GoRoute names Xero among the accounting systems it connects on its managed service and Peppol pages, and there are four ways in: a Xero connector that holds an OAuth 2.0 authorisation to one Xero organisation and is driven by Xero's own webhook, the REST API, a CSV or Excel upload, or manual entry in the portal. Your team raises and authorises the invoice exactly as it does today.

Everything Oman adds happens after the invoice leaves Xero. The version 5 unique identifier, the invoice hash, the QR code on consumer sales and the XAdES-BES signature are produced downstream, from the invoice, by the service provider. No accounting system produces them, and none is expected to.

What decides your timetable is four values Xero has no field for, and a short list of things that have to be right inside your own organisation first. This page names them, says where each has to come from, and gives you work you can start this week without an integration.

Does Xero work with Oman's Fawtara programme?

Yes, and there is more than one way in. Which route suits you depends on how your invoices are raised rather than on how compliant one route is: all four end in the same validation, the same delivery and the same report to the Authority.

The connector's field map is the plain version of what travels: the invoice number, issue date and due date, the currency code, the contact and its tax number, the line description, quantity, unit amount and line amount, the tax type on each line, and the document's subtotal, tax total and total. That is the commercial substance of the invoice, and it is the part Xero is good at.

What does Oman require that Xero has no field for?

Four things, and none of them is a mapping problem. A field that does not exist cannot be mapped; it has to be decided, and then it has to live somewhere.

A unit of measure on every line. This is the one that surprises Xero users. Peppol's shared rule ibr-023 requires an invoiced quantity unit of measure code on every invoice line, and ibr-cl-23 requires it coded from UN/ECE Recommendation 20 with the Recommendation 21 extension — so "each", "hour" and "kilogram" become codes rather than words. Xero has no unit-of-measure field on items or on invoice lines at all. The value therefore comes from a default agreed at onboarding, from your item master, or from a mapping table someone owns.

Peppol participant identifiers. Buyer and seller are addressed on the network by an identifier that no Xero record holds. Oman's scheme is the VAT identification number, and the identifiers come from registration rather than from your books.

The reason behind a zero per cent line. Xero records a tax rate and a reporting classification for the local tax return. It does not record why a line is zero per cent, and Oman requires exactly that, coded. IBR-069-OM refuses a VAT breakdown in category E (exempt) or Z (zero-rated) with no exemption reason code, and two further rules constrain the value: CL-05-OM limits an exempt line to the twelve codes VATEX-OM-01 to VATEX-OM-12, and CL-10-OM limits a zero-rated line to the sixteen codes VATZR-OM-01 to VATZR-OM-16. Every zero per cent rate in your Xero organisation has to be mapped once, by someone who knows why that line is zero per cent.

Item classification. A goods line needs a Harmonized System code of exactly twelve digits (IBR-079-OM, with IBR-080-OM enforcing the length), and the item needs an industrial classification code (IBR-081-OM). Both live in product data rather than on an invoice, and both are usually assembled by whoever owns the item master.

What does Oman add that no accounting system produces?

Four values, made after the invoice leaves your books. They are worth understanding because they are commonly mistaken for a gap in the accounting system, and because a team arriving from a neighbouring Gulf regime will expect them to work differently.

The unique identifier. Oman requires a version 5 UUID on every document (IBR-002-OM) — the kind derived from the document's own content rather than generated at random, so the same invoice always produces the same identifier and a retry is recognisable as a retry rather than as a second sale.

The invoice hash. A SHA-256 digest of the invoice's business content, base64 encoded and carried on the document as an attachment reference. Because it covers the business content and not the security elements added around it, the same invoice hashes the same way twice.

The signature. An enveloped XAdES-BES signature placed in the UBL extensions, with the signature method value fixed by the specification to urn:oasis:names:specification:ubl:dsig:enveloped:xades. It is applied by the service provider with its own certificate.

The QR code, on consumer sales. Oman's specification scopes the QR to business-to-consumer invoices, full and simplified, rather than to every document. It carries nine fields in tag-length-value form — QR version, invoice type, seller name, seller VAT identification number, date, time, total including VAT, VAT total and the seller UUID — base64 encoded. It contains no hash and no digital signature, which is the difference that catches teams carrying a construction over from a neighbouring country: reusing that country's five-tag QR produces a document Oman refuses.

What has to be right inside Xero before the first invoice is sent?

Two fields and one list. None of this needs an integration, a project or a purchase order. It can be done this week, in your own Xero organisation, by whoever maintains it.

VAT identification numbers, in Oman's format. IBR-003-OM requires the seller's, the buyer's and any third party's VAT identification number to be exactly twelve characters: OM followed by ten digits. Yours sits on the organisation record; your customers' sit on their contact records, in the tax number field. A number in any other shape is refused, and a customer list that looks complete because every field has something in it is the commonest unpleasant surprise in week nine.

Amount precision — three decimal places, not two. IBR-DEC-03-OM refuses any amount carrying more than three decimals, and three is not a nicety: the rial has 1,000 baisa. Line VAT is checked against rate times net amount within a tolerance measured in baisa, so a file rounded at the wrong precision produces documents that look right to every human who reads them and fail on arithmetic.

Every zero per cent tax rate in the organisation. List them. For each one decide: zero-rated or exempt, and which Oman code. It is a short table, it needs your finance lead rather than your integrator, and it is the single item most likely to still be open the week before go-live.

Then count one number: how many active contacts have no usable VAT identification number. That figure is the size of the data work, and it is far cheaper to know in week one than in week nine.

If you invoice in anything other than rials

Rule IBR-004-OM requires a currency exchange rate whenever the invoice currency is not OMR. IBR-059-OM fixes its direction — the source currency is the invoice currency and the target is the tax accounting currency — and IBR-065-OM requires the invoice total VAT amount in the tax accounting currency when that currency is OMR. A Xero organisation whose base currency is not the rial therefore has a rate to supply and a converted VAT total to agree with its accountant, and that is a conversation, not a configuration.

We run several Xero organisations. Is that one connection or several?

Several, and treating it as one is a real risk rather than a technicality. A Xero login routinely covers more than one organisation, and each Omani entity is registered with the Tax Authority under its own VAT identification number. Each entity is therefore its own connection, its own participant on the network, and its own stream of documents.

Two practical consequences. A group planning "the Xero rollout" is planning several rollouts that happen to share a login, and the customer-master clean-up has to be done in each organisation that raises Omani invoices. And Xero applies its limits per organisation — 60 calls a minute and 5,000 a day — which matters when someone designs a first-month catch-up that pushes a year of history through in an afternoon.

Does the Tax Authority receive the same file as your buyer?

No, and assuming it does is the second most common misunderstanding after the format. Your buyer receives the invoice. A tax data document, derived from that invoice and carrying it, goes to the Oman Tax Authority. It has its own structure and its own rule pack, which is why a clean validation on the invoice can still leave work to do.

The document is walked through field by field in inside the Oman tax data document, and the exchange model behind it — five corners rather than the familiar four — is explained in Oman's Fawtara five-corner model.

How do you know an invoice will be accepted before you send it?

By validating a real one, early. A document is checked against the full PINT OM rule set including its Schematron rules, and what comes back names the rule that fired by its own identifier — IBR-069-OM rather than "invalid tax line". An error naming the field and the rule is a ticket somebody can act on.

Counted in the packs GoRoute ships on 24 August 2026: 170 rules in the shared Peppol layer, all of them fatal; 154 in Oman's own jurisdiction pack, of which 152 are fatal and exactly two are warnings; and 66 in the tax data document pack, all fatal. Two things about reading the results matter more than they look. Severity comes from the rule file rather than from how the message reads, so a finding worded as advice can still refuse the document. And a warning is not noise — Oman deliberately accepts some documents with a warning, 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.

The order the checks run in is set out in what format an Oman e-invoice must be in; why Oman e-invoices get rejected reads an actual result identifier by identifier, and how to test an Oman e-invoice before you send it covers doing this before the Authority ever sees the document.

Which Oman deadline applies to a Xero user?

The same one that applies to everyone else. It depends on annual supplies, not on your accounting system. Decision 189/2026 makes electronic tax invoices mandatory from 1 April 2027 for taxable persons whose annual supplies exceed OMR 5,000,000, and from 1 October 2027 for those at or below that figure.

Xero's Omani users sit mostly in the second group, which reads like more time and is not: the data work above is the same size in both waves, and the second wave has fewer consultants left unbooked. What the Decision changed is on the page that owns the Oman dates, and which wave am I in works through the threshold. This page states no further dates deliberately: one page should own that question.

Where do the invoices live?

For Oman, in Oman. GoRoute operates in-country data residency for Omani clients — invoices, keys, tax data documents and audit logs. The detail is on data residency and compliance in Oman.

Data residency is usually raised late, by a security review, at the point where changing the answer is expensive. It is a much cheaper question in week one.

What to do this week

1. Export your contact list from Xero and count the records with no VAT identification number in the OM plus ten digits form. One number, and it sizes the data work.
2. List every zero per cent tax rate in each organisation and decide, for each, zero-rated or exempt and which Oman code. This is the long pole.
3. Decide where units of measure will come from — a default, the item master, or a mapping table — and name who owns it.
4. Check your amount precision: three decimal places, not two.
5. Count your Xero organisations that raise Omani invoices. Each is its own rollout.
6. Establish which date applies to you by annual supplies.
7. Ask any shortlisted provider for their Oman accreditation in writing, and check it.

Running something other than Xero?

The same question, answered for the systems next to Xero in Omani finance functions: QuickBooks, Zoho Books, Odoo, SAP S/4HANA, Microsoft Dynamics 365, Oracle Applications, TallyPrime, and, where invoices start in a spreadsheet, Excel. If you wrote your own billing or point-of-sale software, connect it directly sets out what your code must produce and what we add.

For the interface itself, see the API and services page and the developer documentation; for the market as a whole, the Oman page. A document can be validated against the full Oman rule set before you commit to anything through the free sandbox. If it is easier to talk it through against your own Xero organisation, book a working session.

Where GoRoute stands

GoRoute is an e-invoicing service provider accredited in Oman by the Oman Tax Authority, on 29 July 2026, through Union Digital Technologies SPC. It operates a Peppol-certified Access Point (Service Provider ID POP000991, ClayDesk LLC).

Those are checkable facts rather than adjectives, which is the point: ask any provider for the equivalent. How to check an Oman provider's claim sets out the questions worth asking.

Sources

• PINT OM Billing Process v1.0.1 — the Oman specification the validation rules come from
• Oman Tax Authority — Fawtara — the national e-invoicing programme
• Oman Tax Authority tax portal
• OASIS UBL 2.1 — the underlying document syntax
• OpenPeppol — the network the exchange runs on

The Xero capability described here is what GoRoute publishes on its own managed service and Peppol pages and in its developer documentation, read on 24 August 2026, together with the field map its Xero connector ships. Every rule identifier and field constraint was read on the same day in the Oman 2026-Q2 final rule packs GoRoute ships, the Oman eInvoicing Data Dictionary v1.0.1 and the Oman Solution Reference Architecture v1.0.1. No other capability is claimed for Xero on this page, and no price is quoted.