Oman Fawtara E-Invoicing: The 5-Corner Model Explained

What is the Oman e-invoicing 5-corner model?

Oman's 5-corner model adds the Oman Tax Authority to the standard Peppol four-corner exchange. Supplier, supplier's Access Point, buyer's Access Point and buyer still move the invoice between them. A fifth corner receives a Tax Data Document derived from that invoice, giving the Authority near-real-time visibility under the Fawtara programme.

What does Peppol 5-corner model compliance mean in Oman?

Peppol 5-corner model compliance in Oman means running your Access Point through a Fawtara-accredited provider, publishing your participant identifier into the Tax Authority's central SMP, issuing PINT OM invoices that pass the official Schematrons, filing a Tax Data Document for every invoice, receiving inbound documents, and retaining them under Omani tax law.

Five of those six are ordinary Peppol obligations that any country on the network would recognise. The sixth — the Tax Data Document — is the fifth corner, and it is the one that makes an Oman project different from a European one. Each is unpacked below, and the tick-list version is under what "ready" looks like.

From four corners to five — why Oman added the tax authority

The classic Peppol network is a four-corner model: a supplier, the supplier's Access Point, the buyer's Access Point and the buyer. It moves a structured invoice from seller to buyer with no central gatekeeper. Oman's Fawtara programme keeps that exchange but adds a fifth corner — the Oman Tax Authority (OTA) — turning it into a continuous transaction control (CTC) regime.

For how the five-corner model works in practice on an accredited platform, see Oman Fawtara e-invoicing.

If you want the underlying Peppol concepts first, see how e-invoicing works over Peppol. This article explains what the Oman Fawtara 5-corner model adds on top.

The five corners, applied to Oman

Corners C1–C4 are ordinary Peppol. Corner C5 is the addition: for every in-scope transaction, a Tax Data Document (TDD) is submitted to the OTA. That single extra hop is what distinguishes a CTC model from open Peppol exchange.

One naming point before the detail, because it appears in every specification you will read. The architecture Oman published with OpenPeppol — the Oman Solution Reference Architecture, version 1.0.1 of 22 May 2026 — calls this a decentralised 5/6-corner model, and splits the Authority's end in two: C5, an access point that receives the Tax Data Document over the Peppol network, and C6, the Tax Authority's own systems, which C5 passes the tax data to outside the network. A supplier still sends to one address. Where this page says "the fifth corner", C5 and C6 are both behind it.

C1 — the supplier that issues the invoice

C1 is the seller. Its address on the network comes from its VAT registration: scheme 0248 with the Oman VAT identification number, written 0248:OM<VATIN>. Two things follow. A business with no VAT registration has no address on the network. And because the identifier is derived rather than allocated, changing service provider does not change it — only the endpoint it points at.

What C1 sends its provider is not fixed by the network. The architecture describes that handover as an "internal (C1-C2) agreed format", which in practice is your ERP's own file or the provider's API. The obligations that are fixed begin where the provider takes the data.

Two variations matter commercially. A seller may appoint a VAT-registered third party to issue invoices for it, and the specification then treats the third party as C1 — the arrangement between seller and agent sits outside the model. And in consumer sales the seller keeps work a business-to-business seller does not have: it generates the seller UUID that goes into the QR code, gives the buyer a readable invoice, and — the architecture's own note on the consumer sequence — "should send the invoice to their AP within 24 hours".

C2 — the supplier's access point

C2 is where compliance actually happens, and the specification is written as a list of things it must be able to do: generate the identifiers for the invoice and the report, construct and validate the PINT OM invoice, construct and validate the Tax Data Document from it, exchange the invoice with C3 and the report with C5, handle the status messages that come back for both, and make the documents available to C1 for auditing and archiving.

Three details are easy to miss and expensive to discover late.

• The invoice and the tax report go out in parallel. The architecture's note on the full model is explicit: "Sequencing of the C2->C3 invoice and C2->C5 TDD submission are in parallel." The report does not wait for the buyer's side to accept the invoice.
• A status is demanded, not hoped for. C2 must set the message-level status handling code to ALWAYS_SEND in the transmission header for both exchanges, so silence from either side is an exception rather than an ambiguity.
• If C1 supplies its own report, C2 still owns it. Where a customer generates the Tax Data Document itself, C2 "must be able to confirm any C1 provided TDDs are a correct representation of the matching Invoice" before it goes anywhere.

C2 also registers its own status-receiving capability in the Authority's central SMP under its service-provider identifier — scheme 0242, the access-point scheme, separate from the taxpayer entry it publishes for you. And invoice and tax data at C2 is, in the architecture's phrasing, "stored in transit and then removed", subject to what you agree with your provider — a data-handling question worth settling in the contract rather than after it.

C3 — the buyer's access point

C3 mirrors C2 on the receiving side. It registers the buyer's receiving capabilities in the central SMP — PINT OM invoice and credit note are mandatory receiving capabilities for Omani invoicing organisations, the self-billing pair optional — validates the arriving document against the Oman rule packs, returns the invoice status to C2, and delivers the invoice to the buyer in whatever format the two of them agreed.

Then it does the thing most readers do not expect: C3 builds its own Tax Data Document from the invoice it received and sends that to C5 as well. The buyer's side files a tax report too, on the same transaction, and receives its own status back. C3 keeps the invoice, both reports and the statuses available to C4 for audit.

C4 — the buyer

C4 receives. As with the supplier, VAT registration is what gives the buyer an address, and the mandatory receiving capability is the PINT OM invoice and credit note pair.

The interesting cases are the ones where C4 is not there at all. If the buyer is not VAT registered, not yet inside the rollout, or is a consumer, there is no C3 leg and no buyer-side report: the flow reduces to the supplier's access point reporting to C5, and a substitute participant identifier stands in for the receiver. The specification lists five of them, all under scheme 0248, covering deemed supply, exports, self-billed imports outside the Oman rules, consumer and profit-margin sales, and domestic buyers not yet part of the rollout.

Self-billing inverts the direction rather than removing a corner: the buyer issues the invoice on the seller's behalf, so the document travels from the buyer's access point to the seller's, and both sides still report to the Authority.

C5 and C6 — the Tax Authority's corner

C5 is an access point like any other, run for a single customer. The specification is precise about it: C5 registers the receiving capabilities in the SMP for the Authority, and "must be registered in the Oman SMP as an AP with one customer (C6)". The Authority is identified under the service-provider scheme 0242 — for example 001090-TaxAuthority.OM — which is the structural statement that Oman's tax authority is a participant on the network rather than a portal you upload to.

What C5 does with an arriving report is narrower than most people assume. It validates the Tax Data Document against the Oman TDD Schematron — the specification adds, in its own words, "and not for Tax compliance etc." — generates a status message back to whichever access point sent it, and passes the tax data on to C6 in an internally agreed format. That final delivery happens outside the Peppol network, exactly as the delivery from C3 to the buyer does.

PINT OM — the invoice format

Oman does not use the European BIS Billing profile directly. It uses Peppol PINT OM, the Oman specialisation of the Peppol International (PINT) model:

• Invoices and credit notes: urn:peppol:pint:billing-1@om-1.
• Self-billing variants with their own customisation identifiers.
• Validation against the official OpenPeppol PINT OM Schematrons — eight compiled XSLTs, two for each of the four document types. The Tax Data Document has its own, separate from the PINT OM set.

For the identifier detail, see the PINT OM CustomizationID reference, and for how PINT differs from the European BIS baseline, Peppol vs PINT.

The Tax Data Document — corner five in detail

The TDD (urn:peppol:taxdata:om-1) is the report Fawtara actually ingests. It carries a short tax-relevant summary — parties, totals, the tax breakdown and document references — and the complete original invoice embedded inside it. Rule ibr-tdd-23 makes the source-document block mandatory, and ibr-tdd-57 requires that block to hold a whole UBL 2.1 Invoice or CreditNote. The summary is the index the Authority reads first; the embedded invoice is the evidence it is drawn from.

That has a direct cost an implementer has to size for. A TDD is roughly invoice-sized plus a small header, so every reported transaction stores and transmits a second copy of its invoice. Plan storage, retention and outbound bandwidth for two copies rather than one — the effect is largest on high-volume point-of-sale estates, where the reporting leg roughly doubles the payload the invoice leg already carries. It also settles a question that comes up in scoping: there is no set of commercial fields that can be held back from the Authority, because under this design the whole invoice goes.

Crucially, a well-designed provider derives the TDD deterministically from the PINT OM invoice rather than asking the customer to maintain a second data model. Our Oman TDD deep-dive walks through the structure field by field.

What does the fifth corner actually receive?

For a domestic sale between two VAT-registered businesses, the Authority receives the same invoice twice — once in a report filed by the supplier's access point, once in a report filed by the buyer's, each answered with its own status message. That is the first of the twelve document flows the architecture sets out: C2->C5 TDD-OM and C3->C5 TDD-OM, with a status returned to each sender.

Two reports on one sale is a design choice, not duplication by accident. Each side attests to what it actually handled, and the Authority compares them.

The identifier that ties the two reports together

The two reports are matched by the invoice UUID, and the way it is produced is the elegant part. It is a version 5 UUID — a hash-based identifier, meaning the same input always produces the same value — calculated over a fixed list of invoice fields: the seller's identifier and its scheme, the invoice type code, the invoice number, the invoice date, the total tax amount and the total amount including tax, with the total amount due added for profit-margin invoices. All of it hashed under one namespace fixed by the specification.

Because the recipe is fixed, the supplier's access point and the buyer's access point independently compute the same identifier for the same invoice, without exchanging it. That is what lets the Authority see two reports as one transaction. It also means the identifier changes if the content changes — a corrected invoice is a different invoice, by construction.

The report itself carries a different kind of identifier: a version 4 UUID, generated locally, held in the report's own TDT-003 field. The transmission that carries it has a third. So a single sale leaves three traceable identities — the invoice, the report, and the delivery — which is what makes reconciliation possible when something goes wrong.

The states a report moves through

The Authority's own systems track each report through a small set of states, driven by the submission type the sending access point sets: Submit, Resubmit or Disregard.

• A Submit where nothing has been received for that invoice is simply used.
• A Resubmit replaces an earlier report: the previous one is marked "disregard" and the new one becomes current.
• A Disregard withdraws a report that should no longer stand.

A newly arrived report sits pending for a defined window before it is treated as submitted, so that a correction arriving shortly afterwards replaces it rather than joining it. The architecture also writes down the mismatched cases, which is where implementations diverge: a Submit for an invoice already reported is handled as a resubmission, a Resubmit with nothing to replace is handled as a submission, and a Disregard with nothing to withdraw does nothing at all.

What comes back, and what it does not mean

The response is a Peppol message-level status — a delivery verdict between access points, using three codes: AP (delivered and confirmed), AB (delivered, no confirmation) and RE (rejected, or delivery failed). Read it for what it is. A positive status from the fifth corner says the report was well formed and accepted for processing; it is not a ruling that the tax treatment is right, because the specification limits that validation to the document rules "and not for Tax compliance etc.".

Timing is set by the programme rather than by the network. The testbed values published with the architecture — fifteen minutes from validation to report for business-to-business transactions, thirty for consumer transactions, twenty minutes for a status to come back — are labelled as testbed configuration for demonstrating that a provider can hold a service level. The architecture is explicit that production timings for reports live in Oman's Peppol Authority Specific Requirements, not in this document.

Clearance vs post-audit — where Oman sits

Regimes fall on a spectrum:

• Post-audit (traditional Europe): invoices exchanged freely; the tax authority inspects later.
• Clearance / CTC (Oman, and much of the Gulf and Latin America): the tax authority receives a tax view around the time of exchange.

Oman's Fawtara sits firmly in the CTC camp. The TDD submission gives the OTA near-real-time visibility. The commercial invoice still flows supplier-to-buyer over Peppol; a second document, carrying that same invoice inside it, flows to corner five in parallel.

What clearance changes for a supplier

The practical change is that issuing the invoice is no longer the end of the transaction. Under a post-audit regime an invoice is finished when the buyer has it, and the tax authority's interest arrives later, if at all. Under Oman's model a second document about the same sale leaves your provider within minutes, and something has to happen when it does not. Five consequences are worth planning for.

Your invoices are reported from both ends. You will never see the buyer's report, but it exists, it is built from the invoice you sent, and it is matched to yours by an identifier both sides compute from the same fields. The practical effect is that an invoice which is right in your ledger and wrong on the wire is visible as a discrepancy — so the document you send matters as much as the entry you book.

Nothing can be held back. The report carries the complete original invoice inside it, so there is no set of commercial fields that stays between you and your buyer. This comes up in scoping more often than any other question, and the answer does not vary by industry: under this design the whole invoice goes.

A failure is now an operational task, not a silence. The specification writes down each way the exchange can fail and what has to follow. If the buyer's access point reports a validation error, or reports that the buyer could not be reached, the supplier's provider resolves the exception and sends a Disregard report to the Authority — so a tax report does not stand behind an invoice that never arrived. If the Authority's access point rejects the report itself, the provider fixes it and resubmits. And if no status comes back inside the service-level window, that too is an exception to chase rather than a message to wait for. What you should ask a provider is not whether it handles these, but what it does with them: are they visible to your finance team, or do they sit in a log.

It is not only business-to-business. The twelve flows in the architecture cover exports, where only the supplier's side reports; imports, where the Omani buyer's access point files a report on a foreign seller's invoice; profit-margin sales; deemed supplies; and consumer sales, where the buyer is not on the network at all. Consumer sales carry their own visible obligation — a readable invoice with a QR code holding the seller's name and VAT number, the invoice date and time, the total including VAT, the VAT total and a seller UUID generated from exactly those values. If you run a point-of-sale estate, that QR code, and getting the day's invoice data to your provider inside 24 hours, is the part of the mandate your customers will actually see.

Your records grow. Because the whole invoice travels inside the report, storage and outbound bandwidth carry a second copy of everything you issue. Alongside the documents, accredited providers must retain transmission and transaction metadata — at minimum sender and receiver identifiers, transmission timestamps, and acknowledgement and delivery confirmations. Ask where that evidence lives, in what format, and how you get it out, because the day you need it is an audit.

Rollout cohorts and timeline

The OTA is sequencing the mandate by taxpayer cohort:

• Pilot — 100 large companies, voluntary, from end-August 2026 (the Tax Authority's own figure).
• 1 April 2027 — taxable persons whose annual supplies exceed OMR 5,000,000.
• 1 October 2027 — all other VAT-registered taxpayers.

Sitting above that sequencing there is now a statutory deadline. Decision 189/2026 makes electronic tax invoices mandatory from 1 April 2027 where annual supplies exceed OMR 5,000,000 and from 1 October 2027 below that threshold — see Oman sets e-invoicing dates.

For the engineering view of what onboarding and testbed conformance involve, see the Oman Fawtara readiness checklist, and for provider status, GoRoute's OTA accreditation.

What "ready" looks like

A Fawtara-ready Omani taxpayer has:

• [ ] An accredited Fawtara service provider contracted, running your Peppol Access Point.
• [ ] Its participant identifier (0248:OM<VATIN>) published by that provider into the Tax Authority's central SMP, and discoverable — Oman runs the SMP centrally, so this is not something a provider hosts for you.
• [ ] PINT OM issuance passing the official Schematrons on error.
• [ ] Deterministic TDD generation from the invoice, submitted to the OTA.
• [ ] An inbound reception path for received PINT OM documents.
• [ ] Audit retention meeting Omani tax-law requirements.

Being ready is not only a document question. Article 143 bis 1 places a separate security and business-continuity duty on the taxable person — secure issuance, protection against breach and unauthorised access, procedures for breakdowns, and mechanisms for recovering lost data — and it falls due on the same two dates as the rest of the mandate. It is set out in what Oman's e-invoicing mandate requires of your systems.

How GoRoute helps

GoRoute (POP000991) operates a certified Peppol Access Point, publishes your participant entry into the Service Metadata Publisher the Tax Authority runs centrally — that is Oman's model, and no provider hosts one for you here — compiles the official PINT OM Schematrons at build time, and generates the Oman TDD from the PINT OM invoice in a single workflow. One API call covers issuance, validation, Peppol transmission and CTC submission. GoRoute is accredited by the OTA as an Oman e-invoicing service provider, accredited 29 July 2026 through Union Digital Technologies SPC. Book a demo to scope a Fawtara rollout against your cohort.

---

Sources: Oman Tax Authority; OpenPeppol PINT; Peppol network directory.