Mandatory Data Fields For Fawtara E-Invoicing in Oman

Oman's e-invoicing mandate is no longer a future plan for the enterprises. Phase 1 goes live in August 2026, and the Oman Tax Authority (OTA) has published its data dictionary. The Fawtara system runs on 53 mandatory fields for a standard tax invoice, nearly three times what Oman VAT rules require today. If your ERP is not mapped to these, you will not clear a single invoice.

Key Takeaways

• A standard Fawtara e-invoice requires 53 mandatory fields, up from 18-20 fields under the current Oman VAT law.
• Oman uses the PINT-OM specification built on the global PEPPOL standard with 36 Oman-specific extensions (BTOM fields) that need custom ERP mapping.
• The OTA has defined 8 document types, including tax invoices, simplified invoices, credit notes, debit notes, and prepayment invoices, each with its own field requirements.
• Missing or incorrect mandatory fields result in invoice rejection at the ASP validation stage, not a warning, not a flag for correction later.
• Penalties for non-compliance would be OMR 1,000–10,000 for invoice & record failures, and OMR 5,000–20,000 for tax evasion & fraudulent reporting.

Fawtara E-Invoicing Mandate and Timeline

The OTA became a PEPPOL Authority in January 2026 and launched the Fawtara portal in March 2026. Phase 1 of Oman e-invoicing starts in August 2026, covering roughly 150 large VAT-registered taxpayers. Phase 2 follows in February 2027 for all large enterprises.

By August 2027, every VAT-registered business in Oman, including SMEs comes into the e-invoicing scope. Government entities are expected to come into scope under Phase 4. The PINT-OM data dictionary is in draft, but OTA has confirmed no major changes are expected before go-live.

What Are the Mandatory Data Fields of an E-Invoice in Oman Under Fawtara? (List of 53 Fields)

The data fields for Oman e-Invoicing are classified into three categories. These must appear on every standard tax e-invoice, no exceptions. There are 53 of them.

1. Invoice Header

• Invoice number (unique identifier assigned by the seller)
• Invoice issue date
• Invoice type code (tax invoice, simplified invoice, etc.)
• Invoice currency code
• Document-level UUID: This is a BT-OM-01 field, Oman-specific, assigned to every document for traceability
• Digital signature (BT-OM-28): Required for all invoices under Fawtara
• QR code (BT-OM-14): Mandatory on simplified invoices and B2C transactions

2. Seller Details

• Seller's legal name
• Seller's VAT registration number (Tax Identification Number)
• Seller's PEPPOL ID (electronic address for PEPPOL network delivery)
• Seller's postal address, including country code

3. Buyer Details

• Buyer's legal name
• Buyer's VAT registration number (mandatory for B2B invoices)
• Buyer's PEPPOL ID or electronic address
• Buyer's postal address

4. Tax Breakdown

• Tax category code (standard rate: S, zero-rated: Z, exempt: E, out of scope: O)
• VAT rate applicable
• Taxable amount per tax category
• VAT amount per tax category
• Total VAT amount on the invoice

5. Invoice Totals

• Net amount (sum of line amounts before VAT)
• Total invoice amount including VAT
• Amount due for payment

6. Line Item Level

• Line item identifier
• Item description
• Quantity
• Unit of measure
• Item net price (excluding VAT)
• Line net amount
• Line VAT amount (BT-OM-16, Oman-specific field)
• Line total including VAT (BT-OM-17, Oman-specific field)
• Document reference per line (BT-OM-84, Oman-specific field)
• HS code: 12-digit Harmonised System code, mandatory for all goods line items

The HS code gap is a common and expensive surprise for the enterprises in Oman. If your item master does not carry 12-digit HS codes for every goods line item, that is a data remediation project, not a configuration task. For companies with thousands of SKUs, this requires dedicated effort and business owner sign-off before go-live. Audit your item master now. 

Conditional Fields

These are required when a specific condition applies. The OTA data dictionary identifies up to 66 such fields. Some common examples:

1. Buyer VAT number: Mandatory for B2B, not required for B2C simplified invoices
2. Purchase order reference: When the transaction is linked to a purchase order
3. Contract reference: When the invoice references a contract
4. Delivery date and address: When goods are delivered to a location different from the buyer's registered address
5. Payment due date and payment terms: When agreed payment terms differ from the invoice date
6. Prepayment reference: Required on invoices that relate to an advance payment already made
7. Allowances and charges: Required at both header and line level when applicable, with reason codes
8. Foreign currency amounts with OMR equivalent: When the invoice currency is not Omani Rial; tax amounts must also be expressed in OMR
9. Simplified invoice QR code: Mandatory for B2C, conditional on invoice type
10. Reverse charge indicator: For transactions subject to the reverse charge mechanism

The conditional fields are where integration teams spend the most time. The logic is not always obvious from the data dictionary alone, and the business rules linked to each condition need to be mapped carefully.

Optional Fields

These are not required by the OTA but can be included for commercial or operational purposes:

• Additional invoice references (internal references, despatch advice numbers)
• Seller's bank account details
• Buyer's contact information beyond the mandatory address fields
• Item classification codes beyond HS (proprietary product codes)
• Seller's tax representative details (where applicable)
• Free-text notes at the invoice or line level

Optional fields do not cause rejections if absent. However, including them with incorrect or malformed values can still trigger schema validation errors at the ASP. The system validates the entire document, not just mandatory fields. Hence, use optional fields deliberately, not by default.

Some businesses use optional fields to carry internal ERP references that help with reconciliation. This is a valid approach, provided all mandatory fields are correctly populated, optional fields do not compensate for mandatory field failures.

Mandatory Fields for Credit Notes, Debit Notes, and Self-Billed Invoices

This section has significant operational implications that are frequently underestimated. Under Fawtara, invoices cannot be cancelled. The only way to correct a previously issued invoice is through a credit note. This is the same model that KSA uses under ZATCA, and it requires a fundamental rethink of how error correction workflows are set up.

1. Credit Notes (Document Type Code 381)

A credit note under PINT-OM must include all the standard mandatory fields plus the following:

• Reference to the original invoice number being corrected (BT-OM-31)
• UUID of the original invoice (where applicable)
• Reason code for the credit note (BT-OM-32)
• Corrected amounts (line-level and total)

The reason code is not optional in practice. Without it, the ASP validation may reject the document before it even reaches OTA. This has occurred in KSA implementations: teams issued credit notes without reason codes and faced bulk rejections that took days to resolve, during which corrected invoices could not flow through the network.

2. Debit Notes (Document Type Code 383)

Debit notes follow the same logic as credit notes but are used to increase a previously issued invoice value. Required fields include:

• Reference to the original invoice (same BT-OM-31 reference)
• Reason for the debit adjustment
• Updated amount fields at the line and header level

3. Self-Billed Invoices

Self-billing is where the buyer issues the invoice on behalf of the seller. This is mandatory for certain import scenarios in Oman. The PINT-OM specification covers self-billing as a separate process. Key additional requirements include the following:

• Seller's VAT number on the invoice (verified against OTA records)
• Explicit indicator that the document is a self-billed invoice
• All standard mandatory fields apply, with the buyer acting as the issuer

For companies with complex supply chains, particularly in oil and gas or manufacturing, the self-billing workflows need specific attention. The data flows are different from a standard AR invoice, and the ERP mapping needs to reflect that.

4. Simplified Invoices (B2C)

Simplified invoices don’t carry the buyer VAT details, this is the main difference compared to standard B2B invoice. However, QR codes and digital signatures remain mandatory. The seller still submits the invoice to the ASP, but the ASP only sends the tax data to Corner 5 (OTA), the OTA's regulatory oversight node. The full invoice document does not flow through the PEPPOL network to the buyer. The buyer receives a copy separately, in paper or PDF.

Conclusion

The Fawtara mandatory fields are defined and largely stable. The data dictionary is in draft, but OTA has not indicated significant changes. What this means practically: if you are a large taxpayer in the Phase 1 scope, the time to begin ERP gap assessment is now. The 36 Oman-specific BTOM fields, covering UUIDs, cryptographic hashes, line-level VAT amounts, and digital signatures are not standard ERP outputs. 

They need to be built or enabled through an OTA accredited service provider such as ClearTax (a pre-approved ASP listed on the OTA Fawtara portal).

The HS code gap is particularly common and particularly expensive to fix late. So is the credit note reason code logic. These are gaps that surface during UAT, and at that stage, remediation delays go-live, creates penalty exposure, and puts Phase 1 compliance at risk. The cost of identifying them now is a fraction of the cost of fixing them under live conditions.