An invoice raised in an Oracle APEX application does not travel to Oman’s Tax Authority by itself. APEX raises the document as it always did. The data then leaves APEX as structured data, is validated against Oman’s PINT OM rules, goes to the buyer over Peppol, and is reported to the Authority separately.
The recording below follows one transaction along that whole path in 8 minutes 25 seconds — captured in APEX, validated, delivered, reported, and visible afterwards in the APEX table, the GoRoute transactions dashboard and the printable receipt. The same walkthrough is written out further down this page, stage by stage, if you would rather read it than watch it. The regulatory version of the same story, with the rule identifiers, is in Oman e-invoicing from Oracle applications.
Below is the recording written out, stage by stage and in its own order, so this page answers what the integration does without anyone pressing play. Where a detail comes from Oman’s published rule packs or from the Oracle applications guide rather than from the video, it says so. Rule identifiers and counts were read from the Oman rule packs GoRoute ships, on 22 August 2026.
Oracle is not one product, and the difference decides the shape of the whole job. Oracle Fusion Cloud ERP, E-Business Suite, NetSuite and applications your own team built in Oracle APEX are four different starting points. Treating them as one is how an integration estimate goes wrong in week one.
This recording is the APEX case: a custom application at a service counter, the kind a business writes for itself because no packaged product fits how it trades. That is also the harder case, because a packaged system localised for Oman already has somewhere to put Oman’s fields and an application you wrote does not. What exists here is the recording; how a connection would be built, packaged and supported for your own Oracle product and version is a scoping conversation, and the answer to it should arrive in writing.
Nothing new, from the operator’s side. The transaction is entered in the APEX application exactly as it was before — same screen, same fields, no second data entry and no compliance step for a person to remember. What changes is what happens to the record afterwards: it is picked up as it is written, converted to structured data and sent on. That is the difference between an integration people adopt and one they route around, and it is why the recording spends its opening minutes on an ordinary counter transaction rather than on a configuration screen.
Four, and in a custom application they are usually columns nobody has added yet. Rule IBR-003-OM requires the seller, buyer and any third-party VAT identification number to be exactly twelve characters — the letters OM followed by ten digits — so a free-text customer reference will not survive it. Rule IBR-002-OM requires a unique document identifier that is a valid UUID version 5: not a sequence number, and not any UUID, but one generated from a namespace and a name.
Rules IBR-001-OM and ALIGNED-IBRP-000-OM require a twenty-character transaction type made of ones and zeros, with at least one position set. It is an enumeration rather than free text, and the type then decides which other rules apply to the document, so it cannot be defaulted and forgotten. And on every line, IBR-078-OM requires a statement of whether the line is goods or services, with an industrial classification code under IBR-081-OM; a goods line additionally carries a twelve-digit Harmonized System code under IBR-079-OM and IBR-080-OM, while service-type codes are validated separately under CL-12-OM.
One more constraint is worth knowing before anyone designs a table: IBR-DEC-03-OM refuses any amount carrying more than three decimal places. That is the Omani rial’s own precision rather than the two decimals most systems default to, and it is a schema decision, not a formatting one.
Against the destination’s own rules, on our side, before transmission. For Oman that is the full PINT OM 1.0.1 rule set including its Schematron rules, and what comes back is a compliance score with human-readable errors rather than a bare pass or fail. An error that names the field and the rule is a ticket a developer can act on; a rejection code is a conversation.
Three layers can refuse the document, and the size of each is worth knowing. Counted in the packs GoRoute ships on 22 August 2026: the shared Peppol PINT layer holds 170 rules, every one of them fatal; Oman’s own jurisdiction pack holds 155, of which exactly two are warnings; and the tax data document has its own pack of 66 rules, all fatal. Any fatal finding stops the document before anything leaves, and the response names the rule that fired by its own identifier. Severity comes from the rule file rather than from how the sentence reads — three Oman rules are worded “should” and are flagged fatal, so a message that sounds like advice can still refuse the document.
Over Peppol, as UBL 2.1 XML conforming to the PINT Oman profile, from one certified Access Point to another. GoRoute looks the buyer up in the network directory and hands the document to their provider over AS4 — no portal, no emailed attachment, and nothing for the buyer to install. Oman uses Peppol scheme 0248, and the party identifier is the VAT identification number carried with an OM prefix, for the seller and for the buyer alike. Populating that across an existing customer base is usually the longest task in the project and the one least likely to sit with the integration team.
The invoice is what your buyer receives. The tax data document is
the report that goes to the Authority, and it carries the invoice inside it —
rule ibr-tdd-57 requires the report to contain a UBL 2.1 invoice or
credit note. It declares which specification it follows, exactly
(ibr-tdd-01, urn:peppol:taxdata:om-1), and which
business process it belongs to (ibr-tdd-02,
urn:peppol:taxreporting) — this is a report to an authority, not a
document sent to a buyer. Its receiving party is identified by a service provider
identifier in scheme 0242 under
ibr-tdd-17, not by a company registration number. That separation is
why a clean validation result on the invoice can still leave work to do on the
report.
One report per transaction, carrying the time it happened. Real-time is a property of the report format in Oman’s model rather than a marketing adjective: the tax data document pack allows exactly one reported transaction per document (ibr-tdd-09) and requires the date and time the original document was received to be present (ibr-tdd-59 and ibr-tdd-60). A design that batches a day’s transactions into one report does not satisfy that shape, which is a thing to find out while you are drawing the architecture rather than after you have built it.
It comes back with the response, for the document types that require one. Oman’s specification requires a QR code on simplified tax invoices — the reduced-content receipt handed to a consumer at a counter. It is a business-to-consumer feature: full tax invoices do not carry one. Two details are commonly got wrong by teams arriving from a neighbouring Gulf regime, and both are expensive to unpick later: the Oman QR contains no hash and no digital signature, and carrying over another country’s QR construction produces a document Oman’s validation rejects.
In the GoRoute transactions dashboard, which holds the audit trail: what went out, what each document was validated against, and what the receiving side acknowledged. This is why the recording spends time on the transactions page rather than only on the send. A transaction whose status nobody can see is not auditable, and from the mandate date it is the record that has to stand up rather than the act of sending.
One identifier. The same document identifier appears in the APEX table, in the GoRoute transactions dashboard and on the printable receipt, which is the whole point of the closing section of the recording. It sounds mundane and it is the difference between a reconciliation that takes minutes and one that takes a week: three systems agreeing on what to call the same document is what makes a single receipt findable in year six of a ten-year retention period.
Almost all of it. Validation-only calls carry no per-call charge, along with status lookups and webhooks — billing is per document exchanged — so validating the same document forty times while an APEX mapping is corrected costs nothing. And you can validate long before you can send, which lets the development work and the commercial work run in parallel rather than in sequence. For volume, batch submission takes between 1 and 1,000 invoices in a single request, with validate and process as separate stages: useful for backfilling and for month-end, even where the live path reports one transaction at a time.
The same one that applies to everybody else, and it depends on annual supplies rather than on your technology. Decision 189/2026 makes electronic tax invoices mandatory from 1 April 2027 for taxable persons whose annual supplies exceed OMR 5,000,000, and from 1 October 2027 for those at or below that figure. Establish which applies to you by annual supplies, not by headcount or sector. The detail of what the Decision changed is on the page that owns Oman’s e-invoicing dates; this page states no further dates on purpose.
For Oman, in Oman. GoRoute operates in-country data residency on Otech’s Tier III Oracle Cloud Infrastructure region, covering invoices, keys, tax data documents and audit logs, and operates ISO 27001-aligned practices on certified cloud infrastructure. Documents issued before the Authority’s production environment opens are preserved with their original issue time and released when it opens — a document held is not a document re-dated. No date has been announced for that opening, and any provider quoting one should be asked where it came from. For an Oracle estate this is usually the cheapest part of the security review to answer, and much cheaper in week one than in month six.
No. Oracle raises the document as it always did. The data then leaves Oracle as structured data, is validated against Oman’s rule packs, is rendered as UBL 2.1 XML conforming to the Peppol PINT Oman profile, and travels to the buyer over the Peppol network — while a separate tax data document, carrying that invoice inside it, is what reaches the Authority.
The Oracle APEX case: a custom application at a service counter. Oracle Fusion Cloud ERP, E-Business Suite, NetSuite and APEX applications each take a different integration path, so which product and version apply to your estate is a scoping question to get answered in writing rather than inferred from a demonstration.
Four values. Seller, buyer and third-party VAT identification numbers of exactly twelve characters, OM followed by ten digits, under IBR-003-OM. A valid version 5 UUID on every invoice under IBR-002-OM. A twenty-character transaction type of ones and zeros under IBR-001-OM. And on every line, goods or services under IBR-078-OM with an industrial classification code under IBR-081-OM. Amounts carry no more than three decimal places, under IBR-DEC-03-OM.
The invoice is what your buyer receives; the tax data document is the report that goes to the Authority, and it carries the invoice inside it under rule ibr-tdd-57. It has its own pack of 66 rules, all of them fatal, including exactly one reported transaction per document under ibr-tdd-09 and the date and time the original was received under ibr-tdd-59 and ibr-tdd-60.
Counted in the packs GoRoute ships on 22 August 2026: 170 in the shared Peppol PINT layer, all fatal; 155 in Oman’s own jurisdiction pack, of which exactly two are warnings; and 66 in the tax data document pack, all fatal. Any fatal finding refuses the document, and the response names the rule that fired by its own identifier.
The same dates as everyone else, and they depend on annual supplies rather than on which system you run. Decision 189/2026 makes electronic tax invoices mandatory from 1 April 2027 for taxable persons whose annual supplies exceed OMR 5,000,000, and from 1 October 2027 for those at or below that figure.
This recording shows the same platform you would be buying, doing the thing you would be buying it for — on a Peppol-certified access point.
Press Esc, click outside, or use the ✕ to close and stop playback.
