Fawtara
Oman's e-invoicing mandate does not ask you to buy new software. It asks your invoices to leave your system as structured data carrying the fields the specification names, and to reach the Tax Authority through an accredited service provider. Dynacloud is not an accredited service provider and transmits nothing. We do the work in between: find out what your system actually holds, map it to what a compliant invoice must carry, change what has to change inside your system, and connect it to the provider you sign with. Because we are not the pipe, we have no reason to steer you towards one.
Almost every firm writing about Fawtara is an accredited service provider selling its own transmission service. That is a real service and you will need one. It also means the party advising you on which provider to choose is the provider. We are in a different job. We make your existing system emit the right document and hand it over correctly, and we connect it to whichever accredited service provider you contract with. If you change provider in two years, the mapping and the work done inside your system stay yours.
Dynacloud is not an accredited service provider, holds no Access Point status, and transmits no invoices to anybody.
Nothing on this page implies approval, endorsement or accreditation by the Oman Tax Authority. We hold none and we claim none.
We work on the system you already run: Dynamics 365 Finance and Operations, Business Central, SAP, Oracle, a bespoke application, or something written fifteen years ago that nobody wants to touch.
Fawtara integration is a new offering for us and we are saying so rather than dressing it as a track record. What is not new is the connecting work itself, which is what this firm has done in Dynamics and Azure for years.
Oman's e-invoicing programme is Fawtara. The Tax Authority was approved as a Peppol Authority by OpenPeppol in January 2026 and published the PINT OM specification in April 2026. The model has five corners, and you are only one of them. What travels between them is a structured XML document conforming to PINT OM, also written OM PINT, with a Tax Data Document alongside it. The consequence for you is narrow and specific: at the moment the sale happens, your system has to be able to produce that document with every field correctly populated. Nothing else about the mandate matters until that is true. The rollout is phased, beginning with the largest taxpayers notified directly by the Authority from August 2026, the remaining large VAT registered businesses from February 2027, and every other VAT registered business from August 2027, with a further phase covering business to government invoicing after that. Confirm your own phase with the Authority rather than with a vendor, including us. If you are in the last group you are not late, though the customer data work below should start well before your date.
Corner one: you, the supplier.
Corner two: your accredited service provider.
Corner three: your customer's accredited service provider.
Corner four: your customer.
Corner five: the Oman Tax Authority.
We do not start from our data model. We start from yours, because the first real question has a different answer in every system: where does tax actually live? In Dynamics 365 Finance and Operations it sits on the tax transaction rather than on the sales line. In a bespoke application it is usually one percentage on the invoice header. In SAP it comes from condition records. Everything downstream depends on that answer and none of it can be assumed from the outside. What comes out of discovery is a field map: a document saying, item by item, where each thing a compliant invoice must carry will come from in your system, and what happens where nothing exists yet. You sign it before any code is written, because that document is what the rest of the project is measured against.
Seller: VAT registration number and commercial registration number, resolved correctly where branches trade under a group registration.
Buyer: the legal entity name rather than the name of the person who placed the order, the buyer's VAT registration where they are registered, identity details for an individual buyer, and an address.
Document: its type, its number, the issue date and the supply date, and a reference to the original where the document is a correction.
Currency, and the exchange rate used where the invoice is not in rial.
Per line: description, quantity, unit of measure, unit price, discount, taxable amount, tax rate, tax amount, and an exemption reason wherever the rate is not the standard one.
Totals: taxable total, tax total, gross total, and a decided answer for where any rounding difference sits and how the two systems reconcile to the minor unit.
Document type classification, which is its own decision: a purchase receipt from a member of the public is not a tax invoice, a deposit or advance invoice is not a final one, a credit note is not an edit, and a proforma is not any of them. A system that calls all of it 'invoice' has work to do here.
Every proposal you read will describe connecting your system to Fawtara and stop there. The connecting is the short part. These four are where the project actually goes, and they are why work that looked simple in March goes live in November.
The customer master. Buyer VAT registration numbers are missing, invoices are made out to the individual who placed the order rather than the company that pays, and addresses are half filled or unusable. This is routinely the longest single task, it is mostly your staff's time rather than ours, and it should start the day you decide to go rather than the day the mapping is finished.
VAT classification per line. Oman distinguishes three treatments and they are not interchangeable: standard at 5 percent inside the taxable base; zero rated, which is 0 percent but still a taxable supply with input VAT recoverable; and exempt, which is outside the tax base with no input recovery. Most systems carry one taxable yes or no flag, which physically cannot tell the second from the third, and the two land in different boxes on your VAT return. Which of your categories is which is a decision for your accountant. It is not a mapping exercise and we will not make it for you.
Numbering and immutability. The number must be sequential, without gaps, without duplicates, and the document must not be editable after issue. Three common designs fail this. Reading the highest number and adding one produces duplicates the moment two users save together. A raw database sequence is safe but leaves gaps when a transaction rolls back, and every gap needs an explanation. Numbering that restarts per till or per branch, with no branch component in the number, produces duplicates by design. Related and usually overlooked: when a sale is abandoned at the counter the number is already spent, so a cancelled document needs its reason recorded at the moment it is cancelled. A spent invoice number with nothing behind it is exactly what an enquiry asks about. Fixing any of this happens inside your system before integration work can start, which is why it is normally the item that moves the go live date.
Deposits and advance invoices. VAT falls due when the money arrives. The final invoice then has to account for tax already charged on the deposit and must not charge it a second time. If your system treats a deposit as a note against the order rather than a document in its own right, that is a change to the system, not a setting.
A project is finished when four things are true, and none of them is a demo of a happy path.
Every combination your trade actually produces has been through the provider's sandbox and come back accepted: a standard rated sale, a zero rated one, an exempt one, a basket that mixes them, a credit note that references its original, an advance or deposit invoice, and an invoice in a foreign currency.
The rejection path has been walked by the people who will walk it for real. What appears on the counter screen when a document is rejected, who fixes it, and whether the sale can complete while the document is still in flight.
The archive answers a request. The issued structured document and the provider's response are both stored, you know for how long and who can retrieve them, and you can produce them on demand. A stored PDF of the printed invoice is not the same thing, and an enquiry asks for the structured document.
Go live is a plan rather than a date. Which document types move on which day, a period running in parallel, a reconciliation between what your system issued and what the provider transmitted, and a written answer to what your counter staff do if the provider cannot be reached. That last answer is needed before go live, not after the first outage.
Two routes, and we will tell you honestly which one your system is in. Keep the system you already run and we connect it, which is the work described above. Or move to Nizro, the business system Dynacloud builds and owns, where the structure is already inside: three VAT treatments per line rather than one taxable flag, the tax rate stamped onto each document as it is created, sequential numbering from a database counter rather than a highest number plus one, financial and identity fields the database refuses to change after the document exists, credit notes as documents rather than edits, and a cancellation that will not commit without a recorded reason. The boundary is the same for Nizro as for anyone: its invoices are structured rather than scanned, but it produces no PINT OM XML, carries no QR code and no digital signature, transmits nothing and holds no accreditation, so a business on Nizro still signs with an accredited service provider. We are telling you about the second route on a page selling the first because if we thought replacing was always the answer we would not sell the other half.
No, not necessarily. Fawtara asks for a structured invoice carrying the fields the Oman specification names, sent through an accredited service provider. If your existing system can be made to produce that document, number invoices sequentially, and stop them being edited after issue, connecting it is usually cheaper than replacing it. Systems that fail on numbering, on editability after issue, or on holding tax per line rather than per invoice are the ones where replacing becomes the cheaper answer.
No. Fawtara is Oman's e-invoicing system, run by the Oman Tax Authority. Fatoora, also written Fatoorah, is Saudi Arabia's, run by ZATCA. They are separate systems in separate countries with different technical requirements, and being compliant in one does not make you compliant in the other. Anyone who has worked in both markets tends to use the two names for the same thing, which is why the confusion is so common.
No. Dynacloud is not an accredited service provider and transmits nothing. Invoices reach the Authority through an accredited service provider, which you contract with directly. Our work is to make your system produce the correct document and hand it over correctly, and to connect it to whichever provider you choose. That is also why our advice on which provider to use is worth more than a provider's.
PINT OM, also written OM PINT, is the Oman specialisation of the Peppol International Invoice model. It is the technical specification your invoice XML has to conform to, and a Tax Data Document travels alongside it. The Oman Tax Authority was approved as a Peppol Authority by OpenPeppol in January 2026 and published PINT OM in April 2026.
In phases. The largest taxpayers, notified directly by the Authority, come first from August 2026. The remaining large VAT registered businesses follow from February 2027, and every other VAT registered business from August 2027, with a further phase covering business to government invoicing after that. Confirm your own phase with the Oman Tax Authority rather than with a vendor. If you are in the last group you are not late, but the customer data work should start well before your date.
A signed field map showing where every required invoice field comes from in your system. The changes inside your system that the map shows are needed, most often to invoice numbering, to editability after issue, and to how tax is held per line. A connection to the accredited service provider you have chosen. Sample documents accepted through that provider's sandbox for every case your trade produces, including credit notes and deposit invoices. A tested rejection path your counter staff have used. An archive holding both the structured document and the provider's response. And a go live plan with a parallel period and a reconciliation between what your system issued and what the provider transmitted.