Self-Billed Invoices in Oman: How to Correct One After Clearance

When the buyer raised the invoice, the buyer also issues the correction — and it is a self-billed credit note carrying type code 261, never the 381 a supplier would use. It travels under its own customisation identifier, urn:peppol:pint:selfbilling-1@om-1, it must reference the self-billed invoice it corrects by number, issue date and UUID, and its transaction type is restricted to four values by a single fatal rule, IBR-177-OM.

This page is for a finance manager or accountant in a VAT-registered Omani business that self-bills. Every rule identifier below was read out of the PINT OM v1.0.1 self-billing rule packs GoRoute runs in production, on 8 September 2026. The general case — a supplier correcting its own invoice — is how to correct or cancel a cleared Oman e-invoice.

When does self-billing apply in Oman, and who issues the document?

Self-billing is the arrangement where the buyer raises the invoice on the supplier's behalf, usually because the buyer holds the numbers first: a contractor paid on measured work, a distributor settling on units sold, an importer accounting for a supply nobody in Oman invoiced.

In PINT OM this is not a flag on an ordinary invoice. It is a separate profile with its own two documents — the self-billed invoice, type code 389, and the self-billed credit note, type code 261 — sent under urn:peppol:pint:selfbilling-1@om-1 with the business process urn:peppol:bis:selfbilling.

The parties do not swap places. The supplier remains the AccountingSupplierParty and the buyer remains the AccountingCustomerParty; what changes is who builds and sends the file. Because the buyer is now the author, three Oman rules read the buyer's own data harder than they would on an ordinary invoice, and all three are fatal:

IBR-020-OM is the one to check first. A self-billed document is only ever issued by an Omani buyer — if the buyer sits outside Oman, this profile is not the answer to your problem.

Why is the correcting document a 261 and not a 381?

Because the accepted code list is a property of the rule pack, and the rule pack is chosen by the customisation identifier in the envelope before any rule reads the document.

Rule ibr-cl-01 sets the list, and the lists are not the same width. The self-billing packs accept exactly one value each — 389 for the invoice element, 261 for the credit note element — and 381 does not appear in the self-billing list at all. So a credit note that would validate perfectly against a supplier-issued invoice is refused the moment it is sent under a self-billing customisation. The failure is fatal: the document is stopped at validation and reaches neither the supplier nor the Tax Authority.

The field-by-field header for both self-billed documents, including the worked examples, is in the PINT OM CustomizationID reference.

There is no self-billed debit note: 383 has no place in either self-billing pack. Our reading is that an upward correction is raised as a further self-billed invoice under 389. The packs constrain which codes exist; they do not tell you how to account.

What does IBR-177-OM require of the transaction type?

That the document declares itself one of four things, and only one.

Every Oman document carries a 20-character transaction type, BTOM-001, written on the @name attribute of the type code element — twenty positions of 1 and 0, one per transaction characteristic. IBR-001-OM requires exactly that shape and nothing else.

IBR-177-OM then constrains it for self-billed documents:

If Invoice Type code (IBT-003) is Self billed credit note '261' or Self billed invoice '389' then Invoice transaction type (BTOM-001) MUST be either Self-billed Invoice/credit note (00100000000000000000) OR Invoice for import of services for RCM (00000000100000000000) OR Profit Margin Self-Invoice (00000000001000000000) OR Import of Goods (00000000000010000000).

Neighbouring rules turn "either" into "exactly one". IBR-138-OM forbids the self-billed position alongside third-party, export, import-of-services, profit-margin, profit-margin-self or import-of-goods; IBR-146-OM and IBR-147-OM say the same from the other side. IBR-149-OM separately forbids a simplified tax invoice from being self-billed, so the base type on a self-billed document is the full tax invoice.

The consequence is easy to miss: a system that stamps 10000000000000000000 — full tax invoice, no modifier — on every outgoing document produces a 261 that fails IBR-177-OM on the first send, with a message about transaction types rather than about credit notes.

How do the import-RCM, profit-margin and import-of-goods cases differ?

They differ in what else the document must carry, and each adds its own fatal rule. Nothing in the packs requires the correction to repeat the transaction type of the document it corrects, but each rule below reads the transaction type of the document in front of it — so whichever value you set, the correction must satisfy that value's conditions in its own right.

Import of services under reverse charge (00000000100000000000). The supply came from outside Oman, so IBR-160-OM requires the seller country code (IBT-040) not to be OM. This is the case that makes self-billing matter to businesses that never invoice anyone: where the seller is abroad, the receiving access point produces no Oman tax data document, and the buyer raises a self-billed document for reporting instead.

Profit margin self-invoice (00000000001000000000). The most isolated of the four — IBR-146-OM forbids combining it with summary, continuous supply, export, deemed supply, import of services, profit margin, import of goods or self-billed. Note the distinction from its neighbour: IBR-175-OM requires a preceding invoice reference and UUID on the ordinary profit margin invoice (00000000010000000000), which is a different position in the string and a different document.

Import of goods (00000000000010000000). IBR-153-OM requires the buyer identifier (IBT-046) with the scheme ICID, the Importer Customs ID. That rule reads the transaction type, not the type code, so it applies to the 261 exactly as it applied to the 389. A correction that drops the customs identifier because "it is only a credit note" is refused.

What must the self-billed credit note reference?

The same four values an ordinary credit note carries. IBR-032-OM and IBR-023-OM name 261 alongside 381 and 383, so nothing here is relaxed for self-billing:

CL-02-OM restricts the reason code to five values — CAN, VAT, VAL, QTY and OTH — and refuses anything else. The packs ship those codes without expanded labels, so the Tax Authority's own published code list governs what each means. ibr-sr-06 allows at most one preceding reference, so one self-billed credit note corrects one self-billed invoice.

The preceding document here is a 389, not a 380. That matters for the next section.

Whose UUID goes on it, and who computes it?

The seller's identity seeds it — even though you, the buyer, wrote the document. This is the single most expensive misunderstanding in a self-billing integration.

Oman uses a version 5 UUID, meaning a hash of fixed inputs rather than a random value, so that the sending access point and the receiving access point derive the same identifier independently. IBR-002-OM makes a valid version 5 UUID mandatory. The Solution Reference Architecture fixes the recipe: a fixed namespace, and seven values joined with single spaces —

1. the seller's electronic address scheme (IBT-34-1)
2. the seller's electronic address (IBT-34)
3. the invoice type code (IBT-003)
4. the document number (IBT-001)
5. the issue date (IBT-002)
6. the total tax amount (IBT-110)
7. the total amount including tax (IBT-112)

Amounts are the exact strings as written in the XML: 819.00 and 819.0 are different seeds and therefore different documents.

Two traps follow for self-billing. First, fields 1 and 2 are the seller's address, not the issuer's — a buyer that seeds the calculation with its own Peppol address produces a well-formed UUID nobody else can reproduce, and validation will not tell you, because IBR-002-OM checks only the shape. Second, the type code is in the seed, so the 261 and the 389 it corrects have different UUIDs even where every other value matches; the preceding UUID you write into BTOM-031 is the one derived with 389.

One implementation detail before your first correction: our portal's Create Invoice form has no preceding-invoice fields, so a note created there falls back to its own number with the nil UUID — structurally valid, referentially meaningless. Self-billed corrections belong on the API or CSV route, where the preceding invoice is a real field.

Can the supplier even receive it?

That is a discovery question, not a validation one, and it is answered before your document is built.

Receiving capability for the PINT OM invoice and the PINT OM credit note is the mandatory minimum for every Omani taxpayer. The self-billed invoice and self-billed credit note are optional — published in the Tax Authority's central service metadata registry only where that participant has opted in. On our platform the self-billing pair is added to a participant's registration only when the record carries that opt-in.

So a 261 addressed to a supplier who never registered the document type does not fail a rule. It fails to find a route, before any rule pack is loaded. Confirm both sides' registrations before the first correction, not during it.

How do you confirm the correction was accepted?

By reading two statuses rather than one, because a self-billed correction travels two legs.

The delivery to the supplier answers with a Peppol message level status: AP (delivered and confirmed), AB (delivered, no confirmation) or RE (rejected, or delivery failed). The report to the Tax Authority answers separately, and a positive status there means the report was well formed and accepted for processing — not that your tax treatment is right.

Capture three identities against every self-billed correction, because they are what makes a reconciliation possible a year later: the credit note's own version 5 UUID, the preceding invoice UUID it carries, and the ruleset version stamped into the validation result as BTOM-META-001.

Which mistakes get a self-billed correction refused?

Each of these is traceable to the rule that fires.

• 381 under a self-billing customisation. ibr-cl-01, fatal. The commonest, because the document is otherwise correct.
• Transaction type left as plain full tax. IBR-177-OM, fatal.
• Two of the four positions set at once — self-billed and import of goods, say. IBR-138-OM, fatal.
• Buyer country not OM. IBR-020-OM, fatal.
• Buyer VAT number missing. IBR-017-OM, fatal — and easy to miss, since on an ordinary invoice it is the seller's that is scrutinised.
• The customs identifier dropped from an import-of-goods correction. IBR-153-OM, fatal.
• A preceding UUID computed on the buyer's own address. Nothing fails. It reconciles against nothing, months later, which is worse.

Reading refusals in general — which rule set owns which identifier, and why a rule worded "should" can still stop a document — is in why Oman e-invoices get rejected.

What this page deliberately does not cover

VAT return treatment. Which period a self-billed credit note falls into, and how it is declared, is a tax question the specifications and rule packs behind this page do not answer. Ask your tax adviser or the Authority.

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

Prepayments. A prepayment invoice has its own referencing rules and its own exclusions — IBR-176-OM forbids combining prepayment with a profit margin self-invoice — and it is a separate subject from correction.

Related Oman guides

• How to correct or cancel a cleared Oman e-invoice — the same question where the supplier raised the invoice.
• The PINT OM CustomizationID reference — every customisation, profile and type code, with the self-billed headers in full.
• Why Oman e-invoices get rejected — reading a refusal, rule set by rule set.
• Advance payments and deemed supplies — two more events an ERP built for post-audit invoicing will miss.

What to do next

List every supply where your business raises the document rather than receiving it — measured work, self-billed distribution, imported services, imported goods — and for each answer three questions: which of the four transaction types it is, whether the counterparty has registered to receive self-billed documents, and whether your system can supply a preceding invoice number, date and UUID derived from the seller's address. Two of the three are usually gaps in the data model rather than settings.

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

Sources: the PINT OM v1.0.1 self-billing rule packs (2026Q2 final) as deployed in GoRoute production — selfbilling-invoice/ and selfbilling-creditnote/, read on 8 September 2026 for every rule identifier and code list quoted here: IBR-177-OM, IBR-138-OM, IBR-146-OM, IBR-147-OM, IBR-149-OM, IBR-153-OM, IBR-160-OM, IBR-175-OM, IBR-176-OM, IBR-032-OM, IBR-023-OM, IBR-017-OM, IBR-019-OM, IBR-020-OM, IBR-002-OM, IBR-001-OM, CL-02-OM, ibr-cl-01, ibr-sr-06, ibr-055, BTOM-META-001; the PINT OM mandatory field mapping generated from the GoRoute platform code for the preceding-invoice and transaction-type behaviour; and 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 and the status codes. Oman's own material is published by the Tax Authority and the PINT Oman specification.