Oman's Fawtara e-invoicing mandate goes live in Phase 1 on August 2026. The top 100–153 largest VAT-registered taxpayers in Oman have already been notified by the Oman Tax Authority (OTA). Every one of them needs to connect their ERP, billing system, or accounting platform to the Fawtara network before that date — or face non-compliance on every B2B invoice they generate.

Most of the discussion around Fawtara focuses on Accredited Service Providers (ASPs) — who is certified, what their subscription costs. What is rarely discussed from a developer's perspective is what connecting your existing software to a Fawtara ASP actually requires: the PINT OM data format, the five-corner Peppol model, the Tax Data Document architecture, and the specific integration differences between B2B and B2C transactions.

This guide covers the Fawtara API integration architecture from the software developer's side — what changes in your ERP, what the ASP connection requires, and how Fawtara differs technically from Saudi Arabia's ZATCA Fatoorah for GCC businesses that need to handle both.

---

What Fawtara Is — and What It Is Not

Fawtara (فاتورة — Arabic for "invoice") is Oman's national electronic invoicing programme operated by the Oman Tax Authority (OTA) in partnership with Omantel, Oman's national telecommunications provider. The OTA was officially approved as a Peppol Authority by OpenPeppol on January 7, 2026 — making Oman the third GCC country to mandate e-invoicing after Saudi Arabia (ZATCA, 2021) and the UAE (FTA e-invoicing, 2026).

Fawtara is not a portal where businesses upload invoices. It is a structured electronic invoice exchange network built on the Peppol five-corner model — meaning invoices flow between businesses through accredited intermediaries, with the OTA receiving structured tax data automatically as part of that flow. No business connects directly to the OTA's central platform. All invoice transmission happens through OTA-accredited Fawtara Service Providers (ASPs).

The PINT Oman (PINT OM) specification — Oman's localised adaptation of the Peppol International PINT standard — was published in April 2026 in cooperation with the OTA. It is the definitive technical specification for every Fawtara invoice format, validation rule, and exchange process.

---

The Phase Timeline — Why August 2026 Matters Now

Phase	Date	Scope
Pilot	Feb–May 2026	Sandbox live, ASP accreditation begins
Phase 1	August 2026	Top ~100–153 largest VAT-registered taxpayers
Phase 2	February 2027	All remaining large VAT-registered businesses
Phase 3	August 2027	All VAT-registered SMEs
Phase 4	August 2028	Government entities — all B2G transactions

Phase 1 businesses have been directly notified by the OTA. If your Omani entity received an OTA notification in H1 2026, you are in scope for August. A full ERP-to-ASP integration takes 4–6 weeks from engagement to production-ready go-live. Starting integration now means you have buffer. Starting after Phase 1 launches means you are already in violation.

For Phase 2 and 3 businesses — the February and August 2027 deadlines are less than 12 months away. The same integration work is required, with the same 4–6 week implementation timeline. Building the integration once, before the deadline, is structurally more efficient than building under pressure when every Omani software development partner is simultaneously overloaded with compliance projects.

---

The Fawtara Five-Corner Peppol Model

Fawtara operates on Peppol's five-corner model. Understanding the flow is essential before designing any integration:

Corner 1 — Your ERP or billing system (the Supplier) You generate the commercial invoice in PINT OM format (UBL 2.1 XML) — structured, complete, with all 53 mandatory fields populated. This invoice leaves your system as a machine-readable document, not a PDF.

Corner 2 — Your OTA-accredited Fawtara Service Provider (Supplier's ASP) Your ASP receives the structured invoice, validates it against the PINT OM schema and the OTA's business rules, applies a digital certificate, and routes it through the Peppol network to the buyer. Simultaneously, your ASP generates the Tax Data Document (TDD) — a structured tax reporting document separate from the commercial invoice — and submits it to the OTA.

Corner 3 — The Peppol Network The validated invoice transits the Peppol network — the same global B2B document exchange network used across Europe, Singapore, Australia, and now the GCC. Interoperability between different ASPs on the network is guaranteed by the Peppol standard.

Corner 4 — The Buyer's OTA-accredited ASP + the Buyer The buyer's ASP receives the invoice from the Peppol network and delivers it to the buyer's ERP or accounting system in machine-readable format. The buyer is expected to be connected to the Fawtara network through their own ASP — this is the B2B requirement. For B2C transactions (where the consumer is not on the Peppol network), the seller's ASP handles Corner 5 only, and the seller provides a human-readable invoice (PDF or printed) to the consumer outside the Fawtara network.

Corner 5 — OTA Fawtara Platform The Tax Data Document (TDD) from Corner 2 is delivered to the OTA's central platform in real time (B2B) or within 24 hours (B2C). The OTA receives structured tax data for every transaction without needing to see the commercial invoice itself. This is how the OTA achieves real-time VAT monitoring across the entire Omani economy.

The critical developer insight: Your integration project has two distinct outputs. First: generating a PINT OM compliant invoice XML from your ERP data. Second: connecting to your chosen ASP's API to submit that XML, receive validation results, retrieve delivery confirmations, and handle error callbacks. These are two separate technical problems that must both be solved.

---

Fawtara vs ZATCA Fatoorah — Key Differences for GCC Businesses

Many Omani businesses also operate in Saudi Arabia and are already navigating ZATCA Fatoorah compliance. The two systems share a philosophy — structured e-invoicing with real-time government visibility — but differ significantly in their technical architecture. Building one does not automatically give you the other.

	ZATCA Fatoorah (Saudi Arabia)	Fawtara (Oman)
Model	Clearance + Reporting	Peppol five-corner
Format	UBL 2.1 Saudi schema	UBL 2.1 PINT OM
Regulatory body	ZATCA	Oman Tax Authority (OTA)
Digital signature	Mandatory CSID (device-level)	Digital certificate
QR code	Mandatory — TLV, 7 fields	B2C simplified invoices only
Hash chain	Mandatory SHA-256	Not required
ASP required	No — direct ZATCA connection possible	Yes — mandatory for all transmission
B2B flow	ZATCA clears invoice before buyer receives it	Invoice travels via Peppol to buyer's ASP
B2C flow	Report to ZATCA within 24 hours	TDD to OTA within 24 hours via ASP
Mandatory fields	~40 core fields	53 mandatory fields
Archiving	6 years	10 years (5+5)
Phase 1 deadline	January 2023	August 2026
Sandbox	gw-fatoora.zatca.gov.sa	fawtara.taxoman.gov.om

The most important structural difference for developers: ZATCA allows direct ERP-to-authority API connections (you can build directly against ZATCA's Fatoorah API endpoints). Fawtara requires all transmission through an OTA-accredited ASP — there is no direct ERP-to-OTA API. Your integration connects your ERP to your chosen ASP's API, and the ASP handles the Peppol network transmission and OTA TDD reporting.

---

PINT OM Technical Requirements — What Your Invoice Must Contain

The PINT Oman (PINT OM) specification defines the exact data fields, validation rules, and document types for all Fawtara invoices. Published by the OTA through OpenPeppol in April 2026, it is the authoritative technical reference.

Document types covered by PINT OM:

• Standard invoice (B2B and B2G)
• Credit note
• Debit note
• Self-billed invoice (mandatory for import transactions)
• Simplified invoice (B2C, where buyer is not on Peppol network)
• Tax Data Document (TDD) — the separate OTA reporting document For standard B2B invoices — 53 mandatory fields including:
• Supplier and buyer VAT registration numbers (VATIN)
• Invoice UUID (unique identifier per invoice)
• Invoice date and currency
• Line-level 12-digit HS codes for goods transactions
• VAT breakdown by rate (standard 5%, zero-rated, exempt)
• Digital certificate from OTA-accredited service
• QR code (for B2C/simplified invoices) For simplified B2C invoices — 46 mandatory fields

Invoice format: UBL 2.1 XML per the PINT OM specification. PDF/A-3 is also accepted. JSON has not been officially confirmed as valid format.

Archiving: All e-invoices must be stored for 10 years — 5 years in the active system, 5 years in an electronic archive — and made available for OTA inspection on demand.

Import transactions: Must be reported using a self-billed invoice. This is particularly relevant for businesses with international supply chains importing goods or services into Oman.

---

The Three Things Developers Get Wrong with Fawtara Integration

Prerequisite 1 — Treating ASP Connection as a Simple Webhook

The most common assumption: "We just need to POST our invoice to the ASP's endpoint and we're done." The ASP connection is more complex than a simple POST. A production Fawtara integration requires:

Submission: POST the PINT OM XML invoice to the ASP's API endpoint → receive an acknowledgment with a submission reference ID.

Validation result handling: The ASP validates your invoice against the PINT OM schema and OTA business rules before transmitting it to the Peppol network. Validation can return three outcomes — accepted (proceed), accepted with warnings (proceed, log the warnings for review), or rejected (must correct and resubmit). Rejection means the invoice has NOT been transmitted and is NOT valid for VAT purposes. Your system must handle the rejection callback, surface the specific failing rule to the team responsible for data quality, and manage the correction and resubmission workflow.

Delivery confirmation: Once the invoice has been successfully transmitted through the Peppol network and received by the buyer's ASP (for B2B), the seller's ASP returns a delivery acknowledgment. Your system should update the invoice record to "delivered" status only on this confirmation — not on the initial submission acknowledgment.

TDD confirmation: The Tax Data Document submission to the OTA generates a separate confirmation from the ASP. Monitor this separately from the invoice delivery confirmation.

Prerequisite 2 — Not Separating B2B and B2C Flows at the Architecture Level

Fawtara has fundamentally different obligations for B2B and B2C transactions. A system that handles both transaction types through the same invoice generation flow will produce non-compliant output for one of them.

B2B standard invoices must be transmitted in real time — the invoice must be submitted to the ASP and transmitted through the Peppol network before the commercial relationship is considered documented for VAT purposes.

B2C simplified invoices are issued directly to the consumer outside the Peppol network (as a PDF, printed invoice, or email), and the Tax Data Document is submitted to the OTA through the ASP within 24 hours of issuance. The consumer does not receive a Peppol network delivery — they receive a human-readable invoice.

A retail or e-commerce system serving both corporate (B2B) and consumer (B2C) customers must determine at invoice generation time which transaction type applies, generate the appropriate PINT OM document type (standard vs simplified), and route it through the appropriate flow (Peppol network transmission vs TDD-only OTA reporting). Mixing these flows produces invalid invoices for the wrong transaction type.

Prerequisite 3 — Building for ZATCA Then Adapting for Fawtara

Saudi businesses with Oman operations frequently attempt to adapt their ZATCA Fatoorah integration for Fawtara. The two systems share enough vocabulary (e-invoicing, UBL 2.1, ASP, digital certificates, VAT compliance) that the assumption of reusability is understandable. In practice, the architectural differences make this approach costly.

ZATCA's clearance model routes B2B invoices through ZATCA before they reach the buyer — ZATCA's stamp of clearance is embedded in the invoice XML. Fawtara's five-corner model routes invoices through the Peppol network between buyer and seller ASPs — there is no government clearance step in the invoice flow, only the parallel TDD submission to the OTA.

A ZATCA integration built with clearance polling logic (waiting for ZATCA's clearance response before marking the invoice as valid) cannot be directly adapted to Fawtara, where the clearance equivalent is the ASP's schema validation — a different API, a different response format, and a different business logic outcome. Build the Fawtara integration as a separate project informed by ZATCA experience, not as an adaptation of ZATCA code.

---

The Fawtara Integration Architecture — What Your ERP Must Generate

Step 1 — Data mapping and PINT OM field population Map every mandatory field from your ERP's data model to the PINT OM specification. The 53 mandatory fields for a standard B2B invoice include fields that many ERP systems do not capture by default — 12-digit HS codes for goods, OTA-format VAT registration numbers, and UUID generation per invoice. Before writing a single line of integration code, complete a field-by-field gap analysis between your ERP's current invoice data model and the PINT OM mandatory field set.

Step 2 — UBL 2.1 XML generation in PINT OM format Generate the invoice XML from your mapped ERP data. Validate the XML against the PINT OM schema (available from OpenPeppol) before submission to your ASP. Schema validation failures caught locally before submission save the round-trip to the ASP and the manual resubmission workflow.

Step 3 — ASP selection and API connection Choose an OTA-accredited Fawtara Service Provider whose API, pricing, and SLA meet your requirements. The OTA publishes the list of accredited ASPs at fawtara.taxoman.gov.om. Connect to the ASP's submission API — the specific endpoint, authentication method (API key, OAuth 2.0, mTLS), and request format varies by ASP.

Step 4 — Validation result handling Build the validation callback handler before testing. Rejection handling is not an edge case — it is a routine event during initial production deployment as your team calibrates field mappings against OTA business rules.

Step 5 — Status tracking and archiving Maintain invoice status in your ERP: draft → submitted → validated → transmitted → delivered → TDD confirmed. Each status transition corresponds to a specific ASP API callback or confirmation event. Archive all invoice XML files and ASP confirmation receipts for 10 years — the OTA can request these at any time during that period.

---

Who Needs Fawtara API Integration

Omani businesses in Phase 1 (August 2026) The top 100–153 largest VAT-registered taxpayers in Oman — if your entity received an OTA notification, the deadline is this month. ERP integration takes 4–6 weeks minimum from engagement to production go-live.

Saudi and UAE companies with Oman subsidiaries or branches GCC businesses with an Omani registered entity are in scope for Fawtara regardless of where their parent company is headquartered. A Saudi construction group with an Oman branch office needs both ZATCA Fatoorah compliance (Saudi operations) and Fawtara compliance (Oman operations). These are separate integrations — not one integration serving both markets.

Software developers building ERP and billing platforms for GCC clients Any accounting, ERP, POS, or billing platform serving Omani clients must be Fawtara-compliant before it can be used for VAT-valid invoice generation in Oman. If you are building or maintaining ERP software for Omani businesses, Fawtara compliance is a product requirement, not a client configuration.

---

What Does Fawtara Integration Cost?

Fawtara integration for existing ERP or billing platform Field mapping, PINT OM XML generation, ASP API connection, validation error handling, B2B/B2C flow separation, status tracking, 10-year archival setup: SAR 45,000–90,000 | 6–10 weeks (Pricing in SAR for GCC clients. For Oman-only clients, equivalent OMR pricing available on request.)

Full GCC dual-compliance build (ZATCA + Fawtara) Both systems integrated from the same ERP — ZATCA Fatoorah for Saudi operations, Fawtara PINT OM for Oman operations, shared data model with country-specific compliance routing: SAR 100,000–180,000 | 12–18 weeks

Enterprise multi-entity compliance platform Multiple Omani and Saudi legal entities, multi-ASP architecture, consolidated compliance dashboard, OTA audit export, ZATCA PCSID management alongside Fawtara certificate management: SAR 180,000–350,000 | 16–24 weeks

---

Why LogioLegion for Fawtara Integration

LogioLegion builds e-invoicing compliance integrations for GCC businesses across Saudi Arabia and Oman. Our published ZATCA Fatoorah API technical guide covers the Saudi compliance architecture that Fawtara shares in philosophy and diverges from in execution — including the CSID onboarding process, clearance vs reporting model differences, and offline invoice generation requirements that inform our approach to Fawtara's Peppol five-corner architecture.

The Fawtara vs ZATCA comparison table in this article reflects the specific integration differences we mapped when scoping GCC dual-compliance builds for businesses operating across both markets. Saudi companies with Oman branches are the primary segment for this dual-integration work — one engagement, two compliant systems, one development partner who understands both regulatory environments.

Tech stack for Fawtara integration: Node.js for PINT OM XML generation, ASP API connection, and validation callback handling; Laravel for the invoice status state machine, archival management, and compliance dashboard; React for the ERP-facing invoice status monitoring interface. All Oman-market integrations are tested against the OTA sandbox at fawtara.taxoman.gov.om before production deployment.

See our ZATCA Fatoorah API integration guide for the Saudi Arabia parallel system architecture. Book a free discovery call — we scope your Fawtara integration requirements, map the PINT OM field gaps against your ERP's current data model, and deliver a fixed-price proposal within 5 business days.

---

Frequently Asked Questions

What is Fawtara and who does it apply to? Fawtara is Oman's national e-invoicing programme operated by the Oman Tax Authority (OTA) on the Peppol framework. It mandates structured electronic invoicing for all VAT-registered businesses in Oman. Phase 1 begins August 2026 for the top 100–153 largest VAT-registered taxpayers. Phase 2 extends to all large taxpayers in February 2027, and Phase 3 covers all remaining VAT-registered SMEs in August 2027. No permanent exemptions have been announced.

What is the difference between Fawtara and ZATCA Fatoorah? Both are GCC e-invoicing mandates requiring structured electronic invoices. Fawtara (Oman) uses the Peppol five-corner model — invoices are exchanged between buyers and sellers through accredited service providers on the Peppol network, with a separate Tax Data Document (TDD) submitted to the OTA. ZATCA Fatoorah (Saudi Arabia) uses a clearance and reporting model — B2B invoices are cleared by ZATCA before being issued to the buyer, and B2C invoices are reported to ZATCA within 24 hours. The two systems cannot share the same integration code even though both use UBL 2.1 XML.

Do businesses need to connect directly to the Oman Tax Authority's API for Fawtara? No. All Fawtara invoice transmission must go through an OTA-accredited Fawtara Service Provider (ASP) — there is no direct ERP-to-OTA API connection. Your integration connects your ERP to your chosen ASP's API. The ASP handles Peppol network transmission and Tax Data Document submission to the OTA. This is different from ZATCA Fatoorah, where businesses can connect directly to ZATCA's Fatoorah API endpoints.

What is the PINT OM specification? PINT Oman (PINT OM) is the official technical specification for Fawtara invoices — Oman's localised adaptation of the Peppol International PINT standard. Published in April 2026 through OpenPeppol in cooperation with the OTA, it defines the data structures, validation rules, and exchange processes for all Fawtara document types including standard invoices, credit notes, simplified invoices, and the Tax Data Document. All Fawtara invoices must be generated in UBL 2.1 XML format conforming to the PINT OM specification.

Which company builds Fawtara API integration software in Oman and the GCC? LogioLegion builds Fawtara API integration for GCC businesses — mapping PINT OM field requirements against existing ERP data models, generating compliant UBL 2.1 XML, connecting to OTA-accredited ASPs, and handling B2B Peppol network transmission alongside B2C TDD-only OTA reporting. For Saudi companies with Oman operations, LogioLegion builds both ZATCA Fatoorah (Saudi) and Fawtara (Oman) integrations as a single engagement with a shared compliance architecture. Contact LogioLegion.

My company operates in both Saudi Arabia and Oman — do I need separate integrations for ZATCA and Fawtara? Yes — separate integrations are required. ZATCA Fatoorah (Saudi Arabia) and Fawtara (Oman) are technically different systems that cannot share integration code. However, they can share a data model layer — the ERP data that drives both integrations (supplier/buyer details, line items, VAT rates) is largely the same. LogioLegion builds GCC dual-compliance integrations where the shared data layer feeds two separate compliance output layers — PINT OM XML for Fawtara and Saudi UBL 2.1 for ZATCA Fatoorah — reducing the total build effort compared to two fully independent projects.

I need Fawtara integration for my ERP — who should I contact? LogioLegion builds Fawtara integration for businesses using standard ERP platforms and custom billing systems across the GCC. The engagement starts with a PINT OM field gap analysis against your current invoice data model — a 1–2 week exercise that produces the exact list of data changes your ERP needs before integration work begins. Scoping to fixed-price proposal takes 5 business days. Book a free discovery call.

What is the Tax Data Document (TDD) in Fawtara? The Tax Data Document is a structured reporting document separate from the commercial invoice. It contains the tax-relevant data from each transaction and is submitted to the OTA's Fawtara platform through the seller's ASP simultaneously with (for B2B) or within 24 hours of (for B2C) the commercial invoice issuance. The OTA uses the TDD for real-time VAT monitoring — it never receives the full commercial invoice, only the structured tax data. Your integration must generate both the commercial invoice (for transmission to the buyer via Peppol) and the TDD (for ASP submission to the OTA), as these are two distinct documents under PINT OM.

What format must Fawtara invoices be in? Fawtara invoices must be in UBL 2.1 XML format conforming to the PINT OM specification. PDF/A-3 is also accepted in specific contexts. JSON has not been officially confirmed as a valid Fawtara format. Standard B2B invoices require 53 mandatory fields including VAT registration numbers for both supplier and buyer, invoice UUID, VAT breakdown by rate, and 12-digit HS codes for goods transactions.

How long must Fawtara invoices be archived? All Fawtara e-invoices must be archived for 10 years — 5 years in the active system and 5 years in a separate electronic archive — and made available for OTA inspection on demand. This is longer than Saudi Arabia's ZATCA archiving requirement of 6 years, and must be factored into the data architecture of any Fawtara-compliant system.

Can I use my ZATCA-compliant software for Fawtara without any changes? No. While both ZATCA Fatoorah and Fawtara use UBL 2.1 XML and share the concept of structured e-invoicing through accredited service providers, their underlying architectures are different. ZATCA uses a clearance model for B2B invoices (ZATCA validates the invoice before it reaches the buyer). Fawtara uses the Peppol five-corner model (invoices travel between buyer and seller through their respective ASPs, with the OTA receiving a separate TDD). The invoice data structures, validation rules, archiving requirements, and integration patterns are all different. A ZATCA integration cannot be reused for Fawtara without significant rework.

---

LogioLegion builds e-invoicing compliance integrations for GCC businesses across Saudi Arabia and Oman. For Saudi Arabia ZATCA Fatoorah architecture, see our ZATCA Fatoorah API integration guide. For broader Saudi compliance context, see our custom software development Saudi Arabia guide. Book a free discovery call to scope your Fawtara or dual-compliance integration.

---