Executive Summary

The Oman Tax Authority (OTA) is actively implementing Fawtara, Oman's national mandatory e-invoicing system, based on the Pan-European Public Procurement Online (PEPPOL) framework. The Fawtara portal is live for Accredited Service Provider (ASP) registration. Phase one mandatory compliance begins in August 2026, for 100 selected large taxpayers. Phase two notifications are already being issued ahead of the February 2027 commencement. Penalties will apply for non-compliance, with a grace period before enforcement. This alert is drawn exclusively from the OTA's official published sources and sets out the details released so far and how companies should prepare for this new obligation.

If you need a comprehensive explanation of what electronic invoicing is in the PEPPOL context, you can refer to our previous articles here:

• Digital Identity and Invoice Fraud Risks in PEPPOL-Based e-Invoicing – Belgium’s case and what it means for UAE businesses
• What You Need to Know About the UAE PEPPOL International Invoice (PINT) for e-Invoicing | Alvarez & Marsal | Management Consulting | Professional Services
• The introduction of e-Invoicing in the United Arab Emirates – The Countdown Begins!

1.  What Is Fawtara?

Fawtara is Oman's national electronic invoicing system, introduced by the OTA to modernize tax compliance. Under Fawtara, all tax invoices must be generated in a structured digital format and transmitted in real time across a network connecting the supplier, buyer, and OTA, each through their respective accredited service providers. Once fully implemented, only Fawtara-compliant e-invoices will carry legal validity; paper-based invoicing will no longer be recognized.

Objectives:

• Reduce invoice fraud and strengthen VAT system integrity.
• Improve transparency across commercial transactions.
• Advance Oman’s digital economy agenda.
• Automate invoice processing and eliminate manual errors.
• Align with internationally recognized e-invoicing standards.

Direct Benefits for Businesses:

• Reduced administrative overhead and audit-ready records.
• Improved data accuracy supporting inventory and financial management.
• Fewer errors through ERP and accounting system integration.
• Secure digital archiving and real-time reporting.

2. Implementation Phases and Rollout Timeline

The OTA has confirmed a four-phase rollout. Taxpayers are selected for Phase one based on criteria such as revenue size, annual invoice volume, and technical readiness. Small and Medium Enterprises (SMEs) will be included in Phase three. Optional early adoption is permitted for companies not targeted in Phase one, with support provided by the OTA.

Note: Penalties will apply for non-compliance, according to regulations, with a grace period before enforcement. The OTA has not yet published the specific penalty schedule.

3. How The System Works — The PEPPOL Five-Corner Model

Fawtara uses the PEPPOL Five-Corner Model — a decentralized architecture routing invoices through accredited intermediaries, not a central government portal. The OTA sits at Corner six, receives transaction data in near real time from Corner five, and ensures interoperability across different service providers within the Fawtara network.

Corner One — Supplier (Taxpayer): Generates e-Invoices using a service provider by sending system data in an agreed format. e-Invoices must be issued directly from the service provider, they cannot be issued manually by the taxpayer and then entered electronically.

Corner Two — Supplier's Service Provider: Validates e-Invoice format and PEPPOL business rules. Reports the Tax Data Document (TDD) to Corner five. Forwards the validated e-Invoice to the buyer's service provider. Responsibility for e-Invoice compliance ultimately remains with the taxpayer; the OTA will monitor Service Providers’ performance.

Corner Three — Buyer's Service Provider: Receives the validated e-Invoice from Corner two. Submits the TDD to Corner five. Delivers e-Invoices to the buyer (Corner four).

Corner Four — Buyer (Taxpayer): Receives the compliant e-Invoice through their ASP. Acknowledgments are sent back to confirm delivery. For B2B, this is the basis for input VAT recovery claims.

Corner Five — OTA Service Provider: Receives near real-time invoice data from Corner two and Corner three. Validates, records, and audits transaction data. Issues acknowledgements. Does not sit in the direct invoice exchange path — the model is decentralized.

Corner Six – Oman Tax Authority: Receives data from Corner five for further enrichment and analysis.

B2C Invoice Mechanism

For B2C transactions where the buyer has no service provider, OTA prescribes a modified mechanism:

• The supplier is still required to route the invoice through its own service provider (Corner two).
• The supplier’s service provider is required to report only the relevant tax data (TDD) to Corner five — the full invoice exchange through the Fawtara network does not apply in this scenario.
• The human-readable invoice — whether physical, PDF, or another format, is delivered directly to the consumer through conventional channels, outside the Fawtara network.

That consumer-facing document must nonetheless conform to OTA’s prescribed specifications and carry a QR code enabling independent verification of the underlying e-Invoice.

Note: QR code details (who generates it, what information it must contain, and whether it is mandatory only for simplified/B2C invoices) will be shared by OTA in due course. A QR code is currently expected to be mandatory only for simplified (B2C) invoices. Further guidance is expected.

Submission Timeframes

• B2B: Real-time submission is required.
• B2C: The timeframe is under OTA review, no deadline has been stipulated yet.

Invoice Corrections

• Issued e-Invoices cannot be cancelled. Adjustments require a credit note.
• If an invoice is sent to the wrong buyer or wrong VAT number: issue a credit note to the wrong buyer and issue a new invoice to the correct buyer.
• Electronic credit and debit notes are the only permitted mechanisms for invoice adjustments.

VAT Group Treatment

• Every legal entity that falls under a consolidated VAT group (and therefore shares a single VAT registration number) is subject to Fawtara e-Invoicing requirements.
• The OTA requires that all members of a VAT group route their invoices through a single ASP — group-level ASP selection is therefore an enterprise decision, not a business-unit one.
• Where the same VAT number appears on both sides of a transaction (as in intra-group supplies) the system is designed to accommodate this without triggering rejection.

Additional VAT group guidance will be issued by the OTA in due course.

4. Technical and Format Requirements

a. Invoice Format Standards

OTA-confirmed technical requirements:

• Approved Formats: XML and PDF/A-3 — invoices must be issued in one of these structured electronic formats.
• System Connectivity: API connectivity is required between the taxpayer's ERP/billing system and the ASP.
• Digital Certificate: A valid digital certificate is mandatory to ensure reliability and verification of all e-Invoices.
• Invoice Identifiers: Each invoice carries a UUID and an invoice hash as unique identifiers for audit trail purposes. Both serve as unique identifiers but serve slightly different purposes in audit trails. Additional OTA guidance is expected.
• Bilingual Support: The system supports both Arabic and English.
• Manual Entry: Invoices must be issued directly from the approved electronic system. Manual creation followed by electronic entry is not permitted.
• ERP Compatibility: Existing ERP systems may not need to be replaced i.e., integration is possible if they are compatible with OTA specifications. Integration specifications will be provided by the OTA.

b. Data Dictionary and Mandatory Fields

The OTA has circulated a draft Data Dictionary to Phase one taxpayers and prospective ASPs. It defines the full invoice field schema — mandatory, conditional, and optional fields, along with validation rules, and code lists and is the primary reference for ERP configuration.

Note: The Data Dictionary is in draft. A final version will follow the OTA’s stakeholder consultation.

5. Transaction Scope

e-Invoicing applies across all transaction types simultaneously. Confirmed scope:

• B2B (Business-to-Business): In scope; real-time submission is required.
• B2G (Business-to-Government): In scope.
• B2C (Business-to-Consumer): In scope with a lighter exchange model — seller submits to the ASP, ASP reports tax data to the OTA only; the human-readable invoice is exchanged outside Fawtara.
• Out-Of-Scope Supplies: e-Invoicing is not mandatory for out-of-scope supplies. However, the OTA recommends awaiting further legislative clarification.
• Imports/Foreign Suppliers: Businesses must report the Bayan number for imports. Self-billed e-Invoices must be issued for imports of goods and services.
• Reverse Charge Mechanism (RCM): Self-billed e-Invoices must be issued. A specific transaction type exists for RCM in the Data Dictionary.
• Non-VAT-Registered Sellers: Not required to be part of the Fawtara network. Such sellers cannot charge VAT.

6. Input VAT Recovery — Critical Compliance Implications

The OTA has confirmed the following VAT recovery rules, which have direct commercial implications for all businesses in Oman's supply chain:

• During the transitional rollout period: A VAT-registered supplier not yet captured by any active or completed phase may continue to issue invoices under existing Oman VAT law requirements. Buyers receiving such invoices retain the right to claim input VAT in accordance with current rules.
• Once all rollout phases have concluded: Only invoices transmitted through the Fawtara network will qualify as a valid basis for input VAT recovery. Any invoice issued outside the network at that point (regardless of its format or content) will not support a VAT claim by the buyer.

Note: Buyers whose suppliers fail to integrate with Fawtara will lose input VAT recovery on those purchases once all rollouts conclude. Audit your supplier base for Fawtara readiness now.

7. Archiving Obligations

OTA-mandated archiving requirements:

• Total Archiving Period: 10 years.
• Structure: Five years retained in the system + five years maintained in an electronic archive.
• Retrieval: e-Invoices must remain accessible at any point during the retention period.
• Format: Archiving must be electronic, paper or PDF-only storage will not satisfy this requirement.

8. Fawtara Portal — Current Status

The OTA has launched the Fawtara portal at fawtara.taxoman.gov.om. The portal is live and accepting Service Provider accreditation applications. The following releases have been confirmed by the OTA:

• Q1 2026 — Release 1 (Now Live): Service Provider (SP) registration portal is open. Prospective ASPs may submit applications for OTA review to commence the accreditation process.
• Q2 2026 — Release 2 (Upcoming): Testing environment is expected to be available to service providers that have completed the application process. SPs will conduct technical compliance and interoperability testing.
• Q3 2026 — Release 3: e-Invoice exchange commences. Phase one taxpayers can exchange, receive, and report e-Invoices to OTA via their service providers.

Training and Support: The OTA will run workshops and system-familiarization sessions ahead of go-live. A technical support center and helpline will be established, with guidance manuals published through the OTA’s official channels.

9. A&M Commentary — Functional Advisory Perspective

The following observations represent A&M's independent advisory perspective based on our experience supporting businesses across e-Invoicing mandates in the GCC region. They are not drawn from the OTA sources but reflect our practitioner assessment of the implementation challenges businesses face.

a. The Data Dictionary Is Your Starting Point — Not Your Finish Line

The OTA has published a draft Data Dictionary defining mandatory, optional, and conditional fields for compliant e-Invoices. The OTA has not yet published the final version. This is a critical distinction. Businesses that wait for the final Data Dictionary before commencing ERP gap analysis will not have enough time to implement changes before their phase goes live. The draft is sufficiently detailed to commence a full mapping exercise against your current ERP invoice output. Begin that work now. The final version should be used to close remaining gaps, not to start the process.

b. ASP Selection Is a Technical and Commercial Decision — Not a Procurement Exercise

The OTA requires that all entities within a VAT group use a single, same service provider. This group-level constraint means ASP selection is not a business-unit decision, it is an enterprise-level one. An ASP must meet the OTA's detailed financial, legal, technical, and ISO/IEC 27001 security requirements. Beyond accreditation, businesses must evaluate:

• Technical compatibility with your specific ERP (SAP, Oracle, Microsoft Dynamics, or otherwise).
• API integration capability and uptime SLAs.
• Experience managing high invoice volumes and invoice rejection handling.
• Commercial terms including licensing and long-term support.

A&M provides vendor-neutral ASP evaluation — shortlisting, RFP development, and structured assessment against your operational and technical requirements.

c. ERP Readiness Is the Longest Lead-Time Item

The OTA has confirmed that invoices must be issued directly from an approved electronic system, manual creation and electronic entry is prohibited. This means your ERP must be capable of generating a structured output, connecting to your ASP, and handling the full range of document types including credit notes, debit notes, and RCM self-billed invoices. For businesses on legacy or heavily customized ERP platforms, technical remediation can take 6–12 months. The OTA's Q2 2026 test environment is your ‘rehearsal’ and it cannot be used effectively without an ERP-ready solution. For Phase one businesses, that window is effectively closed. For Phase two, the clock is running.

d. The Input VAT Recovery Risk Cascades Down Your Supply Chain

The OTA has been explicit: once all rollout phases are concluded, only invoices issued through the Fawtara network will support input VAT recovery by buyers. This means your suppliers' non-compliance directly affects your VAT position. Procurement teams and CFOs need to understand this now. A supplier who is VAT registered but fails to integrate with Fawtara in time effectively erodes your input tax recovery. We recommend a supplier-base readiness audit to identify exposure and incorporate Fawtara compliance into vendor management and contracting processes.

e. B2C and RCM Require Separate Process Design

The OTA has confirmed distinct mechanics for B2C and RCM transactions. For B2C, the invoice is submitted to the ASP but only tax data flows to OTA, the human-readable invoice goes directly to the consumer. This requires a separate process track from B2B within your invoicing system.

Businesses with mixed transaction portfolios, particularly those in financial services, real estate, or import-heavy industries, need to map each transaction type against the Fawtara model as a distinct workstream, not a single unified implementation.

f. Compliance Liability Rests with the Taxpayer — Not the ASP

The OTA has stated clearly that ultimate responsibility for invoice compliance remains with the taxpayer. The ASP validates format and rules and forwards compliant invoices, but an invoice that contains incorrect VAT data, wrong buyer details, or missing mandatory fields is the taxpayer's liability, not the ASP's.

This means robust internal controls around invoice data quality i.e., master data governance, VAT number validation, and supply classification are not optional extras. They are the foundation of Fawtara compliance. A&M's post-implementation support program covers invoice rejection root cause analysis, data quality remediation, and OTA query management.

10. How We Can Help?

A&M Tax, Middle East delivers end-to-end Fawtara implementation advisory. We are not an ASP, we are a vendor-neutral partner across the full compliance lifecycle.