Correcting a Cleared Oman Prepayment Invoice: What the Credit Note Must Carry

A deposit invoice that Fawtara has already cleared cannot be withdrawn. You correct it the same way you correct any other Oman e-invoice — with a credit note, type code 381, carrying the deposit invoice's number, issue date and UUID plus a reason code. What is different about a deposit is everything around that note: the prepayment flag on the transaction type pulls in a second fatal rule, the references it demands live in two different places depending on which rule pack is running, and any final invoice that has already netted the deposit is now quoting an identifier for a document you have just reversed.

This page is for a finance manager or accountant in a VAT-registered Omani business that takes deposits. Every rule identifier below was read on 9 September 2026 out of the PINT OM v1.0.1 packs GoRoute runs, and the pilot evidence is from our Oman production pilot of 17–19 August 2026.

Is there a special credit note for a prepayment invoice in Oman?

No — and the code list settles it. A prepayment invoice carries UBL type code 386, but rule ibr-cl-01 accepts only 81, 83, 381, 396 and 532 as credit note type codes. 386 is an invoice-side code and is not in that list. So a deposit invoice is a 386, and the document that corrects it is an ordinary 381 credit note built on the CreditNote root.

Everything the general correction rules demand applies unchanged: IBR-032-OM makes the preceding invoice's number, issue date and UUID mandatory, and IBR-023-OM adds a reason code restricted by CL-02-OM to CAN, VAT, VAL, QTY and OTH. All of that is worked through field by field in how to correct or cancel a cleared Oman e-invoice, and this page does not repeat it. What follows is only what a deposit adds.

What does IBR-058-OM actually test?

IBR-058-OM is flagged fatal and its message reads: "Prepayment invoice number (BTOM-027) and Prepayment invoice UUID (BTOM-014) must be provided if Paid amount (IBT-180) is present."

Read the test rather than the message, because they do not say the same thing. The deployed assertion fires on the transaction-type flag, not on the paid amount. Oman's twenty-character transaction-type bitmap (BTOM-001) marks a prepayment at position 15, and the rule reads, in effect: if this document is flagged as a prepayment, then a prepaid amount must exist, and both prepayment references must exist. The message describes the paid amount as the trigger; the code makes the paid amount one of the three things being demanded.

That distinction is not academic: a document flagged as a prepayment with no paid amount fails, which is the opposite of what the message implies. When a rule's wording and its test diverge, the test is what refuses your document.

Where do BTOM-027 and BTOM-014 go?

In two places, and you should write both.

The v1.0.1 jurisdiction pack tests for cac:OriginatorDocumentReference carrying a child cbc:ID and cbc:UUID, alongside cac:LegalMonetaryTotal/cbc:PrepaidAmount. The 2026Q2-final pack — the one running in the live validator during our production pilot — tests instead for cac:AdditionalDocumentReference whose cbc:DocumentTypeCode is PDR, carrying the same two values.

We found this the hard way. In the pilot's Stage B, scenario B-27 was a prepayment invoice built to match the Tax Authority's own published Prepayment.xml sample, which carries the references as OriginatorDocumentReference only. The live validator returned INVALID [IBR-058-OM]. The document was corrected the same day to emit the AdditionalDocumentReference PDR pair as well, redeployed, and re-verified live: valid.

Two things follow. The published sample does not pass the current rule, which we raised with the Authority as observation F-4 in the pilot report; that is a clarification for them to make rather than an interpretation for us to choose. And in the meantime, carry both blocks with identical values — neither pack objects to the form it does not test, so writing both is the only construction that passes both, and it costs six lines of XML.

Does the credit note itself need the prepayment flag?

Only if you can populate what the flag then demands — and the instinct to copy it across is where this goes wrong.

The credit note rule pack contains its own copy of IBR-058-OM, keyed on the credit note's own transaction-type bitmap. Copy the deposit invoice's BTOM-001 onto the correcting note, as an ERP naturally would, and position 15 comes with it. The note is now a prepayment document in the validator's eyes, and it must itself carry a prepaid amount and both prepayment reference blocks or it is refused before it reaches anyone.

IBR-176-OM travels with it too: a document flagged as a prepayment may not also be flagged as a summary invoice, a deemed supply or a profit-margin self-invoice. And IBR-043-OM still requires position 1 or 2 — full or simplified tax invoice — to be set on the note, because the special types layer on a base type rather than replacing it.

The clean design is to decide the credit note's transaction type deliberately rather than inheriting it. If the note is flagged as a prepayment, the prepayment block goes on it. If it is not, the note is an ordinary 381 and the only references it carries are the preceding-invoice ones. Either is valid. Copying half of one into the other is what fails.

Can the reversal be a negative amount?

No. Rule IBR-137-OM requires every amount and quantity on the document to be zero or positive, and it names the prepaid amount, the payable amount, the tax amount and the credited quantity among the fields it checks. The reduction is expressed by the document being a credit note; it is never expressed by a minus sign inside one.

Two arithmetic rules constrain the same block and are worth checking in your mapping before you meet them at validation. ibr-co-16 requires the amount due for payment to equal the total with tax minus the paid amount plus any rounding, so a prepaid amount you write for reference rather than for arithmetic will not balance. ibr-093 requires that where a paid amount appears at the payment level, the total paid amount exists in the legal monetary total.

What happens to the final invoice that already netted the deposit?

It becomes wrong as well, and the two corrections have an order.

The deposit invoice's identifier is a version 5 UUID — computed from the document's own content under a recipe fixed by the Solution Reference Architecture, so the same content always produces the same value and changed content produces a different one. That identifier is exactly what the final invoice quotes as BTOM-014 when it nets the deposit off. Credit the deposit and re-issue it, and the replacement carries a new identifier, while the final invoice still points at the old one.

Nothing in the rule packs detects this. Each document passes validation on its own terms: the final invoice carries a well-formed number and a well-formed UUID, and the validator has no way to know that the document behind them has been reversed. It surfaces at reconciliation, or in an audit, which is late. The control is procedural — a deposit invoice that has been netted cannot be credited as a single-document decision, and whoever raises the credit note needs to be able to see which final invoice, if any, already quoted it.

The wider design work this implies — what your ERP must store, and why recomputing the identifier at final-invoice time is not the same as storing what was issued — is in advance payments and deemed supplies, which covers the event that creates the deposit invoice in the first place.

What the rules do not settle

Two questions come up on every prepayment-heavy rollout and the packs do not answer either. Both are worth testing against the validator rather than reasoning about.

Several deposits against one final invoice. ibr-sr-06 allows at most one preceding invoice reference on a document, so one credit note corrects one deposit invoice. The prepayment reference block is a different block, and the packs do not state how a final invoice netting four staged deposits should represent all four. Run your intended representation through validation before your wave date.

Partial credits. Crediting part of a deposit is not forbidden by anything above, but nothing in the packs ties the credited amount to the original, so the arithmetic is yours to get right and yours to reconcile.

Which mistakes get a prepayment correction refused?

Each of these is fatal, and each names the rule that fires:

• The PDR block missing, because the document was built from the published sample. IBR-058-OM.
• The prepayment flag copied onto the credit note without the prepaid amount and references that come with it. IBR-058-OM again, this time in the credit note pack.
• A negative prepaid amount written to express the reversal. IBR-137-OM.
• A prepayment flagged alongside a summary invoice or deemed supply. IBR-176-OM.
• A reason code that is not CAN, VAT, VAL, QTY or OTH. CL-02-OM.
• 386 used as a credit note type code. ibr-cl-01 — it is on the invoice list only.

Reading a refusal in general is in why Oman e-invoices get rejected, and running the same packs over your own document before you send it is in how to test an Oman e-invoice before sending.

What this page deliberately does not cover

The VAT return treatment. Which period a credit note against a deposit falls into, and how the adjustment is declared, is a tax question the specifications and rule packs do not answer. Ask your tax adviser or the Tax Authority.

Refunding the money, and penalties. Returning the deposit to the customer is a payment rather than a document, and nothing above governs it. On penalties we have no current source for a figure, so there is none here.

Self-billed deposits. Where the buyer raises the documents, the correcting document is a self-billed credit note under a different customisation — see correcting a self-billed invoice in Oman.

Related Oman guides

• How to correct or cancel a cleared Oman e-invoice — the general referencing rules this page builds on.
• Advance payments and deemed supplies — when a deposit invoice must be raised at all.
• Correcting a self-billed invoice in Oman — the same problem when the buyer issues the documents.
• The Fawtara five-corner model explained — what the Authority receives, and when.

What to do next

The useful exercise is one query against your own data: every final invoice that carries a prepayment reference, and every deposit invoice that has been credited. If those two lists intersect anywhere, you have final invoices quoting reversed documents, and that is a reconciliation problem you find now or an auditor finds later.

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 deposit and correction flows against the Oman rules with our team, book a session.

Sources: the PINT OM v1.0.1 jurisdiction and UBL rule packs as deployed in GoRoute production, invoice and credit note, read on 9 September 2026 for every rule identifier here — IBR-058-OM, IBR-137-OM, IBR-176-OM, IBR-043-OM, IBR-032-OM, IBR-023-OM, CL-02-OM, ibr-cl-01, ibr-sr-06, ibr-co-16, ibr-093; the PINT OM mandatory field mapping generated from the GoRoute renderer for BTOM-027 and BTOM-014; the Oman Solution Reference Architecture (v1.0.1 of 22 May 2026, OpenPeppol AISBL with the Oman Tax Authority) §10.2.3 for the version 5 UUID derivation; and GoRoute's Oman production pilot of 17–19 August 2026, scenario B-27 and observation F-4. Oman's own material is published by the Tax Authority and the PINT Oman specification.