The Oman E-Invoicing Data Dictionary, Explained

The Oman e-invoicing data dictionary is the Oman Tax Authority's list of every field an Oman e-invoice can carry. Version 1.0.1 holds 289 rows: each is a business term or a group of terms, with an identifier, a definition, how many times it may appear, its place in the UBL file and the rules that touch it. If you are mapping an ERP to Oman, it is the first document to open.

The rest of this page explains how to read it: how the identifiers work, the field groups, which fields are mandatory and which are optional, and how the dictionary relates to the rule packs that actually accept or refuse a file. The figures below were counted on 8 November 2026 from a machine-readable extract of version 1.0.1 that GoRoute keeps, not recalled.

What is in the dictionary, and how is it organised?

It is a table of business terms, grouped. A business term (BT) is one field, such as the invoice number. A business group (BG) is a block of terms that belong together, such as the seller, which holds a name, an address, an identifier and a contact.

Of the 289 rows, 214 are international terms and groups inherited from the Peppol invoice model, and 75 are Oman additions: 65 business terms numbered BT-OM-1 onwards and 10 groups numbered BG-OM-1 onwards. Each row gives:

• the identifier and name
• the definition
• the cardinality, written 1..1 (exactly one), 0..1 (optional) or 0..n (optional and repeatable)
• the UBL path, which is where the value sits in the XML file
• the code list, if the value must come from one
• the business rules that refer to it

That UBL path is the useful column for an integrator. It turns "the exchange rate" into cac:TaxExchangeRate/cbc:CalculationRate, which is what your mapping needs to write to. The file format itself, UBL 2.1 XML in the PINT OM profile, is covered in what format an Oman e-invoice must be in.

What are the field groups?

Reading the dictionary top to bottom, the fields fall into these groups. Each group is a section of the file, so each one is a section of your mapping.

Two of those groups come up most when an Oman file is being built for the first time. The VAT breakdown has its own pages: which reason code a zero-rated or exempt line needs. And the totals group has a currency dimension: how a USD invoice meets Oman's rial rules.

Which fields are mandatory?

The cardinality column answers this: 1..1 means the field must be present. In version 1.0.1, 70 rows carry 1..1. Many of them are only required inside a block that is itself optional. A delivery country is 1..1, for example, but only if you send a delivery block at all.

The working core, for a plain domestic invoice, is shorter than 70:

• Document: invoice number (BT-1), issue date (BT-2), type code (BT-3), currency (BT-5), business process (BT-23), specification identifier (BT-24)
• Seller: name (BT-27), electronic address and its scheme (BT-34), country (BT-40), tax scheme code (BT-31-1)
• Buyer: name (BT-44), electronic address (BT-49), country (BT-55)
• Totals: sum of line amounts (BT-106), total without VAT (BT-109), VAT total (BT-110), total with VAT (BT-112), amount due (BT-115)
• VAT breakdown: taxable amount, tax amount and category code (BT-116, BT-117, BT-118)
• Each line: line identifier (BT-126), quantity and unit (BT-129, BT-130), net amount (BT-131), net price (BT-146), VAT category (BT-151), item name (BT-153)

That is a reading of the cardinality column, not a statement of everything the rules will demand. A field can be optional in the dictionary and still be required by a rule that depends on another value, which is why a file can satisfy every 1..1 and still be refused. The rejections article goes through those rules by identifier.

Which fields are specific to Oman?

Sixty-five terms and ten groups. Eight of the terms are mandatory:

The first five are about identity and integrity: what kind of supply this is, a unique number for the document, and the QR code, signature and hash that tie the file together. Your ERP does not calculate the QR code, the signature or the hash. They are produced when the document is rendered and signed.

The last two are about arithmetic, and they are the ones that catch ERP integrations. Oman wants the VAT amount and the total including VAT on every line, not only in the totals. Most invoicing systems compute those for display and never put them in an export, so they have to be added to the mapping.

The remaining 57 Oman terms are not marked mandatory, and they cluster into a few jobs:

• Foreign currency: the exchange rate (BT-OM-3) and the VAT amounts restated in rials (BG-OM-9, BG-OM-10)
• Exemptions: reason codes and reason text at line and document level (BT-OM-69, BT-OM-70, BT-OM-72, BT-OM-73, BT-OM-89, BT-OM-90)
• Classification: industrial classification (BT-OM-18), item type, goods or services (BT-OM-19) and service type (BT-OM-15)
• Corrections and prepayments: the preceding invoice UUID, the prepayment invoice number and UUID, the credit or debit note reason, and the paid amounts group
• Imports: import date, customs declaration number and Incoterms (BG-OM-5)
• Third party: an agent's name, VAT number and address (BG-OM-1, BG-OM-2)

The issue time (BT-OM-33) is listed as optional in the dictionary, and two rules refer to it. Our own format article treats it as required by the aligned profile, so send it.

How does the dictionary relate to the rule packs?

The dictionary states the rules in words. The packs are those rules written as checks that software runs, and they are what accepts or rejects your file.

The dictionary counts 336 business rules in all, and that count is the dictionary's own. They are the international rules inherited from the Peppol model (identifiers beginning BR-, BR-CL- for code lists, BR-CO- for calculations, and the four VAT-category sets BR-S-, BR-Z-, BR-E- and BR-O-) plus 242 Oman rules numbered BR-OM-1 onwards.

The packs number the Oman rules differently. A rule the dictionary calls BR-OM-104 is reported by the pack as IBR-104-OM, and the pack message uses the same words: if the VAT category for the amount in accounting currency is S, its rate must be 5. When a rejection arrives, it carries the pack's identifier, and the dictionary row for the same number tells you which term it concerns.

The two do not always say exactly the same thing. Two examples, both found while preparing this page:

• The dictionary's BR-OM-5 says the exchange rate should carry at most four decimal places. The pack we run in production, IBR-005-OM, allows seven.
• The dictionary's BR-OM-80 says an item classification code should have a minimum of 12 digits. The pack's IBR-080-OM requires exactly 12 for an HS code.

Neither is an error on anyone's part. A spreadsheet states intent, and a pack is the version that was compiled and published. Where they differ, build to the pack: it is what validates the file. The two cases above have their own pages: foreign currency and the 12-digit HS code.

What the dictionary leaves out

Three things are not in it, and a mapping exercise that stops at the dictionary will miss them.

The tax data document. The dictionary describes the invoice. The separate document sent to the Authority has its own fields: the tax data document, field by field.

The signing and sending. The dictionary says a signature, hash and QR code must be present. It does not describe producing them. That is the issuing system's job.

Your own data quality. The dictionary cannot tell you that your customer master holds a buyer with no country, or that your item master has no HS codes. Those gaps surface as rejections. The fastest way to find them is to validate real documents before sending any: how to test an Oman e-invoice before you send it.

What is not settled here

Versions move. This page reads version 1.0.1 of the dictionary and the 2026-Q2 final packs. If the Authority publishes a later version, the counts will change and the shape of the answer will not. The version history is tracked here.

A dictionary is not a legal text. It describes what a valid file contains. What your business must issue, and when, is set by the mandate and the Authority's decisions, and nothing here is a statement about your compliance position.

What to do with this

If you are the person mapping an ERP, open the dictionary beside your invoice export and mark each 1..1 row against a source field. The rows with no source field are your work list. The line-level VAT amount and total (BT-OM-16, BT-OM-17) are the first to check, because most systems do not export them.

If you would rather not build and maintain the mapping to UBL yourself, that is what an accredited service provider is for. GoRoute takes invoice data as plain JSON, renders the UBL, applies the rules, signs and sends. The Oman e-invoicing page sets out what that involves, the documentation has the API reference, and the tutorials show it working end to end.

To talk through your own system, book a demo.

GoRoute is accredited by the Oman Tax Authority on 29 July 2026 through Union Digital Technologies SPC, and is a certified Peppol Access Point (POP000991).

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