How it works
How Fawtara works
Fawtara moves your invoice through five corners, and the route depends on who your customer is. This page draws both: the model, and the whole life of one invoice from signing up a provider to keeping the archive.
The short answer
Fawtara moves each invoice through a five-corner model: you send it to your accredited service provider, who passes it across the Peppol network to your customer's provider and, in parallel, reports it to the Oman Tax Authority. Which corners are involved depends on whether your customer is reachable on the network.
The five-corner model
Switch the flow to see which corners are actually involved. The arrows change, and so does what each corner is doing — pick a corner to read its role in the selected flow.
Your customer is VAT-registered and reachable through their own provider. The invoice is delivered over the network and the tax data is reported. Submission is real-time.
- 1You — the supplier → Your provider: Submit
- 2Your provider → OTA SMP: Look up
- 3Your provider → Their provider: Deliver
- 4Their provider → Your customer: Deliver
- 5Your provider → Tax Authority: Report tax data
Source
OTA Service Provider FAQ, Q1 and Q20; OTA Monthly FAQ, 30 June 2026 (B2B real-time; Schematron validation; centralized SMP)
The whole life of one invoice
Onboarding happens once. The middle band happens every time you sell. The last band never moves to your provider, whatever you buy.
1Onboarding
Once, before you go live1Log in to the Fawtara Portal
The top menu has an Accredited Service Providers button. This is the OTA's own portal — the connection is made here, not on a vendor's website.
2Pick one provider and press Connect
The list shows each provider's name, solution name, data residency and contact details. You can hold one provider at a time.
3Complete every engagement stage
Identify Service Provider, then Scope and Commercial Negotiations, then Scope and Commercial Finalized, then Agreement/Contract Signed. All stages must be complete before the connection can proceed — so the contract genuinely comes first, and you cannot do this step early to get ahead.
4Upload documents and set an effective date
Give a current or future date. Leave it blank and the connection takes effect as soon as your provider accepts — decide deliberately rather than defaulting into a mid-period cutover.
5Submit — and wait for the provider
The request is accepted, rejected, or it expires. Both sides are notified by email, SMS, on-screen and portal.
6The gate: the SMP checks the portal
Your provider sends an API request to the Oman SMP to add you as a participant. The SMP then queries the Fawtara Portal to verify that a valid connection between that provider and you exists. Verified, and you are added. Not established, and the request is rejected and nothing changes. This is why the portal step is not paperwork: it is the permission your provider needs, and no API of yours can grant it.
Service Provider and Taxpayer Association Management User Manual v1.0, Oman Tax Authority — Part I (taxpayer actions on the Fawtara Portal) and Part III, §11.2 (SMP API validation and response scenarios)
2Every invoice
Every time you sell1Your system creates the invoice
Keep a source invoice model inside your application. Do not hard-code Fawtara into screen forms or document templates.
2Map it to PINT-OM XML — the negotiable boundary
This is the one layer that is genuinely your call: build the XML yourself and keep the mapping as an asset you own, or send your provider your data and let them build it. The mandatory structured format is XML; a PDF is not an e-invoice.
3Your provider validates it
Against Oman's Schematron rules. An invoice that fails comes back to you, and it is not a valid invoice until it passes — so you need somewhere for failures to land and someone to clear them.
4It is routed and reported
Your provider looks your customer up on the SMP and delivers to their provider, and reports the tax data to the tax authority. Which of those actually happens depends on the flow above.
OTA Service Provider FAQ, Q20; OTA Monthly FAQ, 30 June 2026 (XML mandatory; Schematron validation by the service provider)
3Always yours
Never transfers to your provider1The archive
The OTA has stated it will not provide invoice information back to taxpayers or service providers. Keep the source data, the XML, the validation status, timestamps, and the correction history.
2Compliance responsibility
Ultimate responsibility for invoice compliance remains with the taxpayer. Your provider validating your invoice does not move it. Buying an integration does not buy an indemnity.
3The readable invoice
Your document generation keeps its job: on the B2C path you hand the customer the readable copy yourself, and it will require a QR code.
4Corrections
You do not edit an issued invoice. Adjustments go through electronic credit and debit notes that reference the original.
OTA Monthly FAQ, 30 June 2026 (archiving is the taxpayer's responsibility; the OTA will not provide invoice information back; adjustments via credit/debit notes); OTA Service Provider FAQ, Q21 (compliance responsibility remains with the taxpayer)
Where to go next
Answer four questions about a specific invoice, or read the detail behind the boxes.
Official source material
Drawn from the OTA's own published material. This page is for planning and is not tax advice. Where two current OTA documents disagree, both are shown and neither is picked — confirm your own case with your accredited service provider and the OTA.
Ask Fawtara Assistant
Continue with a cited answer from the approved Fawtara source corpus.