In Oman's Fawtara system, an invoice is only as trustworthy as its Seller UUID. This single identifier, generated directly from the invoice data, is the line between an invoice the Oman Tax Authority (OTA) accepts and one it rejects. Change anything on the invoice and the UUID breaks, exposing the tampering instantly.
This article explains what the Seller UUID is in the Oman context, why it is built the way it is, and the exact four-step process used to generate it for inclusion on the invoice, the Tax Data Document (TDD), and the QR code.
Table of Contents
Where the Seller UUID Fits in Oman's Model
Oman's e-invoicing framework is built on the Peppol-based Fawtara system. Invoices are exchanged in structured form, reported to the OTA, and, for human-readable and consumer-facing output, accompanied by a QR code. The OTA has confirmed that the human-readable version of an invoice must comply with its specifications and will carry a QR code that allows the buyer to validate the e-invoice, with the finer QR details to be published by the authority in due course.
Within this model, the Seller UUID is generated by the seller, referred to here as C1, and passed to the next party in the chain, C2, as part of the invoice data. It serves two purposes at once. It appears on the invoice and on the Tax Data Document (TDD), which is the structured record reported to the OTA, as a unique reference. It is also derived from the QR code fields and then embedded back into the QR code that travels with the invoice.
What makes the Seller UUID more than a random reference number is how it is derived. Because it is generated from the invoice content itself and then encoded back into the QR code, it creates a tight, verifiable link between the identifier and the underlying data.
Why UUID Version 5
The Seller UUID uses UUID version 5, and this choice is deliberate. UUIDv5 is deterministic and hash-based. It produces the same output every time it runs over the same input, combining a fixed namespace with the input content.
This determinism is exactly what an invoice identifier needs in a tax-controlled environment. Because the UUID is effectively a hash of the invoice fields, any change to the underlying content produces a completely different UUID. In practice, a new UUID is generated whenever the content changes. If the invoice data is identical, the UUID is identical. If a single field is altered, the regenerated UUID will not match, which makes tampering immediately detectable by any party that recalculates it.
A random identifier, such as a UUID version 4, could not offer this guarantee, because it carries no relationship to the data it identifies. For a mandate built around transparency and fraud reduction, that link between identifier and content is the whole point.
The Four-Step Generation Process
Generating the Seller UUID follows four precise steps. Each step matters, and skipping or reordering any of them will produce the wrong result.
Step 1: Define the QR Version and Invoice Type
Start by defining the QR Version and the Invoice Type as set out in the TLV (Tag-Length-Value) table. These values establish which fields are included and how the rest of the process unfolds, since the set of fields can depend on the invoice type, such as a standard tax invoice versus a simplified invoice.
Step 2: Concatenate the Field Values
Take the relevant field values, meaning all fields except the UUID itself, with the exact set depending on the invoice type, and join them into a single string. Use the pipe character "|" as the separator between each field.
The result is one continuous string in which each invoice field is delimited by a pipe. The UUID field is deliberately excluded from this string, since the UUID is the output of the process, not an input to it.
Step 3: Convert the String to Uppercase
Ensure that every letter in the final concatenated string is uppercase. This step is not cosmetic. UUIDv5 generation is case sensitive, which means "abc" and "ABC" would hash to two entirely different UUIDs. Forcing the string to uppercase guarantees a consistent, reproducible input regardless of how the source data was originally cased.
Step 4: Generate the UUIDv5
Finally, generate the UUIDv5 using the fixed namespace:
e0bc4ac8-b025-46e5-a76d-0c893fc3027e
The UUIDv5 algorithm combines this namespace with the uppercased, pipe-delimited string and produces the deterministic identifier. That identifier becomes the Seller UUID, ready to be placed on the invoice and the TDD, and embedded back into the QR code.
Putting It Together
The design forms a closed loop. The seller assembles the QR code fields, concatenates and uppercases them, and hashes the result against a fixed namespace to produce a UUIDv5. That UUID then lives on the invoice, on the Tax Data Document reported to the OTA, and inside the QR code itself.
Because the identifier is derived directly from the invoice content, anyone who later regenerates the UUID from the same fields should arrive at the same value. A mismatch is a clear signal that the invoice data has changed. This is what gives the Seller UUID its integrity guarantee, and it is why the four steps must be followed exactly: the correct QR version and invoice type, the right fields in the right order, pipe delimiters, uppercase normalization, and UUID version 5 against the fixed namespace.
A Note on Final OTA Specifications
The Oman Tax Authority has confirmed that a QR code will be required on the human-readable invoice for buyer validation, and that the detailed QR specifications will be released as the Fawtara rollout progresses. Businesses preparing for the mandate should implement their Seller UUID and QR generation in line with this structure while staying ready to align with the OTA's final published technical details.
Working with an OTA-accredited e-invoicing service provider is the most reliable way to ensure your UUID and QR implementation remains compliant as the specifications are finalized.
Get Fawtara-Ready with SMARTeIS
SMARTeIS by Skill Quotient Technologies is an OTA pre-approved, Peppol-certified e-invoicing solution built to handle Oman's Fawtara requirements end to end. From Seller UUID and QR generation to PINT-OM structured exchange, TDD reporting, and real-time validation, the platform manages the technical details so your finance and IT teams do not have to.
With integration across 150+ ERP and POS systems, a built-in validation engine that catches errors before they reach the OTA, and secure long-term archiving, SMARTeIS helps businesses stay compliant as the Oman e-invoicing mandate rolls out and as final OTA specifications are published.
Book a free consultation with our team to assess your readiness for the Oman e-invoicing mandate and start your transition to compliant, Fawtara-ready invoicing today.
Talk to our Oman e-invoicing Expert!
Get a personalized Fawtara readiness assessment and discover the fastest path to compliance before your wave goes live.
Enquire Now!