When an Oman E-Invoice Is Correct but Never Reaches the Buyer

An Oman e-invoice that the Tax Authority accepted but the buyer never received is a delivery problem, not a document problem — and the fix is neither a credit note nor a new invoice. The document stands. What you repair is the transmission, and, separately, the tax report, which travels its own leg to the Authority and carries its own three states: Submit, Resubmit and Disregard.

This page is for a finance or integration lead in a VAT-registered Omani business looking at an invoice that validated, reported, and did not arrive. It is written from the OpenPeppol testbed's own description of the Oman reporting flow, the Oman Solution Reference Architecture, and GoRoute's Oman production pilot of 17–19 August 2026. Where the document itself is wrong, the instrument is a credit note: how to correct or cancel a cleared Oman e-invoice.

Should you issue a credit note when an invoice fails to arrive?

No. A credit note corrects a document that is wrong, and this document is right.

Oman restricts the credit or debit note reason code to five values — CAN, VAT, VAL, QTY and OTH — under rule CL-02-OM, and none of them describes non-delivery. Issuing one anyway does real damage: a credit note is a document in its own right, with its own identifier, its own tax report and its own status. You end up with two documents and two reports for one supply.

The genuinely different case is an invoice the buyer's side refused on validation. That document never became valid, so nothing about it is deliverable, and the fix is in the file: why Oman e-invoices get rejected.

Why is delivery a separate leg from reporting?

Because two documents leave your access point, to two different places, at the same time.

Oman's model puts the Tax Authority at a fifth corner. Alongside the invoice travelling to the buyer's access point over Peppol, a tax data document derived from it goes to the Authority's access point. OpenPeppol's own environment description for the Oman test suite says the two are "submitted in parallel to two different endpoints", each validated separately and each answered with its own status, and adds the sentence that matters here: "Each C3, C5 AP behaves independently but in coordination."

The consequence is the point of this page: an invoice that never reached your customer has in all likelihood already been reported to the Authority, correctly. The five corners and what each one receives are in the Fawtara five-corner model explained.

What happens to the report when the buyer's side cannot be reached?

It goes anyway. This is stated rather than implied: the architecture's exception handling for the sending access point says that where the buyer's access point is not reachable, the sender retries the delivery and submits the tax report regardless.

That is not a tolerance, it is a deadline. Oman's service levels give the report fifteen minutes to reach the Authority for business-to-business and government transactions, and thirty minutes for consumer transactions, timed from the moment the document is validated at the sending side or received at the buyer's side. Any design that waits for the buyer to confirm receipt before reporting will miss those limits on the first bad afternoon — and it will miss them on the days the reporting matters most.

One note on the numbers, because two published figures differ. The architecture's service-level annexe sets fifteen minutes for the status message back to the sender; the testbed's accreditation criteria allow up to twenty. They measure different things — an operating commitment and a test pass mark — and the tighter one is the one to build to.

What are Submit, Resubmit and Disregard?

They are the three values of the document type code on the tax data document, and they are the only three.

Two details save an integration a week each.

The published list is S, R, D and nothing else. An earlier draft circulated a four-value list — Send, Receive, Withdraw, Full — and W and F are no longer valid codes. The current Oman tax-report rule file accepts the three letters above and rejects everything else, so a system built against the draft fails at validation rather than at the Authority.

A correction is not a new kind of document. It is another tax data document for the same invoice, carrying a different code. There is no "prior report" field, because the Authority correlates the correction to the earlier report through the invoice reference the report already carries. An integration hunting for somewhere to put the identifier of the report being corrected is hunting for a field that does not exist.

When is a Resubmit right, and when is a Disregard?

The trigger is which leg the rejection came back on — not how serious the problem looks from your side.

• A rejection on the reporting leg → Resubmit. The Authority refused the report itself: a malformed field, a reference that does not resolve, a rule the report breaks. The invoice is fine. Correct the report and send it again as an R.
• A rejection on the invoice leg → Disregard. The buyer's access point refused the invoice, or could not be reached at all. The report is now describing a document that did not land, so it is withdrawn with a D.
• No answer at all inside the service window → neither. That is not a correction. Check the Authority's status for the report you sent and retry the original Submit until a status comes back. Sending an R for a report that may never have arrived creates the ambiguity you were trying to resolve.

One safeguard belongs in every implementation, including ours. A Resubmit or Disregard that is itself refused is not automatically corrected again. The architecture makes that a manual exception for the service provider to resolve, and the reason is plain: an automatic correction that fires on its own rejection is a loop, aimed at a tax authority.

Does a Disregard cancel the invoice?

No, and this is the line worth holding in a meeting.

A Disregard withdraws a report. It does nothing to the invoice. If the invoice was validly issued and validly delivered, your customer still holds it, still owes the money, and the supply still happened. Withdrawing the report of a document that stands leaves a real supply unreported — a worse position than the one you started in.

So a voluntary cancellation of a clean, already-accepted invoice is not a report-state case. That is a credit note carrying reason code CAN, under the ordinary correction rules, with the full field list on the corrections page. Where the buyer raised the original document, the correcting document is a self-billed credit note instead — see correcting a self-billed invoice in Oman — and where the document was a deposit, the references it must carry are different again, in correcting a cleared Oman prepayment invoice.

What if the buyer is not on the network at all?

Then there is nothing to deliver, and no failure to fix.

Oman anticipates this directly. Where the receiver is not a Peppol participant, the invoice is addressed to a substitute participant identifier and the tax report is the reporting channel: one for deemed supplies, one for exports where the buyer is not registered on Peppol, one for an international buyer outside Oman's rules, and one for a domestic buyer not on Peppol, which includes consumers.

Consumer invoices are the clearest case, because they are not exchanged over Peppol at all — their channels are the human-readable receipt with its QR code, and the tax report. Our August 2026 production pilot ran exactly that: a simplified consumer receipt addressed to the substitute participant was generated and held, never dispatched, with zero network sends confirmed in the transport logs. Nothing failed; nothing was meant to be sent.

A different failure looks identical from a dashboard. A buyer who is a Peppol participant but never registered to receive the document type you are sending fails at discovery, before any validation rule loads. Retrying will not help. Confirm both sides' registrations before the first exchange, not during it.

How do you tell a delivery failure from a rejection?

By reading the status, and then by reading the detail underneath it, because one of the codes covers two different events.

The status that comes back is a Peppol message level status with three values: AP (delivered and confirmed), AB (delivered, no confirmation) and RE (rejected, or delivery failed). That last code is the ambiguous one — a document the buyer's system examined and refused and a document that never arrived both return RE, and they have different owners. The error detail is what separates them, so a provider that collapses the status into a red tick has thrown away what you need.

On Oman transmissions the status handling is set to always send, verified on every send in our pilot's scenario C-07, so silence is an exception to chase rather than an outcome to interpret.

The fair question to ask a provider, including us: show me the delivery status and the report status as two separate values. Collapsed into one, you cannot tell a delivery problem from a reporting problem, and only one of those is yours to fix.

Is it safe to send the same invoice again?

Yes — and it does not create a second document, which is the part people do not expect.

Every Oman document carries a version 5 UUID, computed from the document's own content, so the same content always produces the same identifier. In the production pilot's scenario C-08, a resubmission of an unchanged document returned the same transaction rather than creating a second one — the deterministic identifier acting as an idempotency key, exactly as the specification intends.

The corollary is the trap. Change anything to force the document through — a new number, a fresh issue date, a rounded total — and the identifier changes with it. You have not resent an invoice; you have issued a new one, matched to nothing.

What a retry ladder should look like is in the same pilot. Scenario C-09 exercised a delivery failure deliberately: three retries, an honest retrying → failed lifecycle rather than a silent success, and the full error preserved. A pipeline that swallows the error and shows a green tick is the one that produces the invoice nobody knew was missing.

What the specifications do not settle

Two gaps, stated as gaps.

Reporting to the Authority is not open for production yet. In our 17–19 August 2026 pilot on the Authority's live rails, every tax data document was generated and held with its original issue time preserved, and the ten reporting scenarios are staged pending the Authority opening that leg. The three states above are implemented and tested against the specification and the testbed; they have not yet been exercised end to end against the Authority's production reporting service, by us or by anyone.

What comes back when the Authority marks an earlier report disregarded is not described. The lifecycle says the older report is marked disregarded; it does not say whether the reporter is told, beyond the status returned on the correcting report itself. Build so your own record is the authority for which report currently stands.

Which mistakes turn a delivery problem into a tax problem?

• A credit note issued for non-delivery. Two documents, two reports, one supply.
• A "fixed" invoice with a new number sent to force delivery. A different identifier, so a second invoice, matched to nothing.
• A Resubmit sent because no status came back. Retry the Submit; a resubmission of a report that may never have arrived is worse than waiting.
• A Disregard used as a cancellation. It withdraws the report of a document that still stands, leaving a real supply unreported.
• Reporting held until delivery succeeds. Breaches the fifteen-minute window by design.
• A correction TDD auto-corrected on its own rejection. A loop, aimed at a tax authority.

What this page deliberately does not cover

Validation failures. A document refused on the rules never became deliverable: why Oman e-invoices get rejected, and how to test an Oman e-invoice before sending.

Credit notes and their field list. Covered in full on the corrections page, with the self-billed and prepayment variants on their own pages.

VAT treatment and penalties. Which period an adjustment falls into, and what a late or missing report costs, are tax questions the specifications behind this page do not answer. Ask your tax adviser or the Tax Authority.

Related Oman guides

• How to correct or cancel a cleared Oman e-invoice — the instrument for a document that is actually wrong.
• Correcting a self-billed invoice in Oman — the same question where the buyer raised the document.
• Correcting a cleared Oman prepayment invoice — what a deposit adds to the referencing rules.
• The Fawtara five-corner model explained — the two legs this page separates, drawn.
• Inside the Oman Tax Data Document — the report itself, field by field.

What to do next

One exercise is worth more than the rest. Take a week of outgoing invoices and ask your system two questions per document: did the buyer's side confirm it, and did the Authority confirm the report. If those answers live in one field, you cannot yet tell a delivery problem from a reporting one — and that is the gap to close before your wave date, not after it.

The commercial and integration ground is on our Oman Fawtara e-invoicing page, the connector walkthroughs are on tutorials, and the delivery and reporting statuses this page depends on are in the developer documentation. To walk your own delivery and reporting exceptions against the Oman rules with our team, book a session.

Sources: the OpenPeppol PINT OM Billing & OM TDD (Tax Reporting) Environment Description v1.0 of 12 June 2026 and Testing User Guide v1.0 of 17 June 2026, for the parallel invoice and report legs, the independent statuses and the fifteen and twenty minute test criteria; the Oman – Solution Reference Architecture (v1.0.1 of 22 May 2026 and v1.0.3 of 27 July 2026, OpenPeppol AISBL with the Oman Tax Authority) for the report lifecycle, the exception handling on both access points, the service-level annexe, the substitute participant identifiers and the version 5 UUID derivation; the PINT OM TDD Process v1.0.0 document type code list as deployed in GoRoute production, read on 10 September 2026; rule CL-02-OM from the PINT OM v1.0.1 jurisdiction rule pack; and GoRoute's Oman production pilot of 17–19 August 2026, scenarios C-07, C-08, C-09 and C-10 and its staged Stage D. Oman's own material is published by the Tax Authority and the PINT Oman specification.