Oman's Fawtara E-Invoicing in 2027: What Custom ERP and POS Systems Need

Oman is replacing paper and PDF invoices with structured XML e-invoices that pass through an accredited service provider and are reported to the Oman Tax Authority (OTA). The programme is called Fawtara. Taxpayers with annual supplies above OMR 5 million start on 1 April 2027. Every other VAT-registered taxpayer starts on 1 October 2027.

Retail is where it bites hardest. Consumer sales are in scope from the same day as business sales, and every single sale needs its own e-invoice. If your till software, ERP or billing engine was built in-house or heavily customised, the work of producing those documents is yours.

The Dates, and Which One Applies to You

The source is the OTA's Fawtara FAQ, last updated on 31 August 2026. The test is set out plainly. You implement from 1 April 2027 if either of these is true:

• your supplies from 1 April 2026 to 31 March 2027 exceed OMR 5,000,000, or
• your supplies expected from 1 April 2027 to 31 March 2028 exceed OMR 5,000,000.

"If neither is met, you are required to implement e-invoicing from 1 October 2027."

What counts towards the figure: taxable supplies excluding capital assets, goods and services under the reverse charge mechanism, and intra-GCC supplies. A VAT group is assessed at group level, not member by member. A non-resident counts only supplies made in Oman.

Note the second limb. A business growing towards OMR 5 million can land in the April cohort on its forecast alone. If you are near the line, assume April.

The OTA runs a rollout checking tool that takes your VATIN and your current and expected supply band and shows a potential implementation period. It is labelled as being for awareness and readiness only, so treat its answer as a guide and the FAQ as the rule.

The schedule has already moved once

The OTA's own HTML FAQ page still describes the older plan: one hundred large companies from August 2026, all large companies from February 2027, everyone else from August 2027. The PDF replaces those dates with April and October 2027. For a first group of selected large taxpayers (Rollout 1), August 2026 remains the official go-live date, with a grace period to the end of October 2026 as part of a pilot.

One sentence in the PDF's timeline section says mandatory compliance above OMR 5 million is effective "April 1st 2026". Everything else in the same document says 1 April 2027, including the detailed scope answer quoted above. It reads as a slip, but it is a good reason to work from the primary document rather than from anyone's summary, ours included.

How Fawtara Works

Fawtara runs on Peppol, using a five-corner model:

1. Corner 1: you, the seller, issue the invoice.
2. Corner 2: your accredited service provider (ASP) validates it against the Oman rules and passes it on.
3. Corner 3: the buyer's service provider receives it.
4. Corner 4: the buyer.
5. Corner 5: the OTA, which receives the tax data from the service providers.

The format is XML, built to the PINT Oman specifications that OpenPeppol publishes (Billing Process version 1.0.1 at the time of writing). The FAQ is blunt that "A PDF invoice is not an e-invoice". You can still print paper, but only the e-invoice is a valid invoice for tax purposes.

Three details from the FAQ shape the engineering:

• Your provider validates, you stay responsible. The ASP checks each invoice against the Oman schematron rules, but "the responsibility for invoice compliance remains with the taxpayers".
• You connect to one provider at a time. You request the link through the Fawtara portal and you can switch later.
• There is no standard taxpayer API. In the FAQ's words, linking a taxpayer "is not standardized and will vary depending on the service provider's system". Your ERP talks to your provider's interface, not to the OTA.

When the buyer is a consumer or a business not yet on the network, your provider still reports the tax data to the OTA, and the customer gets the invoice the way they do today. Exports go from you to your provider to the OTA.

Who is already covered

If your ERP or POS vendor is itself an accredited provider, or ships a connector to one, most of this article is not your problem. The FAQ says ERP systems "can be retained based on the arrangement taxpayers have with their accredited service providers", and for a packaged system that arrangement is the vendor's to deliver. Your work is master data and testing.

You could also become your own service provider. The accreditation criteria include an Omani commercial registration with IT activities, a minimum paid-up capital, operating history and ISO/IEC 27001 certification, and the FAQ adds passing the Peppol eDelivery and PINT OM test suites. That suits software companies. It is not a shortcut for a retailer.

This article is for everyone else: companies whose invoices come out of a custom ERP, an in-house till system, a billing engine bolted onto an old database, or a branch that still writes invoices by hand.

What Has to Change in Your Software

Map your invoice data to PINT Oman

The FAQ's guidance on mapping is one line: use the Oman PINT specifications. In the semantic model, the Oman-specific fields (prefixed BTOM) are where most of the effort goes:

• A UUID for every document (BTOM-002). It must be RFC 4122 version 5, which is name-based. Derive it from something stable, such as legal entity, branch, till and document number, and a retried submission produces the same UUID instead of a second invoice.
• An invoice transaction type (BTOM-001). This is a 20-position string where each position is a flag: full tax invoice, simplified tax invoice, self-billed, third-party, export, deemed supply, reverse charge import of services, profit margin, e-commerce, import of goods, special zone supply, prepayment and others. More than one flag can be set. Your system has to know which apply to each invoice, and most ERPs never stored that.
• Seller and buyer identifiers with a scheme code: commercial registration, tax identification number, civil ID, passport, importer customs ID or special zone licence number.
• Currency. Invoice currency, VAT accounting currency, the exchange rate between them and the VAT total in the accounting currency all have their own fields.
• Code lists for VAT exemption, zero-rating reasons, service types and country subdivisions.

Expect the invoice lines to map cleanly and the master data not to. Customer records without a VATIN, missing CR numbers, free-text exemption reasons and addresses without a region code all have to be cleaned up before the first live invoice.

Treat every sale as a document

This is the rule that changes POS systems: "Consolidated invoices are not allowed for B2C transactions. An E-invoice must be issued separately for every invoice." No end-of-day summary. A shop that rings up 3,000 sales a day sends 3,000 e-invoices a day.

The FAQ gives B2C submissions 24 hours and B2B submissions real time. For a till, that means:

• The POS builds the XML (or hands the sale to a service that does) at the moment of sale, with its UUID. There is a separate receipt UUID field for B2C (BTOM-004).
• A store-and-forward queue holds documents when the network or the provider is down, and drains them inside the 24 hours.
• Someone is alerted when a document is still unsent after a few hours, not after twenty-three.

Check provider pricing against your volume before you sign. The FAQ says each provider sets its own model, which "may include subscription fees, transaction-based fees, or other pricing arrangements". At retail volumes a per-document fee is a line in the budget.

B2B in real time

For business invoices, submission is real time. Your ERP posts the invoice, the provider validates it, and the result comes back. That changes the invoice workflow in two ways. Validation errors now surface at the moment of posting, so someone in finance needs a screen that shows the rejection and lets them fix it. And invoice numbering, the UUID and the retry logic have to be correct from day one, because a timeout followed by a blind resend is how duplicate invoices happen.

The flow also runs the other way. When you are the buyer, supplier e-invoices from companies already on Fawtara arrive through your provider as XML, and accounts payable needs a way to bring them in.

QR codes on the printed receipt

The QR code is generated by you (corner 1), not by the provider. It is mandatory for all B2C transactions, full or simplified, and it appears on the human-readable invoice, not in the XML. The OTA plans to use it to verify invoices through a mobile app. For its contents the FAQ points to Appendix D of the Peppol Oman Architecture document (version 1.0.2): get that appendix before anyone redesigns a receipt. Receipt templates and printer drivers are part of this project.

Credit notes, returns and corrections

Once issued, an e-invoice is adjusted by issuing an electronic credit or debit note. The specification has fields for the original invoice's UUID and a reason code (BTOM-031 and BTOM-032), so a refund at the till has to be able to find the original sale.

Imports and self-billing

Imports of goods and services are reported as self-billed invoices. If your procurement flow books imports without raising any document, a new step appears there.

Archiving

Storage stays with you. The FAQ says the OTA will not provide invoice information back to taxpayers, and Peppol does not store documents. Keep the validated XML, the provider's response and the printed version together, under the retention rules of the VAT legislation.

A Plan Back From the Deadline

The FAQ says the OTA reaches out to rollout participants at least six months before their onboarding. For the April cohort, that is now.

If you start on 1 April 2027:

1. October 2026: confirm your cohort with the rollout checker and the FAQ test. List every system that issues an invoice: ERP, each POS, e-commerce checkout, rental or subscription billing, and any manual invoice book.
2. November 2026: choose a provider. Ask for API documentation and a sandbox before you sign, and ask about B2C volume, pricing per document, offline handling and what validation responses look like. Request the link through the Fawtara portal.
3. December 2026 to January 2027: build. Field mapping, UUID generation, transaction type logic, the POS queue, QR codes, credit note flow, inbound invoices. Run the Oman schematron rules from the PINT Oman downloads in your own test pipeline, so failures appear in development and not at the provider.
4. February 2027: end-to-end tests against the provider sandbox with real samples of every transaction type you actually issue, including the awkward ones (exports, returns without a receipt, foreign currency).
5. March 2027: a production rehearsal with one branch or business line, a cutover plan and a support rota for the first weeks.

If you start on 1 October 2027, the sequence is the same shifted by six months: provider chosen by the end of the first quarter, build in the second, testing finished by August. Do not spend the slack. The data cleanup always takes longer than anyone estimates.

What Is Still Uncertain

The dates have moved once and could move again. Plan to the PDF dated 31 August 2026, and check the OTA's documents each month rather than relying on news coverage. The legal basis is Decision 189/2026, which amends the Executive Regulation of the VAT Law. The FAQ says penalties will apply under the VAT legislation once the mandate begins, but does not list amounts, so we do not either.

The specifications are versioned too. The current PINT Oman package on the Peppol site carries a release date of 29 July 2026. Pin the version you build against, and watch the release notes.

Where to Get Help

We build the connector between the system you actually run and the format the mandate requires: field mapping, UUID and numbering logic, POS queues, validation in your pipeline, and the integration with the provider you choose. Our e-invoicing integration service covers that work, and when the ERP itself is the obstacle, ERP modernization is where it starts.

If you are in the April cohort and have not chosen a provider yet, write to office@c9group.dev.