Article 143 bis 1: What Oman's E-Invoicing Mandate Requires of Your Systems

The short answer

Article 143 bis 1 is not about invoices. It is a security and business-continuity obligation, it sits on the taxable person, and it lands on the same dates as the rest of the mandate.

The taxable person must:

• ensure secure issuance of the electronic tax invoice through an electronic system
• comply with the prescribed technical specifications to protect that system against breach or unauthorised access
• take measures and procedures to address emergencies, breakdowns or technical malfunctions
• establish mechanisms ensuring the recovery of data in the event of loss for any reason whatsoever, so that the system does not cease operation and continues to function efficiently and effectively

Read as a workplan, that is four separate programmes: access control, incident response, disaster recovery, and availability.

Why this is the article IT will care about and finance will miss

Most coverage of Decision 189/2026 stops at the dates and the invoice format. Those are finance questions. This one is not.

Article 143 covers the document. Article 143 bis 1 covers the system that produces it. They are separate obligations with a shared deadline, and only one of them is satisfied by adopting a compliant format.

The phrasing repays attention. "Recovery of data in the event of loss for any reason whatsoever" admits no cause-based exception — not a supplier failure, not a cloud region, not an accident. And "so that the system does not cease operation" frames availability as an obligation rather than an aspiration, which inverts the usual reading of an outage: it is a compliance failure, not an excuse for one.

Who actually carries it

A licensed provider can carry most of the operational weight — secure issuance, protection against unauthorised access, redundancy, recovery, keeping the platform running. That is what buying a platform is for.

The legal duty does not transfer with the contract. Two consequences follow, and they are the ones worth putting in front of your IT lead:

Your own systems are in scope. The obligation is on issuance, and issuance starts in your ERP and at your point of sale. A hardened provider platform behind an unpatched till does not satisfy the article.

"Our vendor handles it" is not an answer unless the vendor can evidence it. The Authority's counterparty is the taxpayer. If you cannot produce evidence of the controls, you are the one who cannot produce it.

This is also why Article 143 bis — the Authority notifying taxpayers of licensed providers — matters more than it first appears. The provider list becomes a regulatory instrument, and choosing from it is itself part of discharging 143 bis 1.

What to actually do

Treat it as four workstreams with owners, not a checklist item:

1. Access control. Who can issue an invoice, in the ERP, in the POS estate and in the provider platform. Named accounts, no shared credentials, and scoped API keys so a compromised integration cannot issue in your name.
2. Incident response. A written procedure for a breakdown during business hours, with an escalation path to the provider and a decision on what happens to trade while issuance is down.
3. Recovery. Not "we have backups" — a tested restore, with a known recovery point and recovery time, covering the documents themselves and not only the database.
4. Availability. Understand the failure modes of your own estate, not just the provider's. A single till with local-only storage is a data-loss event waiting to be discovered at audit.

One thing worth doing early because it is slow: decide what evidence looks like before you need it. The article does not prescribe a format. Evidence you can put in front of the Authority is stronger than an assertion, so ask any provider what its infrastructure is certified to and what its own practices are aligned to, and ask where the data sits. GoRoute operates ISO 27001-aligned practices on certified cloud infrastructure, and in-country data residency for Oman on Otech's Tier III Oracle Cloud Infrastructure region, which we set out in data residency and compliance in Oman and hosted infrastructure.

A retention point that belongs here

Oman VAT Law RD 121/2020 requires tax records to be kept for 10 years, and 15 years for real-estate-related tax invoices. Article 143 bis 1's recovery requirement and that retention period interact: a document you cannot retrieve in year seven is a retention failure whether the cause was deletion, a lapsed storage configuration or a migration.

If your archive is a bucket nobody has ever restored from, you do not yet know whether you can produce those records. That is worth testing while it is cheap.

Where this sits

The rest of the mandate: which wave you are in, the advance-payment and deemed-supply triggers, and simplified invoices on the same clock. For the exchange architecture, see the five-corner model.

The Oman compliance page covers the requirements, the Peppol API the integration, and you can book a review if you want the security and continuity questions walked through with your IT lead rather than left to the contract.

Sources

• Decision of the Chairman of the Tax Authority No. 189/2026, new Article 143 bis 1
• Oman VAT Law promulgated by Royal Decree No. 121/2020 (record retention)
• Oman Tax Authority and the Fawtara portal