What Your Business Needs to Receive a Fawtara E-Invoice in Oman

Receiving a Fawtara e-invoice is something your service provider does for you, and the part that reaches your finance system is not governed by Peppol at all. An Oman PINT invoice travels over the network as far as your provider's access point. Your provider validates it, builds the tax report from it, answers the sender on your behalf, and hands you the invoice in a format the two of you agreed privately. Three things therefore have to be in place before any of it works: an accredited provider acting as your receiving point, your receiving capabilities registered on Oman's central SMP, and a written agreement on how the invoice gets from that provider into your ledger.

This page is for an accounts-payable or finance lead in a VAT-registered Omani business that is about to start receiving. Everything in it comes from the Oman – Solution Reference Architecture v1.0.3, the Tax Authority's own reference document, published with OpenPeppol.

If your question is instead whether senders can find you at all, that is a lookup rather than a process, and it is on how to check your business is really registered on Oman's SMP.

Where does the Peppol network actually stop?

At your provider's door, not yours.

The architecture is explicit about which parts of the exchange are standardised and which are not. The components in the middle of the model — the sender's access point C2 and your access point C3 — "fall into the scope of standardisation within the Peppol network", while "interaction between C1/C2 and C3/C4 are bilaterally agreed between the respective parties". You are C4. The hand-off into your system is the bilateral half.

That single sentence decides a surprising amount. It means no Peppol rule says the invoice must reach you as UBL XML, or within a particular time, or through a particular channel. It means a provider who delivers a PDF by email and a provider who posts structured XML to your ERP are both compliant. And it means that if you do not specify the hand-off, you will get whatever your provider's default is.

The agreement is not an afterthought either — the architecture builds it into onboarding. After a provider accepts your connection request on the Fawtara portal, the next step is that the provider "contacts the TP for onboarding (outside Portal)" to agree four things: your receiving capabilities, your tax authority, the C1–C2 bilateral data submission format for what you send, and the C3–C4 bilateral data submission format for what you receive.

Two of those four are about receiving. They are settled off the portal, in writing, and nobody validates them for you.

What has to be registered before anyone can send to you?

Your document types, on Oman's central SMP, by your provider.

The architecture puts this as an obligation on the receiving access point. Your provider MUST register receiving capabilities in the SMP for you, identified by your participant identifier scheme and participant identifier, covering:

There is a fifth registration that is not yours. Your provider must also register Message Level Status receiving capabilities against its own service provider identification, not against your participant identifier. If you look yourself up and do not find MLS listed, that is correct rather than missing.

The practical reading for accounts payable is the optional pair. Self-billed documents arrive when a customer raises the invoice for your supply. If any of your large customers self-bills, those documents will be addressed to your identifier and will only arrive if the optional capability was registered. Checking that is a one-minute lookup, and it is the subject of the SMP registration page.

What does your provider do the moment an invoice arrives?

Five things, in a defined order, and only one of them is delivering the invoice to you.

The architecture's receiving flow runs: the provider receives the Oman PINT invoice in the exchange with the sender's access point; validates it using the Schematron rule files; generates both an Oman tax data document and the invoice in the internal C3–C4 format; exchanges three things in parallel — the invoice to you by internal means of communication, the tax data document onward, and a Peppol message level status back to the sender; processes the results; and finally makes the invoices, the tax data documents and both sets of statuses available to you for auditing and archiving.

The order matters for a reason that surprises finance teams. Validation happens before you see anything. A document that fails the Oman rules is answered with a negative status to the sender and is not turned into a tax report at all — the architecture's summary of the receiving role records, against a validation error, "Exchange negative MLS with C2" and "No TDD is exchanged with C5". You will not be asked to adjudicate a malformed invoice, because it never becomes your problem. What reaches you has already passed.

Who answers the sender, and what do they hear?

Your provider answers, in your name, and you never see the message unless you ask for it.

The message level status for an invoice runs from your access point back to the sender's. The architecture describes it as covering the receiver's "status of the compliance in relation to Peppol Business Document Specifications and onwards delivery towards C4" — so it is a statement about both the document and about getting it to you. It is transmitted exactly like a business document, using the same discovery and transmission method, with your provider as sender of the status and the other provider as receiver.

Three codes exist:

The one worth understanding as a buyer is RE, because it covers two different events — a document your provider refused on the rules, and a document that could not be delivered onward to you. Your supplier sees the same code either way, and the detail underneath it is what separates them. That ambiguity, read from the sender's side, is the subject of when an Oman e-invoice is correct but never reaches the buyer.

The question to put to your provider is therefore narrow and answerable: what does your system treat as "delivered to us", and does it send AP or AB? An AP claims your side confirmed receipt. If nothing in your integration confirms anything, AP is being sent on your behalf about an event that did not happen.

What happens if your own system cannot be reached?

Your supplier gets a negative status, and the Tax Authority's record of the transaction changes.

This is the part that turns an internal outage into an external fact. The architecture's summary for the receiving role lists "C4 not reachable" as an exception with two consequences: exchange a negative message level status with the sender, and exchange no tax data document with the Authority.

Its worked scenario for a domestic business-to-business invoice where the buyer is registered on the Oman SMP but not reachable is more specific still. The sequence recorded is: the invoice from the sender's access point to yours, the tax report from the sender's side to the Authority, the Authority's status back, a negative status from your provider to the sender, and then a tax data document carrying D — Disregard — from the sender's side.

So a failed hand-off into your ledger ends with your supplier withdrawing the report of an invoice they correctly issued. Two things follow. Your availability is a commercial term worth writing into the agreement above, not an IT detail. And an outage on your side is visible to every supplier who sends to you that day.

Does the buyer ever report to the Tax Authority?

Yes, in three defined situations — and in ordinary domestic purchasing, no.

Oman's model has three exchange choreographies, and two of them are reporting legs. One runs from the seller's side: (C1) → C2 → C5 → OTA. The other runs from the buyer's side: (C4) → C3 → C5 → OTA. The architecture's scenario table shows which is used when. The buyer-side leg carries the report for self-billing, where the buyer raises the document; for a profit-margin self-invoice where only the buyer is VAT registered; and for imports.

Imports are the case an accounts-payable team meets first, and they work in a way nobody guesses. The architecture states that an import invoice — arriving over Peppol or by any other means, such as mail — cannot be used to produce an Oman tax data document, because it cannot be guaranteed to carry every field the report requires. Instead, your provider produces a self-billed PINT invoice on your behalf, and uses that to generate the tax report. It adds the point that keeps supplier relationships intact: "this SB PINT invoice will not be sent to the original seller, it is only used to generate the TDD."

If your business imports, this is a question to ask your provider before go-live rather than after the first foreign invoice: which of my incoming documents will you convert this way, and what will I see when you do. Why self-billed documents behave differently once they need correcting is covered in correcting a self-billed invoice in Oman.

What do you have to keep, and who hands it to you?

You keep the record; your provider is obliged to give you the material to keep.

The last step of the receiving flow requires your provider to "make all of the Invoices (the original from C2) / TDDs and the Invoice / TDD MLSs available to C4 for auditing and archiving". That is four artefacts per transaction: the original Oman PINT invoice as it arrived, the tax data document built from it, the invoice status and the report status.

Read that next to the architecture's own note on the receiving flow — "Invoice and tax data is stored in transit and then removed, subject to agreement between C4/C3". Your provider is a pipe, not an archive, unless you have agreed otherwise in writing. The long-term record is yours.

The practical test is whether you can retrieve, for a single purchase invoice from eighteen months ago, the document as it actually arrived on the network rather than the rendering your ERP made of it. If the answer depends on a support ticket, that is a gap to close in the agreement rather than in the software.

What to settle with your provider before the first invoice arrives

Five questions, all answerable in a sentence each, all traceable to the architecture:

1. In what format will you deliver invoices to us, and by what channel? This is the C3–C4 bilateral format the onboarding step requires you to agree.
2. Which document types have you registered against our identifier? Two is right for most businesses; four if anyone self-bills you.
3. What do you treat as successful delivery to us, and do you send AP or AB?
4. What do you do with an import invoice, and will we see the self-billed document you create from it?
5. How do we retrieve the original invoice, the tax report and both statuses, and for how long do you hold them?

The contract-side view of these — what a provider agreement should cover before you press Connect — is on what to settle with an Oman service provider before you connect, and if you are still choosing, the comparison is on how to connect your Omani business to an accredited service provider.

What this page does not cover

Input VAT. Whether and when a received e-invoice supports an input-VAT deduction is a tax question. The architecture describes document exchange, not entitlement, so no answer is inferred here. Ask your tax adviser or the Tax Authority.

Retention periods. Neither the architecture nor the PINT Oman specification states how long a buyer must keep received documents. The obligation to be given them is stated, as above; the duration is not, and it is not going to be guessed on this page.

Becoming reachable in the first place. The registration your provider performs, its three-working-day clock and how to verify it are a separate page, linked above.

Related Oman guides

• How to check your Omani business is really registered on Oman's SMP — the lookup that proves senders can address you at all.
• When an Oman e-invoice is correct but never reaches the buyer — the same failure seen from the sender's side, and what they do about it.
• What to settle with an Oman service provider before you connect — where the receiving format and capabilities are actually agreed.
• How to connect your Omani business to an accredited service provider — the portal sequence that comes before all of this.
• The Fawtara five-corner model explained — the legs this page separates, drawn.

What to do next

Ask your provider for the C3–C4 format in writing, this week. It is the one part of receiving that no specification decides for you, and it is the part that determines whether an invoice arrives in your ERP as data or as an attachment somebody keys in.

Then confirm the document types registered against your identifier, using the free Peppol lookup with scheme 0248 and your twelve-digit VAT identification number. Two entries is correct for most businesses; four if you are self-billed.

The commercial and accreditation ground for Oman is on our Oman Fawtara e-invoicing page. Recorded walkthroughs of the systems that sit on the receiving end are on tutorials, and the document types, statuses and identifier formats behind this page are in the developer documentation. To walk your own accounts-payable flow against these rules with our team, book a session.

Sources: the Oman – Solution Reference Architecture v1.0.3 of 27 July 2026 (Final; OpenPeppol AISBL with the Oman Tax Authority) — section 2.1 for the bilateral C3/C4 interaction and the receiving-capability prerequisite, section 2.3 for the message level status direction and the AP/AB/RE code meanings, section 3.2 step 2(d) for the four things agreed at onboarding including the C3–C4 bilateral data submission format, section 6.1.1 for the mandatory and optional receiving capabilities and for MLS being registered against the provider's own identifier, section 6.1.2 and section 6.2 with Figure 17 for the receiving flow and the audit-and-archive step, section 6.5 for imports and the self-billed PINT invoice used only to generate the tax report, section 6.6 for the validation-error and "C4 not reachable" exceptions, section 9 for the worked scenarios including the unreachable buyer, and section 10.1 for the three exchange choreographies. Document types and rules are those of the PINT OM specification v1.0.1, published at docs.peppol.eu; Oman's own e-invoicing material is published by the Tax Authority.