What Happens When an Invoice Reaches Oman From a Supplier Abroad

An invoice from a supplier outside Oman is never the document your business reports to the Tax Authority. The Authority's own architecture is explicit that an import invoice cannot produce an Oman tax data document, because nothing guarantees it carries every field that report needs. So your provider builds a document that can: a self-billed PINT invoice, raised in your name from the foreign invoice, used only to generate the tax report — and deliberately never sent to the supplier who invoiced you. If a self-billed document nobody asked for appears in your records after a foreign purchase, that is the mechanism working rather than a mistake.

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

What has to be in place before any invoice can reach you at all — registration, capabilities and the format your provider hands you — is the wider subject of what your business needs to receive a Fawtara e-invoice. This page takes one case from it and follows it to the end.

Why can't an imported invoice be reported to the Tax Authority?

Because nothing guarantees it carries the fields an Oman tax data document requires.

The architecture's wording is unambiguous: the import invoice, "Peppol or non-Peppol", "cannot be used to produce a TDD by Oman Invoice Receivers, because it cannot be guaranteed that the Invoice can provide all required data necessary for creating an OM TDD".

The reason sits in the diagram beside that sentence. In the domestic case the document crossing between two access points is an Oman PINT invoice, built against Oman's own rules. In the import case the diagram labels the document moving between the supplier's provider and yours simply a Peppol BIS invoice — a valid invoice in the sender's own country's specification, which was never written to carry Oman's tax-reporting fields. A French or Belgian supplier issues a correct invoice under its own rules. Those rules do not know what Oman's report needs.

Faced with a document that might map and might not, the architecture does not ask your provider to guess. It takes the import invoice out of the reporting path completely — which is not a rejection. The import invoice is still your purchase invoice, it is still delivered to you, and nothing about it is treated as invalid. It is simply not the thing that gets reported.

What is the self-billed invoice your provider creates?

A document your own provider raises in your name, from the foreign invoice, for exactly one purpose.

The architecture continues: "in this case the Buyer's C3 will produce a self-billed PINT Invoice to be able to generate a TDD for tax reporting purposes." Your provider is C3. You are C4. So the document is manufactured on your side of the border, from information that arrived on the foreign invoice, in the format Oman's reporting needs.

Three consequences follow, and all three matter to accounts payable.

It never reaches your supplier. The architecture adds the sentence 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." Nobody abroad receives a document claiming to invoice them, and nothing you do here changes what you owe.

It has one job. It is not a second purchase invoice, not a credit, and not a payment instruction. It exists so that a report can be generated.

It is a self-billed document, with everything that implies. If its figures turn out to be wrong, the correction is a self-billed correction — raised on the buyer's side, not requested from the supplier. The codes and references such a correction has to carry are the subject of correcting a self-billed invoice in Oman.

Does the invoice have to arrive over Peppol at all?

No — and this is the part finance teams most often have backwards.

The architecture introduces the import scenario as covering invoices "where the sending organisation is outside Oman and the receiving organisation is within Oman", and says plainly that it "covers both Peppol exchange and using other means of exchange e.g. mail".

A scanned invoice emailed by an Italian supplier is in scope in the same way a Peppol document is. The reason an import cannot produce a tax data document is the content of the document, not the channel it travelled on — so changing the channel changes nothing.

The summary table for receiving providers makes the same point from the other direction. For international traffic, both Peppol and non-Peppol, the row against the Tax Authority reads "No Exchange", and for non-Peppol traffic the row back towards the sender's provider reads "No exchange" as well. The import invoice itself generates nothing on the network in either direction.

One thing the architecture does not settle, and we are not going to invent it: it does not describe how a provider comes to know about an invoice that arrived by post or by email directly to you. Getting that invoice to your provider is part of the bilateral arrangement between the two of you, which the architecture leaves to the parties. That is a question for your provider agreement, and it is worth asking before the first one arrives rather than after.

Which messages actually move when you import?

Two — and neither of them goes to your supplier.

Oman's document-flow table lists every scenario the network supports. Three of them are worth reading side by side.

Read the import row twice. There is no status message back to the sender's provider, no reporting leg on the seller's side, and exactly one report — yours. Oman's model defines three exchange choreographies, and imports use the buyer-side one, which runs from you, through your provider, to the Authority's endpoint and on to the Tax Authority. The table adds the same note in its own words: a self-billed PINT invoice will be created by your provider to generate the report, and it will not be sent to the original seller.

One apparent contradiction, named rather than smoothed over. The summary table quoted above records no exchange with the Authority for international traffic, while the document-flow table records a report going from your provider to the Authority on an import. The reading that makes both statements true is that the import invoice is never the reported document, and the self-billed invoice built from it is. That reading is ours, not the Authority's wording. If your provider reads it differently, that difference is worth surfacing before go-live rather than during your first audit.

Why does a self-billed invoice appear in records nobody asked for?

Because your provider had to create one, and it then has to hand it to you.

The receiving flow obliges your provider to make the invoices it received, the tax data documents and both sets of status messages available to you for auditing and archiving. On an import, that set has an extra member. A single foreign purchase therefore leaves you holding:

1. the original import invoice, as it arrived;
2. the self-billed PINT invoice your provider created from it;
3. the tax data document generated from that self-billed invoice;
4. the Tax Authority endpoint's status on that report.

Three practical rules follow for the accounts-payable team that finds item two.

It is not a second liability. One purchase, one payable, two documents describing it. A self-billed invoice arriving alongside a supplier invoice for the same amount is the expected outcome, not a duplicate to be investigated.

Reconcile on the original. The document your supplier will discuss with you, chase payment against and reference in a dispute is the import invoice. The self-billed one does not exist on their side of the conversation.

If the figures are wrong, correct the self-billed document as a self-billed document. Your supplier cannot issue a credit note against an invoice they never saw.

Timing is worth knowing too, because it decides whether this is visible immediately or at period end. The architecture's testbed service level gives a receiving provider fifteen minutes from receiving a business document to transmitting the tax report for business-to-business traffic. It marks those figures as testing values, with production service levels set in the Oman Peppol Authority Specific Requirements. Either way, the self-billed invoice appears within minutes of the purchase invoice, not in a month-end batch.

What to settle with your provider before the first foreign invoice

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

1. Which of our incoming documents will you treat as imports? The test is that the sending organisation is outside Oman, not the channel the invoice used.
2. How do invoices that reach us by mail or email get to you? The architecture does not settle this; your agreement has to.
3. Will we see the self-billed invoice you create, and how will it be labelled in what you send us? Unlabelled, it looks like a duplicate.
4. Who corrects it if it is wrong, and by what route?
5. How long do you hold the four documents an import produces, and how do we retrieve them? The obligation to give them to you is stated; the duration is not.

The contract-side view of questions like these — what an Omani business should settle with an accredited provider before it presses Connect — is on what to settle with an Oman service provider before you connect.

What this page does not cover

Input VAT on an import. Whether and when an imported purchase supports a deduction, and how reverse-charge treatment interacts with any of the above, is a tax question. The architecture describes document exchange, not entitlement, so nothing is inferred here. Ask your tax adviser or the Tax Authority.

Retention periods. The architecture's retention appendix requires accredited providers to retain transmission and transaction metadata — sender and receiver identifiers, transmission timestamps, acknowledgement and delivery confirmations — and then gives the retention time as "See Oman PASR". It sets no number of its own, and one will not be guessed here.

Penalties. The architecture sets none, for this or anything else. Any figure you are shown for a late or missing import report should be traced to a Tax Authority decision, not to an architecture document.

Exports. The mirror case — an Omani seller invoicing a buyer abroad — is a different flow with the reporting on the seller's side, and it is not covered here.

Related Oman guides

• What your business needs to receive a Fawtara e-invoice in Oman — the registration, capabilities and hand-off format behind every incoming invoice.
• Correcting a self-billed invoice in Oman — what a self-billed correction must reference and carry.
• What to settle with an Oman service provider before you connect — where the bilateral arrangements this page keeps pointing at are actually agreed.
• When an Oman e-invoice is correct but never reaches the buyer — the delivery failure case, from the sender's side.
• How to check your Omani business is really registered on Oman's SMP — the lookup that proves senders can address you at all.

What to do next

Ask your provider today which of your incoming documents it classes as imports, and what it will show you when it creates a self-billed invoice from one. Both answers are short, and both are much cheaper to have before your first foreign invoice than after it.

The commercial and accreditation ground for Oman — what an accredited provider is, and what GoRoute is accredited for — is on our Oman Fawtara e-invoicing page. Recorded walkthroughs of the receiving side are on tutorials, and the document types, statuses and identifier formats behind this page are in the developer documentation. To walk your own import 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 6.5 and Figure 18 for the Peppol/non-Peppol international scenario, the statement that an import invoice cannot produce a tax data document, the self-billed PINT invoice raised to generate one, and the note that it is not sent to the original seller; section 6.6 for the receiving provider's summary of international traffic; section 6.2 for the obligation to make invoices, tax data documents and status messages available for auditing and archiving; section 9 Table 3 flows 1, 11 and 12 for the domestic, export and import document flows; section 10.1 for the three exchange choreographies; and Appendix C with C.1 for the testbed service levels and the retention pointer to the Oman Peppol Authority Specific Requirements. 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.