Mandatory Data Fields for Fawtara E-Invoicing in Oman

Oman's e-invoicing mandate has moved past the planning stage for enterprises. Phase 1 goes live in August 2026, and the Oman Tax Authority (OTA) has already published its data dictionary. The Fawtara system requires 53 mandatory fields on a standard tax invoice, nearly three times what current Oman VAT rules demand. Businesses whose ERP systems are not mapped to these fields will not be able to clear a single invoice through the network.

This guide sets out the field-level requirements businesses need to plan against: what is mandatory on every invoice, what applies conditionally, what remains optional, and how the rules differ for credit notes, debit notes, self-billed invoices, and simplified B2C invoices.

Key Facts at a Glance

A standard Fawtara e-invoice requires 53 mandatory fields, compared with 18 to 20 fields under current Oman VAT law. The framework is built on the PINT-OM specification, itself an extension of the global Peppol standard, and includes 36 Oman-specific extensions, known as BT-OM fields, that require custom ERP mapping rather than standard configuration. The OTA has defined 8 distinct document types, including tax invoices, simplified invoices, credit notes, debit notes, and prepayment invoices, each carrying its own field requirements. A missing or incorrect mandatory field results in outright invoice rejection at the accredited service provider (ASP) validation stage, not a warning or a flag for later correction. Non-compliance penalties range from OMR 1,000 to OMR 10,000 for invoice and record failures, and from OMR 5,000 to OMR 20,000 for tax evasion or fraudulent reporting.

Mandate Background and Timeline

The OTA became a Peppol Authority in January 2026 and launched the Fawtara portal in March 2026. Phase 1 begins in August 2026, covering roughly 150 large VAT-registered taxpayers, with Phase 2 following in February 2027 for all large enterprises. By August 2027, every VAT-registered business in Oman, including SMEs, falls within scope, with government entities expected to be brought in under a later Phase 4.

The PINT-OM data dictionary remains formally in draft, but the OTA has confirmed that no major changes are expected before go-live, which means businesses can begin ERP mapping against the current field set with reasonable confidence.

The 53 Mandatory Fields on a Standard Tax Invoice

The mandatory fields fall into six functional groups that must appear on every standard tax e-invoice without exception.

Invoice header: invoice number assigned by the seller, invoice issue date, invoice type code, invoice currency code, a document-level UUID (BT-OM-01, an Oman-specific field assigned to every document for traceability), a digital signature (BT-OM-28, required on all invoices under Fawtara), and a QR code (BT-OM-14, mandatory on simplified invoices and B2C transactions).

Seller details: the seller's legal name, VAT registration number, Peppol ID for network delivery, and postal address including country code.

Buyer details: the buyer's legal name, VAT registration number (mandatory for B2B invoices), Peppol ID or electronic address, and postal address.

Tax breakdown: the tax category code (standard rate as S, zero-rated as Z, exempt as E, out of scope as O), the applicable VAT rate, the taxable amount per tax category, the VAT amount per tax category, and the total VAT amount on the invoice.

Invoice totals: the net amount before VAT, the total invoice amount including VAT, and the amount due for payment.

Line item level: a 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), line total including VAT (BT-OM-17, Oman-specific), a document reference per line (BT-OM-84, Oman-specific), and a 12-digit Harmonised System (HS) code, mandatory for every goods line item.

The HS code requirement tends to catch businesses off guard. Where an item master does not already carry 12-digit HS codes for every goods line, closing that gap is a data remediation project rather than a configuration task. For businesses running catalogues with thousands of SKUs, this typically requires dedicated effort and sign-off from the relevant business owner well before go-live, which makes an early audit of the item master a sensible first step.

Conditional Fields

Conditional fields apply only when a specific transaction scenario is present, and the OTA data dictionary identifies up to 66 of them. Common examples include the buyer's VAT number, mandatory for B2B but not required on B2C simplified invoices; a purchase order reference, where the transaction is tied to a purchase order; a contract reference, where the invoice relates to a contract; delivery date and address, where goods are delivered somewhere other than the buyer's registered address; payment due date and terms, where agreed terms differ from the invoice date; a prepayment reference, required where the invoice relates to an advance payment already made; allowances and charges at both header and line level, with accompanying reason codes; foreign currency amounts with an OMR equivalent, required whenever the invoice currency is not Omani Rial, since tax amounts must also be expressed in OMR; a simplified invoice QR code, mandatory for B2C depending on invoice type; and a reverse charge indicator for transactions subject to that mechanism.

Conditional fields are where integration teams generally spend the most time. The underlying logic is not always obvious from the data dictionary alone, and the business rules tied to each condition need to be mapped carefully rather than assumed.

Optional Fields

Optional fields are not required by the OTA but can be included for commercial or operational purposes. These include additional invoice references such as internal references or despatch advice numbers, the seller's bank account details, buyer contact information beyond the mandatory address fields, item classification codes beyond the HS code, the seller's tax representative details where applicable, and free-text notes at invoice or line level.

Optional fields do not cause rejection when absent, but including them with incorrect or malformed values can still trigger schema validation errors at the ASP, since the system validates the entire document rather than only the mandatory fields. Some businesses use optional fields to carry internal ERP references that support reconciliation, which is a valid approach, provided every mandatory field is correctly populated first. Optional fields cannot compensate for a failure in a mandatory one.

Example: A wholesale distributor decides to populate an optional free-text field with an internal warehouse batch code to help its own reconciliation team match invoices back to stock movements. If that same invoice is missing the mandatory 12-digit HS code on one line item, the invoice is still rejected at the ASP, regardless of how useful or well-formed the optional batch code entry is. Optional data adds convenience; it never substitutes for a missing mandatory field.

Correcting Invoices: Credit Notes, Debit Notes, and Self-Billed Documents

This area carries operational implications that are frequently underestimated. Under Fawtara, invoices cannot be cancelled once issued. The only mechanism for correcting a previously issued invoice is a credit note, which requires a fundamental rethink of how error correction workflows are designed.

Credit Notes (Document Type Code 381)

A credit note under PINT-OM must include every standard mandatory field, plus a reference to the original invoice number being corrected (BT-OM-31), the UUID of the original invoice where applicable, a reason code for the credit note (BT-OM-32), and the corrected amounts at both line and total level.

The reason code is not optional in practice. Without it, ASP validation may reject the document before it ever reaches the OTA. Consider a scenario where a retailer issues a batch of credit notes to correct a pricing error across several invoices but omits the reason code field on each one, assuming it to be a minor formality. If the ASP rejects the entire batch on that basis, none of the corrected invoices can flow through the network until every reason code is added and the batch is resubmitted, which can stall reconciliation for days at a time when the business can least afford it.

Debit Notes (Document Type Code 383)

Debit notes follow the same underlying logic as credit notes but are used to increase the value of a previously issued invoice. Required fields include a reference to the original invoice using the same BT-OM-31 field, a reason for the debit adjustment, and updated amount fields at both line and header level.

Self-Billed Invoices

Self-billing occurs where the buyer issues the invoice on behalf of the seller, and this is mandatory for certain import scenarios in Oman. The PINT-OM specification treats self-billing as a distinct process, with additional requirements including the seller's VAT number verified against OTA records, and an explicit indicator confirming the document is self-billed. All standard mandatory fields still apply, with the buyer acting as the document issuer.

For businesses with complex supply chains, particularly in oil and gas or manufacturing, self-billing workflows warrant specific attention, since the underlying data flows differ from a standard accounts receivable invoice and the ERP mapping needs to reflect that difference.

Simplified Invoices (B2C)

Simplified invoices differ from standard B2B invoices mainly in that they do not carry buyer VAT details. QR codes and digital signatures, however, remain mandatory. The seller still submits the invoice to the ASP, but the ASP only sends the tax data to Corner 5, the OTA's regulatory oversight node, rather than routing the full document through the Peppol network to the buyer. The buyer instead receives a separate copy, typically in paper or PDF form.

What This Means for ERP Readiness

The Fawtara mandatory fields are defined and largely stable. While the data dictionary remains formally in draft, the OTA has not signalled significant changes ahead of go-live, which means the practical priority for Phase 1 businesses is to begin ERP gap assessment now rather than waiting for further confirmation.

The 36 Oman-specific BT-OM fields, covering UUIDs, cryptographic elements, line-level VAT amounts, and digital signatures, are not standard outputs of most ERP systems out of the box. These typically need to be built or enabled through an OTA-accredited service provider.

The HS code gap and the credit note reason code logic are two of the most common issues, and both are considerably more expensive to fix once discovered late. These gaps tend to surface during user acceptance testing, at which point remediation delays the go-live date, creates penalty exposure, and puts Phase 1 compliance at risk. Identifying and resolving them during the planning stage costs a fraction of what fixing them under live conditions would.

Key-Takeaways

Fawtara's field-level requirements are detailed, but they are also knowable well in advance of go-live. The businesses best positioned for Phase 1 are those treating ERP mapping, HS code coverage, and credit note logic as a structured remediation project now, rather than discovering the gaps during testing. Accqrate works with businesses to close exactly these kinds of ERP mapping and data readiness gaps, helping align invoice generation with the PINT-OM field requirements ahead of each phase of Oman's e-invoicing rollout.