Mandatory Data Fields for Fawtara E-Invoicing in Oman

Oman's e-invoicing mandate has moved well past the planning stage, and the field-level requirements businesses must meet are now substantially defined. The Oman Tax Authority (OTA) has published its technical specification through OpenPeppol, and the number of mandatory fields required on a compliant invoice has changed materially as that specification has matured. Businesses whose ERP systems are not mapped to the current field set will not be able to clear invoices through the network once their compliance date arrives.

This guide sets out what businesses need to plan against: what is mandatory, what applies conditionally, what remains optional, how the requirements differ for credit notes, debit notes and self-billed invoices, and where the field requirements have genuinely changed since earlier draft guidance circulated.

Mandate Background and the Revised Timeline

The OTA became a Peppol Authority in January 2026 and published the PINT OM technical specification through OpenPeppol in April 2026, with a finalised version, PINT OM 1.0.1, released on 29 July 2026 covering billing, self-billing and the Tax Data Document process.

The compliance calendar has since been revised. Tax Authority Decision No. 189/2026, published in the Official Gazette on 9 August 2026, replaced the original multi-phase rollout with two threshold-based mandatory dates:

1. April 1, 2027, for taxable persons whose annual supplies exceed OMR 5 million.
2. October 1, 2027, for taxable persons whose annual supplies do not exceed OMR 5 million.

Around 100 large taxpayers took part in a voluntary pilot that began issuing e-invoices in August 2026, and other businesses may opt in early on the same voluntary basis. No taxpayer is required to comply before April 1, 2027, and the OMR 5 million threshold determines only the timing of the obligation, not whether a business is ultimately in scope.

How the Mandatory Field Count Has Changed

This is a point businesses need to treat carefully. An OTA data dictionary circulated for consultation in November 2025 set out 53 mandatory fields on a standard tax invoice. When the PINT OM framework was published through OpenPeppol in April 2026, independent review of that specification found the mandatory field count had risen to 73, with 28 new fields added as mandatory and several previously mandatory fields reclassified as optional.

The same review found that QR codes, digital signatures and invoice hashes, all treated as mandatory in the November 2025 draft, were removed from the mandatory field list in the published PINT OM framework. Some guidance issued after this update continues to reference the earlier 53-field count and mandatory QR codes, which suggests the wider advisory market has not fully converged on the current position. Businesses should not treat any single third-party summary, including this one, as the final word. The safest approach is to confirm the exact mandatory field list against the OTA's currently published PINT OM 1.0.1 documentation before finalising ERP mapping, and to revisit that mapping if the OTA issues further clarification, since this has already happened once.

Mandatory Field Categories on a Standard Tax Invoice

Regardless of the exact total, the mandatory fields fall into recognisable functional groups that consistently appear across every version of the specification:

1. Invoice header details: a seller-assigned invoice number, invoice issue date, invoice type code drawn from the international UN/CEFACT code list, invoice currency code, and a document-level unique identifier for traceability.
2. Seller details: legal name, VAT registration number, Peppol identifier for network delivery, and a full postal address including country code.
3. Buyer details: legal name, VAT registration number for B2B invoices, Peppol identifier or electronic address, and postal address.
4. Tax breakdown: the applicable tax category code for standard rated, zero rated, exempt and out of scope supplies, the VAT rate, the taxable amount per category, and the VAT amount per category.
5. Invoice totals: the net amount before VAT, the total invoice amount including VAT, and the amount due for payment.
6. Line item detail: item identifier, description, quantity, unit of measure, net price, line net amount, line VAT amount, and a 12 digit Harmonised System code for goods line items.

The Harmonised System 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, and it is worth auditing the item master early, well ahead of the relevant go live date.

Conditional and Optional Fields

Conditional fields apply only when a specific transaction scenario is present. Common examples include:

1. The buyer's VAT number, required for B2B invoices but not for B2C simplified invoices.
2. A purchase order or contract reference, where the transaction is tied to one.
3. Delivery date and address, where goods are delivered somewhere other than the buyer's registered address.
4. Payment due date and terms, where these differ from the invoice date.
5. A prepayment reference, where the invoice relates to an advance payment already received.
6. Allowances and charges at header or line level, with accompanying reason codes.
7. Foreign currency amounts with an OMR equivalent, since tax amounts must be reported in Omani Rial regardless of the invoice currency.
8. A reverse charge indicator for transactions subject to that mechanism.

Optional fields are not required by the OTA but can support commercial or operational purposes, such as internal references, despatch advice numbers, seller bank details, or free text notes. Optional fields do not cause rejection when absent, but a malformed optional field can still trigger a validation error, since the whole document is checked, not only the mandatory portion. Optional data adds convenience; it never substitutes for a missing mandatory field.

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

Under the Peppol based model Oman has adopted, invoices are generally not cancelled once issued. The recognised mechanism for correcting a previously issued invoice is a credit note, drawing on the same international invoice type coding used across Peppol implementations elsewhere.

A credit note must include every standard mandatory field, plus a reference to the original invoice being corrected, a reason code for the adjustment, and the corrected amounts at both line and total level. The reason code matters in practice: a batch of credit notes submitted without one risks rejection at the accredited service provider stage, which can stall reconciliation across an entire batch until every entry is corrected and resubmitted.

Debit notes follow the same underlying logic but are used to increase the value of a previously issued invoice, requiring a reference to the original invoice, a reason for the adjustment, and updated amounts at line and header level.

Self-billing occurs where the buyer issues the invoice on behalf of the seller, and this is required for certain import scenarios under reverse charge. The PINT OM self-billing specification treats this as a distinct process, with 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. Businesses with complex supply chains, particularly in oil and gas or manufacturing, should give this workflow specific attention, since the underlying data flow differs from a standard receivable invoice.

Simplified invoices for B2C transactions differ from standard B2B invoices mainly in that they do not require buyer VAT details. The seller still submits the invoice to its accredited service provider, which reports the relevant tax data to the OTA, while the buyer typically receives a separate readable copy outside the formal network.

Penalties for Non-Compliance

The OTA has not yet published a dedicated penalty schedule specific to e-invoicing. Non-compliance is therefore addressed under Oman's existing VAT Law penalty framework:

1. Administrative violations, such as record keeping failures, generally start from OMR 500.
2. Deliberately failing to issue a required tax invoice, or deliberately failing to keep invoices and records for the required retention period, carries a fine of between OMR 1,000 and OMR 10,000, imprisonment of between two months and one year, or both, under the VAT Law's general penalty provisions.
3. Understatement of output tax or overstatement of input tax carries a percentage-based penalty on the tax difference.
4. Tax evasion carries a substantially higher percentage-based penalty and may attract further criminal consequences.

Because a dedicated e-invoicing penalty schedule has not yet been issued, businesses should treat the general VAT Law framework as the operative one for now and monitor OTA guidance for any e-invoicing specific penalty structure that may follow.

What This Means for ERP Readiness

The practical priority for affected businesses is to begin ERP gap assessment now, working from the current PINT OM 1.0.1 documentation rather than earlier draft materials. Fields that are Oman specific, including unique document identifiers and line level VAT detail, are not standard outputs of most ERP systems out of the box and typically need to be built or enabled through an OTA-accredited service provider.

The HS code gap and the credit note reason code requirement are two of the most common issues, and both are considerably more expensive to fix once discovered during user acceptance testing than during the planning stage. Given that the mandatory field count and the QR code and digital signature requirements have already changed once since the initial draft, businesses should also build a process for re-checking their mapping against future OTA updates rather than treating today's field list as permanently fixed.

Frequently Asked Questions

How many mandatory fields does a Fawtara invoice require?

The figure has changed as the specification developed, rising from 53 fields in the November 2025 draft to 73 in the finalised PINT OM framework. Businesses should confirm the current count directly against the OTA's published specification rather than relying on a single fixed number.

Are QR codes and digital signatures mandatory?

They were mandatory in the earlier draft but were removed from the mandatory field list when the PINT OM framework was finalised. Some published guidance has not yet caught up with this change, so this is worth confirming directly before building compliance logic around either requirement.

What happens if a mandatory field is missing or incorrect?

The invoice is rejected at the accredited service provider validation stage before it reaches the OTA or the buyer, rather than being flagged for later correction.

Can an issued invoice be cancelled?

No. Corrections are made through a credit note, and adjustments that increase value are made through a debit note.

When must my business actually comply?

From April 1, 2027, if annual supplies exceed OMR 5 million, or from October 1, 2027, if they do not, under Decision No. 189/2026.

What penalties apply for non-compliance today?

There is no dedicated e-invoicing penalty schedule yet. Oman's general VAT Law penalties apply, including fines and potential imprisonment for deliberate failures to issue or retain compliant invoices.

Key Takeaways

Fawtara's field level requirements are detailed and have already changed once as the underlying specification matured, from 53 to 73 mandatory fields, with QR codes, digital signatures and invoice hashes moving out of mandatory status. Businesses best positioned for their compliance date are treating ERP mapping, HS code coverage and credit note logic as a structured, ongoing readiness project rather than a one-time exercise based on a single draft. Accqrate works with businesses to close exactly these kinds of ERP mapping and data readiness gaps, helping align invoice generation with the current PINT OM field requirements as Oman's e-invoicing rollout progresses.