Advance Payments and Deemed Supplies: The Two Oman E-Invoicing Triggers Your ERP Will Miss

Which events require an Oman e-invoice, and which will your ERP miss?

Under the amended Article 143, an electronic tax invoice is required on four events. Two of them are routinely absent from ERP configurations built for paper: receiving consideration before the date of supply, and deemed supplies. Both are documents your system does not create today, and neither is a formatting change.

• Receiving consideration, wholly or partly, before the date of supply — deposits, prepayments, staged payments, retainers
• Deemed supplies — which in most paper processes produce no invoice at all

Both become mandatory on your wave date: 1 April 2027 above OMR 5m, 1 October 2027 below. Both are changes to when your system creates a document, which is a far deeper piece of configuration work than adding a new output format.

They are also both visible in the technical specification, which is what makes this page more than a restatement of the law. Oman's e-invoice carries an explicit transaction-type declaration, the validation rules that run in production check it, and prepayments and deemed supplies each have their own position, their own combination rules and — in the prepayment case — their own mandatory cross-reference. The rest of this page works through what that means for the configuration.

Why do these two triggers bite harder than the others?

Because the other two describe events your ERP already invoices. Ordinary supplies and the Regulations' catch-all cover documents you produce today, so you are changing the format of something that already exists. For deposits and deemed supplies you are producing a document that does not currently exist anywhere in your process.

That distinction decides how long the project takes. Re-formatting output is a connector task: the data is already assembled, and something new renders it. Creating a document at a new point in the process is not. It touches order management, the receipts workflow, revenue recognition, the numbering sequence and the VAT return reconciliation. It needs analysis, configuration and testing, and it needs finance and IT in the same room, because neither can answer the questions alone.

It is also the kind of change that fails quietly. A format error is caught by validation on the first document. A missing trigger produces no error at all — the system simply never creates the invoice, the receipt goes out as it always has, and nothing complains until the difference between documents issued and VAT declared is reconciled. That is why both of these belong on a project plan rather than in a backlog.

How does an Oman e-invoice declare that it is a prepayment or a deemed supply?

Through a twenty-character transaction-type flag on the document. Each position marks one transaction type. The validation rules that run in production require exactly twenty characters of ones and zeros with at least one set, and require either the first or the second position — full tax invoice, or simplified tax invoice — to be set on every document.

The rule pack is explicit about the structure. ALIGNED-IBRP-000-OM requires the transaction type to be present and to be a twenty-character bitmap of ones and zeros with at least one marking an active type. IBR-001-OM repeats the character constraint. IBR-043-OM requires the first or second position always to be set. Every one of these is flagged fatal, meaning the document does not pass validation and therefore is not issued.

The consequence for design is that the special types are layered on a base type rather than replacing it. A prepayment invoice is a full or simplified tax invoice that also carries the prepayment flag. A deemed supply invoice is a full or simplified tax invoice that also carries the deemed supply flag. If your ERP models these as separate document types with their own behaviour, the mapping to Oman's model is a translation step you have to write, not a lookup.

The positions matter, and they are visible in the examples that ship with the production validator:

That last row is worth pausing on. The prepayment example in the production rule set carries UBL invoice type code 386 — the standard code for a prepayment invoice — while the deemed supply example carries 380, the ordinary commercial invoice code. So a prepayment is signalled twice: once in the international type code and once in Oman's own transaction-type flag. Getting one right and the other wrong is an easy defect to introduce and a cheap one to test for.

Which transaction types cannot be combined?

The rule pack forbids specific combinations outright, each as a fatal error. A prepayment invoice cannot also be a summary invoice, a deemed supply or a profit-margin self-invoice. A deemed supply cannot also be a continuous supply, an export, a profit-margin invoice or a profit-margin self-invoice. These are validation failures, not warnings.

The two rules that matter here are IBR-176-OM and IBR-143-OM, and both are worth reading as design constraints rather than as error messages.

IBR-176-OM prevents a prepayment being folded into a summary invoice. That is a real pattern: a business that bills a customer monthly in arrears and takes deposits during the month might reasonably want one document. Oman's rules do not allow it. The deposit is its own invoice, on its own trigger, at the moment consideration is received.

IBR-143-OM prevents a deemed supply being combined with a continuous supply or an export. Again, that is a real pattern rather than a theoretical one — a business writing off stock that was destined for export, or treating a continuously supplied service as partly own-use, has to separate the two events into two documents.

The general lesson is that Oman's model expects one document per event, and resists attempts to combine events into a single tidy invoice. Any ERP design that reduces document count by merging triggers will meet one of these rules eventually, and it will meet it as a fatal validation error rather than as a review comment.

What must the final invoice carry once a deposit has been invoiced?

Three things together, or the document is rejected. If the paid amount appears on the final invoice, rule IBR-058-OM requires the prepayment invoice number and the prepayment invoice unique identifier to be present as well. Showing a deposit against a final invoice is therefore not a calculation; it is a reference to a specific earlier document.

This is the single most consequential rule on this page for ERP design, because of what it implies about data retention rather than about tax.

The prepayment invoice's number is straightforward: your system issued it, and it should still have it. The unique identifier is not. In Oman's model the invoice identifier is a version 5 UUID — a hash-based identifier computed from named invoice fields rather than a random one — derived from the seller identifier and its scheme, the invoice type code, the invoice number, the invoice date, the invoice total tax amount and the invoice total amount including tax. The Solution Reference Architecture states the property plainly: the same content invoice produces the same identifier, and if the content changes a new identifier is determined.

Three practical consequences follow.

Your ERP has to store the link, not recreate it. In principle the identifier is recomputable from the deposit invoice's own fields, because it is deterministic. In practice, a system that recomputes it at final-invoice time is one rounding difference away from computing a different value than the one that was actually reported. Store what was issued.

Amending a deposit invoice invalidates the reference. Change the amount, the date or the tax on the prepayment invoice and its identifier changes. Any final invoice already pointing at the old value is pointing at a document that, as far as the identifier is concerned, no longer exists. Corrections to deposit invoices need a defined path — a credit note and a new document, not an in-place edit.

Partial and multi-stage prepayments need a decision. A project billed in four stages produces four deposit invoices before the final one. The rule requires the prepayment invoice number and identifier where a paid amount is present; deciding how your system represents several of them, and testing that representation against the validator, is work to do before your wave date rather than in the first week after it.

What breaks in the deposit sequence you run today?

The common pattern is a receipt at deposit stage and a tax invoice at delivery, with VAT accounted at delivery. From your wave date the deposit itself requires an electronic tax invoice for the consideration received. The receipt is no longer sufficient, and the VAT point moves earlier for that portion of the consideration.

The sequence today usually looks like this:

1. Customer pays a 30% deposit → receipt issued
2. Goods delivered three months later → tax invoice for the full amount
3. VAT accounted at delivery

From your wave date, step 1 requires an electronic tax invoice for the consideration received. Three consequences are worth planning for.

Your invoice count rises. Every staged payment becomes a document. A project business billing in four stages issues four tax invoices where it previously issued one, plus the final settlement. That affects volume-based pricing, archival, any manual review step in the chain, and — because each document has to reach the Authority within minutes of validation — the load profile of your integration.

Double taxation becomes a live risk. If the deposit was invoiced with VAT and the final invoice is raised for the gross amount without netting the prepayment, you have declared output VAT twice. This is the single most common defect we would expect to see in the first months of a prepayment-heavy rollout, and it is the specific thing to test in sandbox. The rule described in the previous section is what makes the netting auditable: a paid amount without the two references is rejected, so the system cannot show a net position without saying which document it is netting against.

Cancellations need a credit path. A cancelled order that was invoiced at deposit stage now needs a credit note, not a quiet refund of a receipt. The credit note runs through the same validation rules — the Oman credit note pack carries the same 154 assertions as the invoice pack, including IBR-058-OM and IBR-176-OM — so a credit note against a prepayment has to satisfy the same referencing discipline as the invoice did.

What is a deemed supply, and why does it have no document today?

A deemed supply is a transaction treated as a supply for VAT even though it is not an ordinary sale — typically goods or services taken for personal or non-business use. In most finance functions today it is a journal entry and a line on the VAT return. There is no invoice, no number, and nothing to submit.

Article 143 spells this out on the ordinary-supplies limb as well, covering supplies "to a taxable person allocating the supplies for personal use". From your wave date a deemed supply needs a document with a unique number, in the approved electronic format, retained like any other.

Practically that means deciding three things your ERP will not decide for you:

• Who the document is addressed to. There is often no external counterparty at all.
• What triggers its creation. If the only trigger today is a quarter-end journal, the document will be quarterly and late.
• Where it sits in your numbering sequence. One unique number per invoice, across every issuing point, including this new one.

Who is the buyer on a deemed supply that must not be shared?

Oman's architecture answers this directly. Where the transaction type is a business-to-business deemed supply and the invoice must not be shared with the buyer, the buyer electronic address is a fixed substitute value — 997770000096 under scheme 0248 — so the transaction is still reported to the Authority rather than blocked. Consumer deemed supplies use the business-to-consumer substitute instead.

This is the part of the design that most people do not expect, and it resolves the "who is the buyer" question above rather elegantly. The Solution Reference Architecture defines a set of substitute participant identifiers for exactly the cases where a real, network-reachable buyer does not exist. The deemed supply case is the first entry in that table.

Two things follow from it that are easy to get wrong.

A substitute is a field value, not an address. It goes in the document so the transaction can be reported. It is not somewhere the invoice gets delivered, and the specification is explicit that where the buyer is not reachable on the network the sending access point generates the identifier and exchanges the tax data document with the Authority's access point, and does not exchange the invoice with a receiving access point. The reporting happens; the delivery does not.

Consumer deemed supplies take the consumer substitute. The architecture notes this specifically: a deemed supply in a business-to-consumer transaction uses the fixed value for consumer transactions, 997770000099, rather than the deemed-supply one. And where that consumer value is used, a further rule — IBR-173-OM — requires the seller unique identifier to be present, which is the value carried in the QR code on the readable invoice. Two substitutes, two different downstream requirements.

If your process for deemed supplies is currently "post a journal at quarter end", none of this is configured anywhere, and none of it is a switch. It is a document type, a trigger, a numbering rule and a party-identification rule, and it needs the same treatment as any other new document in the system.

Do these rules apply to consumer sales as well?

Yes. Article 143 covers supplies to non-taxable persons, and Article 146 paragraph two puts simplified invoices on the same timeframes, so a retail deposit is in scope on the same date as a business one. The specification reflects this: the prepayment and deemed supply examples in the production rule set are both built on the simplified base type.

That has one operational consequence worth naming. Consumer documents run on a different reporting clock — Oman's service levels give a consumer tax data document 30 minutes to reach the Authority against 15 for a business one, and the architecture notes that the supplier should send the invoice to their access point within 24 hours. A deposit taken at a retail counter is therefore inside the same reporting machinery as an invoice raised in the finance system, and any point-of-sale estate that batches its uploads overnight needs looking at with that in mind.

The simplified invoice and point-of-sale page covers the consumer side in full.

What should you change, and in what order?

Start by listing the events, not the documents. Every point where money arrives before a supply, and every deemed supply currently handled as a return adjustment. Those two lists are the scope. Everything after that — numbering, netting rules, party identification, testing — follows from knowing which events your system has to start recognising.

In order:

1. List every point where money arrives before a supply. Deposits, retainers, milestone billing, subscriptions billed in advance, customer credit on account. Include the ones outside the ERP: the sales team's proforma process, the online checkout, the branch that takes cash deposits.
2. List every deemed supply you currently handle as a return adjustment. If it only exists in a spreadsheet at quarter end, it needs an owner and a trigger.
3. Decide the netting rule for prepayments and write it down before configuring anything. This is where double-taxed VAT comes from, and the rule has to survive partial deposits, multiple deposits and cancellations.
4. Decide how the deposit invoice's number and identifier are stored and how the final invoice retrieves them. This is the requirement of IBR-058-OM, and it is a data-model decision rather than a configuration flag.
5. Extend your numbering scheme. One unique number per invoice, across every issuing point, including the new documents.
6. Decide party identification for deemed supplies, including which substitute applies for business and consumer cases.
7. Test both flows end to end in a sandbox, including a cancellation and a credit note against a deposit. Not the happy path. Testing an Oman e-invoice before sending covers how to run documents through validation ahead of go-live.
8. Reconcile a full period — the documents you issued against the VAT you declared — before your wave date, not after.

Where does this sit in the wider mandate?

These are the transaction-level triggers: which events oblige you to create a document. The other parts of the same decision cover which wave you are in, what a simplified invoice must carry, and the security and continuity obligations on the systems that issue all of it. They are separate pieces of work with one shared deadline.

Simplified and B2C invoices run on the same clock, and Article 143 bis 1 places security and continuity obligations on your systems rather than your documents. For the exchange mechanics underneath all of it, see the Fawtara five-corner model and the Tax Data Document deep dive. For what the finished document has to look like, see the Oman e-invoice format, and for the integration surface itself, connecting your own software to Fawtara.

If you want the ERP side scoped rather than guessed, the Peppol API documentation covers the integration surface, the Oman page covers the rules, and you can book a session to walk your prepayment flows with our Oman team before you configure anything.

Sources

• Decision of the Chairman of the Tax Authority No. 189/2026, amended Article 143 and Article 146
• PINT OM v1.0.1 validation rule packs as deployed in GoRoute production — PINT Oman E-Invoice Validation Rules (IBR-OM), rules ALIGNED-IBRP-000-OM, IBR-001-OM, IBR-043-OM, IBR-058-OM, IBR-143-OM, IBR-173-OM and IBR-176-OM, and the Oman example document set
• Oman Solution Reference Architecture v1.0.1, 22 May 2026, OpenPeppol AISBL — sections 4.3, 5.5, 10.2.3 and 10.3.1
• Oman Peppol Authority Specific Requirements v1.0 RC, OpenPeppol AISBL — Annexure A
• PINT Oman specification and the Oman Tax Data Document specification
• Oman Tax Authority and the Fawtara portal