Skip to main content

Oman 🇴🇲

E-invoicing requirements and Peppol compliance for the Sultanate of Oman.

Overview​

AspectDetails
Tax AuthorityOman Tax Authority (OTA)
B2G MandateActive — Peppol network
B2B MandatePhased rollout (2025–2027)
Required CIUSPINT OM (Official OpenPeppol PINT Oman)
Primary Scheme0248 (Oman VATIN)
CurrencyOMR (Omani Rial, 3 decimal places)
VAT Rate5% standard rate
QR CodeMandatory — Fawtara TLV format
Digital SignatureXAdES-BES enveloped signature
Oman Peppol Authority

Oman joined the Peppol network under the OpenPeppol umbrella. The Oman Tax Authority (OTA) mandates Peppol-based e-invoicing with additional national requirements (Fawtara CIUS) on top of standard Peppol BIS 3.0.

Oman PINT OM (Official Schematrons)​

The official OpenPeppol PINT OM specification replaces the earlier Fawtara CIUS. It includes billing, self-billing, and Tax Data Document (TDD) Schematrons.

Customization IDs​

<!-- PINT OM Billing -->
<cbc:CustomizationID>urn:peppol:pint:billing-1@om-1</cbc:CustomizationID>

<!-- PINT OM Self-Billing -->
<cbc:CustomizationID>urn:peppol:pint:selfbilling-1@om-1</cbc:CustomizationID>

<!-- TDD (Tax Data Document) -->
<cbc:CustomizationID>urn:peppol:taxdata:om-1</cbc:CustomizationID>

Profile IDs​

<!-- Billing / Self-Billing -->
<cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>

<!-- Tax Reporting -->
<cbc:ProfileID>urn:peppol:taxreporting</cbc:ProfileID>

Schematron Packs​

GoRoute runs the official OpenPeppol PINT OM Schematrons compiled with Saxon-HE 12.4:

PackSchematronsDescription
Billing Invoice2 (preprocessed + jurisdiction-aligned)Standard tax invoice validation
Billing Credit Note2Credit note validation
Self-Billing Invoice2Self-billing invoice validation
Self-Billing Credit Note2Self-billing credit note validation
TDD1Tax Data Document for CTC reporting

PINT OM documents are auto-detected by the urn:peppol:pint:billing-N@om-N or urn:peppol:pint:selfbilling-N@om-N CustomizationID pattern and skip baseline CEN+BIS Schematrons.

Ruleset 1.0.1 — the rules that reject invoices​

PINT OM 1.0.1 layers 120 Oman-specific rules (IBR-…-OM) on top of Peppol BIS Billing 3.0. Most are structural and you will never see them. These are the ones that actually fail in production.

Document type codes​

CodeDocumentNotes
380Commercial invoiceThe standard case
381Credit noteRequires a preceding invoice reference — see IBR-032-OM
383Debit noteSame preceding-invoice requirement
386Prepayment invoice
389Self-billed invoiceBuyer issues on the supplier's behalf. Restricted by IBR-177-OM
261Self-billed credit noteRequires a preceding reference and is restricted by IBR-177-OM

BTOM-001 — invoice transaction type​

Every Oman document carries a 20-character bitmap of 1s and 0s with at least one bit set. It travels in the name attribute of the type code element, not as a separate field:

<cbc:InvoiceTypeCode name="00100000000000000000">389</cbc:InvoiceTypeCode>

Fifteen of the twenty positions are defined; the rest are reserved. Two examples that appear in the rules verbatim:

BitmapMeaning
00100000000000000000Self-billed invoice / credit note
00000000100000000000Invoice for import of services under reverse charge

IBR-001-OM enforces the shape — exactly 20 characters, [01] only. Several other rules then key off individual positions, so a structurally valid bitmap with the wrong bit set still fails.

IBR-032-OM — the one that catches everyone​

Fatal. If the type code is 381, 383 or 261, the document MUST carry all three of the preceding invoice's reference, issue date and UUID. Missing any one is a hard rejection:

<cac:BillingReference>
    <cac:InvoiceDocumentReference>
        <cbc:ID>INV-2026-00042</cbc:ID>                      <!-- IBT-025 -->
        <cbc:IssueDate>2026-07-14</cbc:IssueDate>            <!-- IBT-026 -->
        <cbc:UUID>7d4f1e2a-...-9c3b</cbc:UUID>               <!-- BTOM-031 -->
    </cac:InvoiceDocumentReference>
</cac:BillingReference>

The UUID is the one people omit, because BIS Billing 3.0 does not ask for it. It must be the original invoice's UUID, not a fresh one.

IBR-177-OM — self-billing is not general purpose​

A self-billed invoice 389 or self-billed credit note 261 is only valid when BTOM-001 is one of a short list: self-billed, import of services under reverse charge, profit-margin self-billing, or import of goods. Self-billing outside those cases is rejected — this is a policy rule, not a formatting one.

IBR-002-OM — deterministic UUIDs​

The invoice UUID must be a version 5 UUID, not random. Re-deriving the same invoice must produce the same UUID, which is what makes the preceding-invoice reference in IBR-032-OM verifiable.

IBR-034-OM — non-OMR invoices​

If the invoice currency (IBT-005) is not OMR, the VAT accounting currency (IBT-006) MUST be present.

Zero-rating and exemption reason codes​

A zero-rated or exempt line needs more than a Z or E category — it needs a reason code from the Oman code list. Without one, validation fails.

ListCodesUsed for
VATZR-OM-01 … VATZR-OM-1616Zero-rating reasons
VATEX-OM-01 … VATEX-OM-1212Exemption reasons
<cac:TaxCategory>
    <cbc:ID>Z</cbc:ID>
    <cbc:Percent>0</cbc:Percent>
    <cbc:TaxExemptionReasonCode>VATZR-OM-09</cbc:TaxExemptionReasonCode>
    <cbc:TaxExemptionReason>Export of service</cbc:TaxExemptionReason>
    <cac:TaxScheme><cbc:ID>VAT</cbc:ID></cac:TaxScheme>
</cac:TaxCategory>

Two that matter most to importers and exporters:

  • VATZR-OM-09 — export of service
  • VATZR-OM-12 — re-export of goods

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.

Validate before you send

POST /api/v1/invoices/validate/deep runs the full PINT OM 1.0.1 Schematron and returns every rule that fired, by identifier. Cheaper than a rejection, and the free sandbox is provisioned within 24 hours.

Identifier Scheme — 0248​

Oman uses scheme 0248 (Oman VATIN) for participant identification, and the identifier keeps its OM prefix.

# Oman participant
participant = {
    "scheme": "0248",
    "identifier": "OM1100012345",
    "name": "Oman Trading Company LLC",
    "country": "OM"
}

Peppol ID Format​

0248:OM<10-digit-VATIN>
Not 9959

Earlier revisions of this page said 9959. That is wrong for Oman and it is a costly mistake: 9959:1100012345 is not a registered participant, so the SMP lookup returns nothing and delivery fails with a transport error rather than a validation message. The authoritative sources are register-oman-tsmp.py (“Scheme : 0248 (Oman VATIN). Participant id: iso6523-actorid-upis::0248:OM<VATIN>”), the OTA sample invoices, and the live SMP registrations.

Example: 0248:OM1100012345

SMP Lookup​

# Verify an Oman participant exists on Peppol
curl "https://smp-test.goroute.ai/iso6523-actorid-upis::0248:OM1100012345"   # registered, resolves

Currency — OMR (3 Decimal Places)​

Oman uses the Omani Rial (OMR) which has 3 decimal places — unlike EUR/USD which have 2.

<!-- All amounts use 3 decimal places -->
<cbc:TaxAmount currencyID="OMR">50.000</cbc:TaxAmount>
<cbc:TaxInclusiveAmount currencyID="OMR">1050.000</cbc:TaxInclusiveAmount>
<cbc:PayableAmount currencyID="OMR">1050.000</cbc:PayableAmount>
3 Decimal Places

Always use 3 decimal places for OMR amounts (e.g., 1050.000, not 1050.00). This applies to all monetary fields in the invoice including line items, tax amounts, and totals.

VAT in Oman​

Oman introduced VAT at 5% in April 2021.

CategoryRateCodeDescription
Standard5%SMost goods and services
Zero-rated0%ZExports, certain food items, healthcare
Exempt0%EFinancial services, residential rent
Z and E are not enough on their own

A zero-rated or exempt line must also carry a reason code — see Zero-rating and exemption reason codes. A Z category with no VATZR-OM-* code fails validation.

<cac:TaxCategory>
    <cbc:ID>S</cbc:ID>
    <cbc:Percent>5</cbc:Percent>
    <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
</cac:TaxCategory>

QR Code Requirements (Fawtara)​

Oman mandates a Fawtara QR code on all invoices. The QR contains TLV (Tag-Length-Value) encoded invoice data that allows offline verification.

TLV Fields​

TagFieldDescriptionExample
1Seller NameSeller's registered name (UTF-8)Al Haya Trading LLC
2VAT NumberSeller's tax registration numberOM1234567890
3TimestampISO 8601 issue date/time2026-02-08T12:00:00Z
4Total with VATTax-inclusive amount (3 decimals)1050.000
5VAT AmountTotal VAT (3 decimals)50.000
6Invoice HashSHA-256 digest (base64)A1B2C3...

TLV Encoding​

Each field is encoded as: Tag (1 byte) + Length (1 byte) + Value (UTF-8 bytes)

Tag 1: [20] = Al Haya Trading LLC
Tag 2: [12] = OM1234567890
Tag 3: [20] = 2026-02-08T12:00:00Z
Tag 4: [8]  = 1050.000
Tag 5: [6]  = 50.000
Tag 6: [44] = <base64 SHA-256 hash>

The concatenated TLV bytes are base64-encoded and embedded in the UBL XML.

QR Embedding in UBL​

The QR data is stored in an AdditionalDocumentReference with ID QR:

<cac:AdditionalDocumentReference>
    <cbc:ID>QR</cbc:ID>
    <cac:Attachment>
        <cbc:EmbeddedDocumentBinaryObject mimeCode="text/csv" filename="QR">
            AQxBbCBIYXlhIExMQwIKT00xMjM0NTY3ODkw...
        </cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
</cac:AdditionalDocumentReference>

Invoice Hash​

A SHA-256 hash of the invoice's business content is also embedded:

<cac:AdditionalDocumentReference>
    <cbc:ID>HASH</cbc:ID>
    <cac:Attachment>
        <cbc:EmbeddedDocumentBinaryObject mimeCode="application/octet-stream" filename="HASH">
            kX5xVq2F8a3pZ...base64-encoded-sha256...
        </cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
</cac:AdditionalDocumentReference>
Whether GoRoute adds these depends on how you send the document

There are two paths and they behave differently. Check which one you are on before you decide whether to generate the QR code, hash and signature yourself.

Documents GoRoute renders for you — POST /api/v1/invoices, drafts, the ERP connectors and the pollers. GoRoute composes the UBL from the data you supply, so the Oman signing pipeline runs over that rendered output and adds the compliance elements, when Oman signing is configured for your environment. See What GoRoute adds on the rendered-document paths below.

Documents you submit as final UBL — POST /api/v1/documents. The XML you send is transmitted exactly as you submitted it. GoRoute adds no QR code, no hash, no cac:Signature and no ext:UBLExtensions on this path. If your invoice needs those elements, put them in the document before you submit it.

That difference is deliberate. A caller posting final UBL has already produced the complete business document, and altering it would break two things you depend on: the copy you archive would no longer match what was transmitted and reported, and any envelope or hash you computed over it would be invalidated.

Digital Signature​

Oman requires an XAdES-BES enveloped digital signature on invoices:

  • Algorithm: RSA-SHA256
  • Canonicalization: Exclusive C14N 1.0
  • Certificate: PKCS12 keystore (.p12)
  • Location: Inside ext:UBLExtensions (UBL DSig Profile)
<!-- Signature reference in the invoice body -->
<cac:Signature>
    <cbc:ID>urn:oasis:names:specification:ubl:signature:Invoice</cbc:ID>
    <cbc:SignatureMethod>urn:oasis:names:specification:ubl:dsig:enveloped:xades</cbc:SignatureMethod>
</cac:Signature>

<!-- Actual cryptographic signature in UBLExtensions (first child of Invoice) -->
<ext:UBLExtensions>
    <ext:UBLExtension>
        <ext:ExtensionContent>
            <sig:UBLDocumentSignatures>
                <sac:SignatureInformation>
                    <ds:Signature Id="invoice-signature">
                        <!-- SignedInfo, SignatureValue, KeyInfo -->
                    </ds:Signature>
                </sac:SignatureInformation>
            </sig:UBLDocumentSignatures>
        </ext:ExtensionContent>
    </ext:UBLExtension>
</ext:UBLExtensions>

Sending via GoRoute API​

curl -X POST https://app.goroute.ai/peppol-api/api/v1/invoices \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "invoice": {
      "document_type": "invoice",
      "number": "OM-INV-2026-001",
      "issue_date": "2026-02-08",
      "due_date": "2026-03-10",
      "currency": "OMR",
      "seller": {
        "name": "Al Haya Trading LLC",
        "vat_number": "OM1234567890",
        "peppol_id": "0248:OM1100012345",
        "address": {
          "street": "Sultan Qaboos Street",
          "city": "Muscat",
          "postal_code": "100",
          "country": "OM"
        }
      },
      "buyer": {
        "name": "Oman National Corp",
        "vat_number": "OM9876543210",
        "peppol_id": "0248:OM1100054321",
        "address": {
          "street": "Al Khuwair Road",
          "city": "Muscat",
          "postal_code": "200",
          "country": "OM"
        }
      },
      "lines": [
        {
          "description": "IT Consulting Services - January 2026",
          "quantity": 160,
          "unit": "HUR",
          "unit_price": 25.000,
          "tax_rate": 5,
          "tax_category": "S"
        }
      ],
      "totals": {
        "net_amount": 4000.000,
        "tax_amount": 200.000,
        "payable_amount": 4200.000
      }
    }
  }'

Python (requests)​

import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://app.goroute.ai/peppol-api"

payload = {
    "invoice": {
        "document_type": "invoice",
        "number": "OM-INV-2026-001",
        "issue_date": "2026-02-08",
        "currency": "OMR",
        "seller": {
            "name": "Al Haya Trading LLC",
            "vat_number": "OM1234567890",
            "peppol_id": "0248:OM1100012345",
            "address": {"country": "OM"}
        },
        "buyer": {
            "name": "Oman National Corp",
            "vat_number": "OM9876543210",
            "peppol_id": "0248:OM1100054321",
            "address": {"country": "OM"}
        },
        "lines": [
            {
                "description": "IT Consulting Services",
                "quantity": 160,
                "unit": "HUR",
                "unit_price": 25.000,
                "tax_rate": 5,
                "tax_category": "S"
            }
        ],
        "totals": {
            "net_amount": 4000.000,
            "tax_amount": 200.000,
            "payable_amount": 4200.000
        }
    }
}

response = requests.post(
    f"{BASE_URL}/api/v1/invoices",
    headers={"X-API-Key": API_KEY},
    json=payload
)

result = response.json()
print(f"Transaction: {result['transaction_id']}")
print(f"Status: {result['status']}")
# On this path GoRoute renders the UBL, so the QR code, hash and
# signature are added for you - when Oman signing is configured.

UBL XML (Direct)​

You can also submit UBL you have produced yourself. This is a JSON call to POST /api/v1/documents: the XML travels as a string in the document field. You do not POST raw XML, and this endpoint has no application/xml request body.

On this path GoRoute does not alter your document. It is transmitted exactly as you submitted it — no QR code, no hash and no signature are added. If your invoice needs those elements, generate them before you send.

import json
import requests

with open("oman-invoice.xml", encoding="utf-8") as f:
    invoice_xml = f.read()

response = requests.post(
    f"{BASE_URL}/api/v1/documents",
    headers={"X-API-Key": API_KEY, "Content-Type": "application/json"},
    json={
        "receiver_scheme": "0248",
        "receiver_id": "OM1100054321",
        "document": invoice_xml,
    },
)
# The document above is transmitted exactly as submitted.
print(response.status_code, response.json()["transaction_id"])

The same call with curl, reading a JSON body you have already assembled:

curl -X POST https://app.goroute.ai/peppol-api/api/v1/documents \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  --data-binary @request.json

receiver_scheme, receiver_id and document are the required fields; sender_scheme and sender_id default to your organisation. A successful call returns 202 Accepted with a transaction_id. The same request is documented in full under Sending an Invoice.

Earlier revisions of this page documented an endpoint that does not exist

This page previously told you to POST raw UBL, with a raw-XML content type, to a send path nested underneath /api/v1/documents, and said GoRoute would add the QR code, hash and signature to it. No such endpoint has ever existed, and code written against it has never worked. Use POST /api/v1/documents as shown above, and note that it does not modify your document.

Tax reporting status (TDD and MLS)​

Oman's CTC protocol produces two artefacts alongside the invoice itself: a Tax Data Document (TDD) addressed to the Oman Tax Authority, and one or more Message Level Status (MLS) responses exchanged between access points. Two endpoints expose them. Both require the transactions:read permission.

Reporting status for one transaction​

GET /api/v1/transactions/{transaction_id}/reporting

Returns the tax-reporting state of a transaction in a single call.

FieldMeaning
transaction_idThe transaction queried.
clearance_statusOne of prepared_awaiting_authority, cleared, failed, reported, reported_via_substitute, awaiting_ota_go_live, or null when no TDD exists yet.
ota_liveWhether this environment is configured to report to a live tax authority.
ota_targetThe participant identifier Tax Data Documents are addressed to, as scheme:id.
ota_target_is_testbedtrue when ota_target is the OTA test participant.
noteA plain-language explanation, or null. See below.
mls_statusThe MLS response code if one has arrived, otherwise sent if an MLS was dispatched, otherwise null.
tdd.transaction_idThe transaction holding the TDD, or null.
tdd.sentEnqueued for transmission — not "arrived". Read together with tdd.held.
tdd.heldtrue when the TDD was built, validated and stored but deliberately not transmitted. A held TDD has reached nobody.
tdd.deliveredtrue cleared, false failed, null not yet reconciled.
tdd.scopeScope of a substitute report, where one was used.
tdd.document_urlRelative URL of the stored TDD, or null when there is no TDD.
mls.transaction_idThe MLS we sent, kept for backward compatibility.
mls.response_codeResponse code carried by the MLS.
mls.document_urlRelative URL of the MLS, or null.
mls.legs[]One entry per leg that exists — leg is sent or received, each with its own transaction_id and document_url. A received leg also carries response_code and received_at.
substitute.usedtrue when a substitute participant was reported to.
substitute.participantThe substitute participant identifier.
substitute.reasonWhy a substitute was used.
sla_breachedWhether the reporting SLA for this transaction was breached.
tdd.sent does not mean the tax authority received it

sent means enqueued for transmission. A held TDD is enqueued and then deliberately not transmitted, so tdd.sent and tdd.held are both true at once. Always read the two together: if tdd.held is true, nothing has reached the tax authority. clearance_status already applies that precedence for you — prefer it over inferring the state from tdd.sent.

Why you may see an explanatory note​

When clearance_status is anything other than reported, and this environment is pointed at the OTA test participant or is not configured as live, the response carries a note explaining that in prose. This is the expected state today rather than a fault: the invoice itself is delivered to the buyer over Peppol normally, the TDD is still generated and stored against the transaction, and the original issue time is preserved so the reporting obligation can be evidenced later. When the note is absent it is null.

GoRoute publishes no date for OTA production reporting. Use ota_live and ota_target_is_testbed on this endpoint to see what your own environment is pointed at, rather than assuming.

Fetching an MLS document​

GET /api/v1/transactions/{transaction_id}/mls?leg=sent

Returns the MLS as unaltered UBL ApplicationResponse XML, with content type application/xml. Nothing is reformatted or re-serialised.

ParameterValuesBehaviour
legsentThe ApplicationResponse GoRoute issued as C3 to the sending access point (C2).
legreceivedThe ApplicationResponse GoRoute received — from C2 for an invoice you sent, or from C5 for a TDD.
legomittedThe sent leg if one exists, otherwise the received leg.

A transaction can have both legs at once, which is why they are addressable separately. Call the reporting endpoint first and read mls.legs[] to see which legs exist before fetching one.

Errors

Statuserror_codeWhen
404TRANSACTION_NOT_FOUNDNo such transaction in your organisation.
404MLS_NOT_AVAILABLEThe transaction exists but no MLS of the requested leg has been produced.
404DOCUMENT_NOT_STOREDThe leg exists but its XML is not retrievable from storage.
import requests

status = requests.get(
    f"{BASE_URL}/api/v1/transactions/{transaction_id}/reporting",
    headers={"X-API-Key": API_KEY},
).json()

print(status["clearance_status"], status["ota_target"])
if status["note"]:
    print(status["note"])

# Fetch a leg only if the reporting call says it exists.
for leg in status["mls"]["legs"]:
    xml = requests.get(
        f"{BASE_URL}/api/v1/transactions/{transaction_id}/mls",
        params={"leg": leg["leg"]},
        headers={"X-API-Key": API_KEY},
    ).text

Example Oman Invoice (Full UBL)​

<?xml version="1.0" encoding="UTF-8"?>
<Invoice xmlns="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
         xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
         xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
    
    <!-- Oman PINT OM -->
    <cbc:CustomizationID>urn:peppol:pint:billing-1@om-1</cbc:CustomizationID>
    <cbc:ProfileID>urn:peppol:bis:billing</cbc:ProfileID>
    
    <cbc:ID>OM-INV-2026-001</cbc:ID>
    <cbc:IssueDate>2026-02-08</cbc:IssueDate>
    <cbc:IssueTime>12:00:00Z</cbc:IssueTime>
    <cbc:DueDate>2026-03-10</cbc:DueDate>
    <cbc:InvoiceTypeCode>380</cbc:InvoiceTypeCode>
    <cbc:DocumentCurrencyCode>OMR</cbc:DocumentCurrencyCode>
    <cbc:BuyerReference>PO-2026-456</cbc:BuyerReference>
    
    <!-- Seller (Oman company) -->
    <cac:AccountingSupplierParty>
        <cac:Party>
            <cbc:EndpointID schemeID="0248">OM1100012345</cbc:EndpointID>
            <cac:PartyName>
                <cbc:Name>Al Haya Trading LLC</cbc:Name>
            </cac:PartyName>
            <cac:PostalAddress>
                <cbc:StreetName>Sultan Qaboos Street</cbc:StreetName>
                <cbc:CityName>Muscat</cbc:CityName>
                <cbc:PostalZone>100</cbc:PostalZone>
                <cac:Country>
                    <cbc:IdentificationCode>OM</cbc:IdentificationCode>
                </cac:Country>
            </cac:PostalAddress>
            <cac:PartyTaxScheme>
                <cbc:CompanyID>OM1234567890</cbc:CompanyID>
                <cac:TaxScheme>
                    <cbc:ID>VAT</cbc:ID>
                </cac:TaxScheme>
            </cac:PartyTaxScheme>
            <cac:PartyLegalEntity>
                <cbc:RegistrationName>Al Haya Trading LLC</cbc:RegistrationName>
                <cbc:CompanyID>1234567890</cbc:CompanyID>
            </cac:PartyLegalEntity>
        </cac:Party>
    </cac:AccountingSupplierParty>
    
    <!-- Buyer (Oman company) -->
    <cac:AccountingCustomerParty>
        <cac:Party>
            <cbc:EndpointID schemeID="0248">OM1100054321</cbc:EndpointID>
            <cac:PartyName>
                <cbc:Name>Oman National Corp</cbc:Name>
            </cac:PartyName>
            <cac:PostalAddress>
                <cbc:StreetName>Al Khuwair Road</cbc:StreetName>
                <cbc:CityName>Muscat</cbc:CityName>
                <cbc:PostalZone>200</cbc:PostalZone>
                <cac:Country>
                    <cbc:IdentificationCode>OM</cbc:IdentificationCode>
                </cac:Country>
            </cac:PostalAddress>
            <cac:PartyTaxScheme>
                <cbc:CompanyID>OM9876543210</cbc:CompanyID>
                <cac:TaxScheme>
                    <cbc:ID>VAT</cbc:ID>
                </cac:TaxScheme>
            </cac:PartyTaxScheme>
            <cac:PartyLegalEntity>
                <cbc:RegistrationName>Oman National Corp</cbc:RegistrationName>
            </cac:PartyLegalEntity>
        </cac:Party>
    </cac:AccountingCustomerParty>
    
    <cac:PaymentMeans>
        <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
    </cac:PaymentMeans>
    
    <cac:TaxTotal>
        <cbc:TaxAmount currencyID="OMR">200.000</cbc:TaxAmount>
        <cac:TaxSubtotal>
            <cbc:TaxableAmount currencyID="OMR">4000.000</cbc:TaxableAmount>
            <cbc:TaxAmount currencyID="OMR">200.000</cbc:TaxAmount>
            <cac:TaxCategory>
                <cbc:ID>S</cbc:ID>
                <cbc:Percent>5</cbc:Percent>
                <cac:TaxScheme>
                    <cbc:ID>VAT</cbc:ID>
                </cac:TaxScheme>
            </cac:TaxCategory>
        </cac:TaxSubtotal>
    </cac:TaxTotal>
    
    <cac:LegalMonetaryTotal>
        <cbc:LineExtensionAmount currencyID="OMR">4000.000</cbc:LineExtensionAmount>
        <cbc:TaxExclusiveAmount currencyID="OMR">4000.000</cbc:TaxExclusiveAmount>
        <cbc:TaxInclusiveAmount currencyID="OMR">4200.000</cbc:TaxInclusiveAmount>
        <cbc:PayableAmount currencyID="OMR">4200.000</cbc:PayableAmount>
    </cac:LegalMonetaryTotal>
    
    <cac:InvoiceLine>
        <cbc:ID>1</cbc:ID>
        <cbc:InvoicedQuantity unitCode="HUR">160</cbc:InvoicedQuantity>
        <cbc:LineExtensionAmount currencyID="OMR">4000.000</cbc:LineExtensionAmount>
        <cac:Item>
            <cbc:Name>IT Consulting Services - January 2026</cbc:Name>
            <cac:ClassifiedTaxCategory>
                <cbc:ID>S</cbc:ID>
                <cbc:Percent>5</cbc:Percent>
                <cac:TaxScheme>
                    <cbc:ID>VAT</cbc:ID>
                </cac:TaxScheme>
            </cac:ClassifiedTaxCategory>
        </cac:Item>
        <cac:Price>
            <cbc:PriceAmount currencyID="OMR">25.000</cbc:PriceAmount>
        </cac:Price>
    </cac:InvoiceLine>
</Invoice>

What GoRoute adds on the rendered-document paths​

Applies only where GoRoute renders the document

This applies to the paths where GoRoute composes the UBL itself — POST /api/v1/invoices, drafts, the ERP connectors and the pollers — and only when Oman signing is configured for your environment. It does not apply to UBL you submit to POST /api/v1/documents, which is transmitted exactly as submitted.

On the rendered-document paths the Oman signing pipeline adds the following before Peppol transmission:

  1. QR Code — AdditionalDocumentReference[ID='QR'] with TLV-encoded data
  2. Invoice Hash — AdditionalDocumentReference[ID='HASH'] with SHA-256 digest
  3. Digital Signature — ext:UBLExtensions with XAdES-BES enveloped signature
  4. cac:Signature — Signature reference element

If a document already carries its own AdditionalDocumentReference[ID='QR'], the pipeline leaves it in place rather than adding a second one.

If you are submitting final UBL, generate whatever elements your invoice needs yourself.

Validation​

GoRoute applies multi-layer validation to Oman invoices:

LayerCheckRule
1UBL 2.1 XSDStructural XML validity
2Business rulesTotals, calculations, required fields
3eDEC Code ListsParticipant schemes, currencies, process IDs
3BPINT OM SchematronOfficial OpenPeppol jurisdiction rules (IBR-OM)
3CTDD SchematronTax Data Document validation (CTC reporting)
PINT vs Baseline

PINT OM invoices (detected by urn:peppol:pint:billing-N@om-N in CustomizationID) skip the baseline CEN-EN16931 + Peppol BIS Schematrons. They run only the official PINT OM Schematrons, which already incorporate all required European and Peppol rules along with Oman-specific jurisdiction rules.

TDD (Tax Data Document)​

Oman's CTC (Continuous Transaction Controls) protocol requires a Tax Data Document to be submitted to the Oman Tax Authority within 15 minutes of invoice issuance. GoRoute generates the TDD automatically:

  • Root element: pxs:TaxData (namespace urn:peppol:schema:om-taxdata:1.0)
  • Receiving party: Oman Tax Authority (0242:000773)
  • Validated against TDD-OM-peppol-om-tdd.xslt before submission
  • Supports document types: Send, Receive, Withdraw, Forward

Comparison with Saudi Arabia (ZATCA)​

Oman's Fawtara system is inspired by Saudi Arabia's ZATCA but with key differences:

FeatureOman (OTA)Saudi Arabia (ZATCA)
NetworkPeppolZATCA platform
Base StandardPeppol BIS 3.0UBL 2.1 (no Peppol)
QR FormatTLV (Tags 1-6)TLV (Tags 1-9)
SignatureXAdES-BESXMLDSIG
Currency Decimals3 (OMR)2 (SAR)
Tax Rate5%15%
ClearanceVia Peppol APVia ZATCA portal
CertificatePeppol AP certZATCA-issued cert

Troubleshooting​

Common Issues​

"Amount must have 3 decimal places"

  • OMR uses 3 decimal places. Use 1050.000 not 1050.00.

"Scheme not recognized"

  • Ensure you're using the latest eDEC code lists. GoRoute updates these automatically.

"QR code shows gibberish when scanned"

  • Fawtara QR codes contain TLV binary data, not plain text. Use a Fawtara-compatible reader or the GoRoute dashboard to verify.

"CustomizationID validation failed"

  • Use the exact Oman CIUS CustomizationID shown above. The #conformant# suffix is required.

Resources​

Further reading​

Ready to build? The free developer sandbox gives you test credentials and a registered participant, provisioned within 24 hours on business days. Recorded ERP integration walkthroughs are on the tutorials page.

Last updated on