Fawtara API integration means posting your invoice data to one endpoint. GoRoute maps it to PINT OM, validates it against the official Schematrons, applies the XAdES signature, generates the UUID, hash and TLV QR code, sends the invoice over Peppol and files the Tax Data Document with the Oman Tax Authority.
Full Oman Tax Authority Compliance
GoRoute.ai is a fully accredited service provider for Oman's Fawtara E-Invoicing Project, having completed OpenPeppol PINT testing and Oman Tax Authority accreditation.
An Oman e-invoicing solution has to issue PINT OM invoices that pass the official Schematrons, sign them with XAdES, produce the TLV QR code, exchange them over Peppol through an accredited access point, file a Tax Data Document with the Tax Authority, receive inbound documents, and retain everything for audit.
GoRoute does each of those as an accredited Fawtara service provider. The Fawtara readiness guide sets out what each one takes to build, and how to choose a provider covers what to ask before you sign.
Everything you need to meet Oman Tax Authority e-invoicing requirements
Automatic enveloped XAdES signature for every invoice. Cryptographic proof of authenticity and integrity as required by Oman Tax Authority.
TLV-encoded QR codes carrying the fields the architecture requires: QR version, invoice type, invoice number, seller name, seller VATIN, invoice date, issuance time, total including VAT, VAT total, and the seller UUID. Scannable by tax inspectors.
Unique identifier (UUID) and SHA-256 cryptographic hash for each invoice ensuring traceability and tamper-proof records.
Oman-specific line item VAT amounts (BT-OM-16) and line totals including VAT (BT-OM-17) calculated automatically.
Pre-submission validation against all Oman eInvoicing Data Dictionary rules. Catch errors before they cause rejections.
Native Omani Rial support with automatic currency conversion. Foreign currency invoices include OMR tax amounts.
Generate compliant documents for all Oman business scenarios
Code 388
Standard VAT invoice for goods and services
Code 381
Correction for overcharges or returns
Code 383
Additional charges after original invoice
Code 386
Advance payment before delivery
All Oman-approved VAT category codes with automatic validation
5% VAT
0% with reason
VAT exempt supplies
Not subject to VAT
Buyer accounts for VAT
Oman's PINT profile adds 120 country-specific rules on top of Peppol BIS Billing 3.0. These are the ones that decide whether your invoice clears — taken from the ruleset GoRoute validates against, not from a summary.
Asking what the file itself has to be — UBL 2.1 XML, the PINT OM profile, and whether JSON is an alternative? That question is answered in full in what format an Oman e-invoice must be in.
Oman-specific rules (IBR-…-OM)
Document types with their own rule packs
Zero-rating reason codes (VATZR-OM)
Exemption reason codes (VATEX-OM)
Every Oman invoice carries a 20-character string of 1s and 0s, with at least one 1. Fifteen of the twenty positions are defined; the remainder are reserved. Each position marks an active transaction type, and several rules key off specific positions — set the wrong bit and an otherwise valid invoice is rejected.
0248 — the identifier that trips people up
Oman participants are registered under Peppol scheme 0248, and the identifier keeps its OM prefix. A common integration error is registering under a generic scheme or stripping the country prefix — the participant then cannot be resolved through SMP lookup, and senders get a delivery failure that looks like a network problem rather than a registration one.
| Rule | Applies to | What it requires |
|---|---|---|
| IBR-032-OM fatal | Credit note 381, debit note 383, self-billed credit note 261 |
Must carry the preceding invoice reference (IBT-025), issue date (IBT-026) and UUID (BTOM-031). All three. Missing any one is fatal — and a credit note is the single most common thing to get wrong. |
| IBR-177-OM | Self-billed invoice 389, self-billed credit note 261 |
BTOM-001 is restricted to a short list: self-billed, import of services under RCM, profit-margin self-billing, or import of goods. Self-billing outside those cases is rejected. |
| IBR-002-OM | All documents | The invoice UUID must be a deterministic version 5 UUID, not a random one. Re-deriving the same invoice must produce the same UUID. |
| IBR-034-OM | Any non-OMR invoice | If the invoice currency (IBT-005) is not OMR, the VAT accounting currency (IBT-006) must be present. |
380 Commercial invoice — the standard case381 Credit note383 Debit note386 Prepayment invoice389 Self-billed invoice — buyer issues on the supplier's behalf261 Self-billed credit noteGoRoute ships separate rule packs for invoice, credit note, self-billed invoice and self-billed credit note — each validated against its own Schematron rather than one generic pass.
Zero-rated and exempt lines must carry a reason code from the Oman code lists — VATZR-OM-01 to VATZR-OM-16 for zero-rating, and VATEX-OM-01 to VATEX-OM-12 for exemption. A zero-rated line with no reason code fails validation.
This matters most for importers and exporters: export of services and re-export of goods each have their own code, and medicines and Ministry-of-Health-approved medical equipment are zero-rated under Ministerial Decision 59/2021, made under Articles 51–53 of Sultani Decree 151/2020.
See it running: the Odoo and Oracle APEX demos both validate against this ruleset end to end.
Four separate passes, not one. An Oman invoice is checked against UBL 2.1 syntax, the general PINT rules, the Oman-specific jurisdiction rules, and — once it has been turned into a Tax Data Document — the Authority's own TDD rules. Each pass is a different file of published rules, and each can reject an invoice the previous pass accepted.
| Pass | Rule file | Assertions | What it catches |
|---|---|---|---|
| 1 — syntax | XSD schema for UBL 2.1 Invoice or CreditNote |
— | Malformed XML, elements in the wrong order, unknown elements. A document that fails here is not an invoice yet. |
| 2 — PINT | PINT-UBL-validation-preprocessed.sch | 171 | The general Peppol International model: totals that must add up, mandatory business terms, VAT breakdown consistency. |
| 3 — Oman | PINT-jurisdiction-aligned-rules.sch | 150 | Oman's own additions, carrying 151 rule identifiers ending -OM — BTOM-001, the credit-note reference rule, the VAT reason codes, the OMR accounting-currency rule. |
| 4 — TDD | peppol-om-tdd.sch | 60 | The Tax Data Document built from your invoice and sent to the Authority. Every one of its 60 assertions is flagged fatal. |
Counts read directly from the Oman Tax Authority's published developer packages for PINT OM Billing and the Tax Data Document, both released 2026-04-08. The credit-note package carries the same 150 jurisdiction assertions as the invoice package.
Validation is not a single gate at the end. The 5-corner model puts it in three places, and the further along a failure happens, the more people know about it:
Source: Oman — Solution Reference Architecture v1.0.3 of 2026-07-27, §6.1.2, §6.6 and §7.1.2.
An ERP validates against its own data model: that a customer exists, that the lines total correctly, that the VAT code is one it knows. None of that is what Oman checks. The rules that reject an Oman invoice are about things an ERP has no opinion on:
This is the gap validation software fills: it runs the Authority's published rules over your document before the network does. How to test an Oman e-invoice before you send it walks through doing it, and why Oman e-invoices get rejected covers reading the failures that come back.
GoRoute runs all four passes on submission and returns the failures with the rule identifier that produced each one, so you are debugging a named rule rather than guessing. Run your own invoices against it in the free sandbox, with no commitment and no accreditation of your own required.
The XML Oman accepts is UBL 2.1 in the PINT OM profile, and your system does not have to produce it. You send us the invoice in whatever shape your software already emits — UBL XML, JSON, or through a connector — and the conversion, signing, identifier derivation and Peppol transmission happen on our side.
Common with SAP, Oracle and anything that already sends invoices in Europe. Post the document as it stands. We map it into the PINT OM profile, add the Oman-only business terms your European profile has no field for, and validate before transmission.
Post JSON to the REST API and the UBL XML is constructed for you. Nothing in your codebase needs to learn UBL. This is the usual route for in-house billing, point-of-sale and subscription systems.
A connector reads the invoice out of the system and does the rest. No XML reaches your finance team at all. Wrote your own system? — what your code must produce, and what we add.
An Oman invoice is routed by its document type identifier, not by its file name. These are the strings the architecture names, and getting one wrong is the difference between a delivered invoice and a document the network cannot place:
The process identifier is urn:peppol:bis:billing or urn:peppol:bis:selfbilling, and the Tax Data Document travels under urn:peppol:taxreporting. The participant identifier keeps scheme 0248 and its OM prefix. Full string reference: PINT OM CustomizationID and ProfileID.
Oman derives the invoice UUID from the invoice's own content using a version 5 UUID, so the same invoice always produces the same identifier — and the sending and receiving providers derive it independently and must agree. The name it is computed from is built out of six fields, all mandatory:
IBT-034-1 the seller identifier's schemeIBT-034 the seller identifierIBT-003 the invoice type codeIBT-001 the invoice numberIBT-002 the invoice dateIBT-110 the invoice total tax amountThe practical consequence for an integration: if your export re-formats a date, pads an invoice number, or rounds the tax total differently on a second run, the UUID changes and the document is a different invoice as far as Oman is concerned. Source: Oman — Solution Reference Architecture v1.0.3, §10.2.1 and §10.2.3. The document built from your invoice for the Authority is covered in inside the Oman Tax Data Document.
Nothing above requires you to build AS4 transport, hold a certificate, or register in the SMP yourself — that is what an accredited provider is for. Start with the free sandbox and the API integration guide, or read what format an Oman e-invoice must be in first.
One REST call covers issuance, validation, Peppol transmission and the Tax Data Document. Connect your ERP, accounting software or custom application, and try it against the free sandbox before you commit.
Submit invoices via simple JSON or UBL XML API. Get real-time validation results and signed documents back.
POST /api/v1/invoices
{
"seller_vat": "OM1234567890",
"buyer_vat": "OM0987654321",
"currency": "OMR",
"items": [...],
"cius": "OM" // Oman CIUS validation
}Ready-made integrations for popular business software used in Oman and the GCC region.
Written up per system, with the Oman rules each one has to satisfy: Microsoft Dynamics 365, SAP S/4HANA, Odoo, Oracle Applications, QuickBooks, Xero, Zoho Books, Sage, TallyPrime and Excel. Wrote your own billing, point-of-sale or ERP software? Connect it directly — what your code must produce, and what we add.
Start generating compliant e-invoices with digital signatures, QR codes, and full Tax Authority validation in minutes.
Everything you need to know about Oman Fawtara e-invoicing compliance
Fawtara is Oman's electronic invoicing initiative managed by the Oman Tax Authority. Decision 189/2026 makes electronic tax invoices mandatory from 1 April 2027 for taxpayers whose annual supplies exceed OMR 5,000,000, and from 1 October 2027 for those at or below that threshold. Simplified (B2C) invoices follow the same timeframes. GoRoute.ai helps you prepare now to avoid last-minute compliance rushes.
Oman VAT numbers follow the format OM followed by 10 digits (e.g., OM1234567890). This is mandatory for all Oman-based sellers on electronic invoices. GoRoute.ai validates VAT number format before submission to catch errors early.
Oman e-invoice QR codes must contain TLV (Tag-Length-Value) encoded data including: Seller name, Seller VAT number, Invoice timestamp, Invoice total with VAT, and VAT amount. GoRoute.ai automatically generates compliant QR codes and embeds them in your invoices with the correct mimeCode (text/csv).
Oman requires XAdES (XML Advanced Electronic Signatures) in enveloped format within UBL Extensions. The signature must use the standard URI 'urn:oasis:names:specification:ubl:signature:Invoice' and method 'urn:oasis:names:specification:ubl:dsig:enveloped:xades'. GoRoute.ai handles all cryptographic signing automatically using your organization's certificate.
Oman's standard VAT rate is 5%. This applies to most goods and services unless specifically exempted or zero-rated. GoRoute.ai validates that standard rate (S) line items include the correct 5% rate and warns if a different rate is used.
Oman Credit Notes (type code 381) must reference the original invoice they are correcting. This includes the original invoice number (BT-OM-31 - Invoice ID reference) and optionally the UUID of the original invoice. A reason code (BT-OM-32) should also be provided. GoRoute.ai enforces these references during validation.
Oman requires 8 additional fields beyond EN16931: BT-OM-01 (Invoice UUID), BT-OM-14 (QR Code), BT-OM-16 (Line VAT Amount), BT-OM-17 (Line Total incl. VAT), BT-OM-28 (Digital Signature), BT-OM-29 (Invoice Hash), BT-OM-84 (Document Reference per line). GoRoute.ai validates all 75 Oman-specific fields.
Yes, but with conditions. Domestic Oman invoices should use OMR (Omani Rial). If you invoice in USD, EUR, or other currencies, you should set OMR as the Tax Currency (cbc:TaxCurrencyCode) so tax amounts are calculated in OMR. GoRoute.ai validates this and warns if neither document nor tax currency is OMR.
The Oman eInvoicing Data Dictionary v1.0.1 defines 336 business rules, 290 business terms, and 17 code lists. These cover everything from mandatory field presence to value validations and cross-field calculations. GoRoute.ai implements all rules as Schematron validation, catching errors before submission.
Yes! Oman is now an official Peppol Authority. This means businesses in Oman can send and receive compliant e-invoices through the Peppol network to 40+ countries worldwide. The Fawtara specification is built on EN16931 and UBL 2.1 — the same foundation as Peppol BIS 3.0. GoRoute.ai provides full support for both Oman's domestic Fawtara requirements and international Peppol connectivity through a single platform.
Oman Fawtara, Saudi ZATCA Fatoora and the coming Qatar mandate share similar concepts — both require digital signatures, QR codes, and unique identifiers. However, the technical specifications differ in details (field mappings, code lists, validation rules). GoRoute.ai supports both with country-specific CIUS modules, so you can invoice to both countries with a single integration.
GoRoute.ai validates invoices before submission and provides detailed error messages with the exact rule that failed (e.g., BR-OM-01: Missing UUID). Each error includes the XPath location and expected value so you can fix the issue quickly. Fatal errors block submission; warnings are informational. Our API returns all validation results in a structured JSON response.
GoRoute.ai is operated by ClayDesk LLC, a US-based technology company and the legal entity behind the GoRoute.ai e-invoicing platform. ClayDesk is a certified Peppol Service Provider (POP000991) serving Oman and 40+ other Peppol-connected jurisdictions through a single Peppol-certified global infrastructure.
Book a demo with our team to see how GoRoute can simplify your e-invoicing compliance.