How to Correct or Cancel a Cleared Oman E-Invoice

An Oman e-invoice that has already been reported to the Tax Authority cannot be withdrawn, edited or replaced. There is no cancellation document in PINT OM. You correct it by issuing a second document — a credit note if the correction reduces what the buyer owes, a debit note if it increases it — and that second document must carry the original invoice's number, issue date and UUID, plus a reason code from a list of exactly five values.

This page is for a finance manager or accountant in a VAT-registered Omani business holding an invoice that has already gone. Every rule identifier below was read out of the PINT OM v1.0.1 packs GoRoute runs in production, on 7 September 2026.

Can you cancel an Oman e-invoice after it has been cleared?

No — you reverse it, and the reversal is itself an e-invoice.

Once the tax data document for an invoice has gone to the Authority, that invoice is part of the record. Nothing in the Oman document set takes it back. The four PINT OM document types are the invoice, the credit note, and the self-billed pair of the same two; a "cancellation" is not one of them.

What exists instead is a reason code on the correcting document. Rule CL-02-OM restricts the credit or debit note reason code (BTOM-032) to five values — CAN, VAT, VAL, QTY and OTH — and refuses anything else. A full cancellation is expressed as CAN: a credit note for the whole amount, referencing the invoice it cancels. On the GoRoute platform CAN is the default the renderer writes when no other code is supplied.

The pack ships those five codes without expanded labels, so the obvious readings — cancellation, VAT, value, quantity, other — are a reading rather than a citation, and the Tax Authority's published code list governs.

Why can't you just edit the invoice and send it again?

Because the identifier is computed from the content, so an edited invoice is a different invoice by construction.

Every Oman document carries a version 5 UUID — a hash-based identifier, meaning the same input always produces the same value. The Solution Reference Architecture derives it from a fixed list of the document's own fields: the seller's electronic address, the document type code, the invoice number, the issue date, the total tax amount and the total including tax. Change any of them and the UUID changes with them.

Two consequences follow, and they pull in opposite directions. Sending the identical document twice is safe: in our August 2026 production pilot on the Authority's live rails, a resubmission of an unchanged document returned the same transaction rather than creating a second one, the deterministic UUID acting as an idempotency key. Sending a changed document under the same invoice number does the opposite — a different UUID makes it a new document to the Authority, matched to nothing. You have not replaced anything; you have issued a second invoice.

One narrow mechanism does withdraw something, and it should not be mistaken for a cancellation. The tax report moves through Submit, Resubmit and Disregard states, and a Disregard withdraws a report that should no longer stand — where the buyer's access point rejected the invoice, say, so no report sits behind a document that never arrived. It is exception handling inside the reporting leg, owned by your provider.

What must an Oman credit note reference?

Four values about the invoice being corrected, all mandatory, all enforced by rules that refuse the document outright.

IBR-032-OM states it plainly: if the document type code is 381, 383 or 261, the preceding invoice reference, its issue date and its UUID must be present. IBR-023-OM adds the reason code on the same three type codes. Both are fatal, so a credit note missing any one of them reaches neither the buyer nor the Authority — it is refused at validation, before anything is sent. Two smaller rules shape the same block: ibr-sr-06 allows at most one preceding reference, so one credit note corrects one invoice, and ibr-073 requires every date written YYYY-MM-DD.

The UUID is the field that surprises people, because it looks like something you must have been given. You do not: it is derived from the original invoice's own values under a recipe fixed by the specification, so your system can compute it — which means a credit note can carry the right reference even for an invoice that never travelled over Peppol. For an invoice issued before the mandate applied, PINT OM defines a nil value, 00000000-0000-0000-0000-000000000000.

Everything else is ordinary. The customisation identifier stays urn:peppol:pint:billing-1@om-1 and the business process stays urn:peppol:bis:billing; the root becomes CreditNote and the type code element becomes cbc:CreditNoteTypeCode carrying 381. The header field by field is in the PINT OM CustomizationID reference.

One field should not be there. A payment due date (IBT-009) belongs on invoice-type documents only, never on a credit note.

When is a debit note the right document instead?

When the correction increases what the buyer owes — an undercharge, a missed line, a rate applied too low. The credit note reduces; the debit note increases. Both reference the document they correct under the same rules, because IBR-032-OM and IBR-023-OM cover 381, 383 and 261 together.

What differs is structural, and it catches implementers out. A debit note in PINT OM is an Invoice document, not a CreditNote. Rule ibr-cl-01 splits the code list in two: 383 is an accepted value of cbc:InvoiceTypeCode, 381 an accepted value of cbc:CreditNoteTypeCode. So a debit note is built on the Invoice root and judged by the invoice rule pack, while carrying a mandatory BillingReference that ordinary invoices do not have. Build it by copying your credit note and changing 381 to 383 and it fails ibr-cl-01 on the first send.

What does the five-corner flow do with a correction?

It treats it as a document in its own right, with everything that implies.

Oman's model adds the Tax Authority as a fifth corner: alongside the invoice travelling from supplier to buyer over Peppol, a tax data document derived from it goes to the Authority. A credit note is not an amendment to an earlier report — it gets the whole treatment. Its own version 5 UUID, its own tax data document with the complete credit note embedded inside, and reporting twice: once by the supplier's access point and once by the buyer's, each answered with its own status. That is also why the buyer's side cannot decline it — receiving the PINT OM invoice and credit note pair is a mandatory capability for Omani invoicing organisations, registered in the Tax Authority's central SMP. The mechanics of all five corners are in the Fawtara five-corner model explained.

We have run this on the live network rather than a test bed. In the production pilot of 17–19 August 2026 against the Authority's production infrastructure, scenario C-03 issued a credit note against a delivered invoice between two Omani taxpayers. It was delivered, and its billing reference carried the original invoice's number and its exact delivered UUID — both sides computing the same identifier independently, which is the point of the derivation.

How do you confirm the Authority accepted the correction?

Read the status on the report, not the delivery of the credit note to your customer — two events on two legs, only one of which involves the Authority.

What comes back is a Peppol message level status with three codes: AP (delivered and confirmed), AB (delivered, no confirmation) and RE (rejected, or delivery failed). On Oman transmissions the status handling is set to always send, so silence is an exception to chase rather than an outcome to interpret.

Then read it for exactly what it says. A positive status from the fifth corner means the report was well formed and accepted for processing. It is not a ruling that your tax treatment is right: the specification limits that validation to the document rules "and not for Tax compliance etc.".

Three identities are worth capturing against every correction, because they are what makes a reconciliation possible months later: the credit note's own version 5 UUID; the preceding invoice UUID it carries, which ties it to the original; and the ruleset version line, BTOM-META-001, stamped into every validation result — the only thing that answers "it validated fine in August" a year later.

A fair test of a provider, and one to apply to us: ask to see the credit note's delivery status and its tax report's status as two separate values. Collapsed into one green tick, you cannot tell a delivery problem from a reporting problem, and those have different owners.

Which mistakes get a correction refused?

These come back during integration, each traceable to the rule that fires.

• No preceding invoice UUID. The commonest: the number and date are obvious fields to map, the UUID is not. IBR-032-OM, fatal.
• A random UUID anywhere. Oman requires a version 5 UUID; most libraries return a version 4 by default. IBR-002-OM, fatal.
• A reason code that is not on the list — free text, or a plausible-looking value like RET. CL-02-OM, fatal.
• Two preceding references on one note. One correction, one invoice. ibr-sr-06, fatal.
• A debit note built on the CreditNote root. ibr-cl-01, fatal — and it fires on the type code rather than the root, so the message points somewhere unhelpful.

Reading a refusal generally — which rule set owns which identifier, and why a rule worded "should" can still stop the document — is in why Oman e-invoices get rejected. Running the same rules yourself first is in how to test an Oman e-invoice before you send it.

What this page deliberately does not cover

How a correction is treated on your VAT return. Which period a credit note falls into, and how it is declared, is a tax question we cannot source from the specifications and rule packs this page is built on. Ask your tax adviser or the Authority.

Penalties. No figure here for issuing a correction late or wrongly; we have no current source for one.

Self-billed corrections. Where the buyer issues the documents, the correcting document is a self-billed credit note, type code 261, under the self-billing customisation, with its own constraints on the transaction type. That is its own page, publishing this week.

Related Oman guides

• Why Oman e-invoices get rejected — reading a refusal, rule set by rule set.
• The PINT OM CustomizationID reference — the credit note header in full.
• Advance payments and deemed supplies — two more events an ERP built for post-audit invoicing will miss.
• The Fawtara five-corner model explained — what the Authority receives, and when.
• What format an Oman e-invoice must be in — the file itself.

What to do next

The useful exercise is not reading more rules. It is listing every place in your business that issues a credit note, a cancellation or a manual adjustment — including the ones outside the ERP — and checking that each can supply a preceding invoice number, date, UUID and reason code. That is a data-model gap, not a configuration one.

The commercial and integration ground is on our Oman Fawtara e-invoicing page, the connector walkthroughs are on tutorials, and the API surface is in the developer documentation. To walk your own correction flows against the Oman rules with our team, book a session.

Sources: the PINT OM v1.0.1 jurisdiction and UBL rule packs (2026Q2 final) as deployed in GoRoute production, read on 7 September 2026 for every rule identifier and code list here — IBR-023-OM, IBR-032-OM, IBR-002-OM, CL-02-OM, ibr-055, ibr-sr-06, ibr-cl-01, ibr-073, BTOM-META-001; the PINT OM mandatory field mapping generated from the GoRoute renderer; 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 UUID derivation, the corner model, the report states and the status codes; and GoRoute's Oman production pilot of 17–19 August 2026, scenarios B-02, C-03 and C-08. Oman's own material is published by the Tax Authority and the PINT Oman specification.