The question is not whether Odoo can produce an invoice. It is what happens to that invoice afterwards. This recording follows one the whole way: raised in Odoo the ordinary way, sent to GoRoute over the REST interface, validated against Oman’s PINT OM rules in real time, and its status and audit trail written back.
It runs 11 minutes 38 seconds and covers credit notes and debit notes as well as the straightforward case, which is where most integrations turn out to be incomplete. The whole sequence 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 is in Odoo e-invoicing in Oman.
Below is the recording written out, stage by stage, so this page answers what the integration does without anyone pressing play — useful if video is blocked where you are reading it, and faster to scan when you are scoping work. Where a detail comes from Oman’s published rule packs or from the Odoo guide rather than from the video, it says so.
Because “real-time” here is a property of the report format rather than a marketing adjective. Oman’s tax data document — the report that goes to the Authority — allows exactly one reported transaction per document (rule 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 collects a day of Odoo invoices and reports them in one overnight file does not satisfy that shape. That is a thing to learn while drawing the architecture, not after building it, and it is why the recording opens on this point.
Exactly as it is today. The invoice is raised through Odoo’s ordinary invoicing workflow — no new screen, no second data entry, no GoRoute field for a person to remember. That matters more than it sounds: the commonest objection to an e-invoicing project is that finance staff will have to work differently, and here they do not. The integration extends Odoo’s native invoice functionality rather than replacing it, so existing approval and posting workflows stay as they are.
As structured data over a REST interface, not as a PDF. This is the whole point of the exercise: a tax authority and a buyer’s system both read fields, and neither reads a picture of an invoice. Odoo is connected to GoRoute once, as a setup step, rather than per invoice or per user — API credentials and a field mapping from Odoo’s invoice model to UBL, configured at the start and then left alone.
The party identifiers. Oman uses Peppol scheme 0248, and the identifier is the VAT identification number carried with an OM prefix. It is required for the seller and for the buyer, which means it has to be present in your own company record and across your customer records in Odoo. Oman’s rule IBR-003-OM requires that number to be exactly twelve characters — OM followed by ten digits — so a free-text reference field will not survive validation.
Start this first, because it is not a technical task and it does not sit with the people doing the integration. Two habits save weeks. Fix your own side first: your company records are a handful of entries entirely within your control, and getting them right removes most of the noise from early test results. Count the gap before planning around it: run a count of active customers with no usable VAT identifier. That single number sizes the data work, and it is much better known in week one than in week nine.
The document is checked against the full PINT OM 1.0.1 rule set including its Schematron rules, before anything is transmitted, 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 someone can act on; a rejection code is a conversation.
Three layers can refuse the document. Counted in the packs GoRoute ships on 22 August 2026: the shared Peppol PINT layer holds 170 rules, all 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. 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.
Two documents rather than one. The invoice is what your buyer receives, over the
Peppol network, as UBL
2.1 XML conforming to the PINT Oman profile. The tax data document
is the report that reaches the Authority, and rule ibr-tdd-57
requires it to contain that invoice inside it. It declares its own
specification exactly (ibr-tdd-01,
urn:peppol:taxdata:om-1) and its own business process
(ibr-tdd-02, urn:peppol:taxreporting), and its
receiving party is a service provider identifier in scheme 0242
under ibr-tdd-17. That separation is why a clean result on the
invoice can still leave work to do on the report.
As a status you can act on rather than as silence you have to chase. The result comes back on the same interface the invoice went out on, and failed transmissions are retried automatically with a widening gap between attempts rather than dropped. The integration raises activity records in Odoo for anything that needs a person, with the error message attached — and an invoice remains a valid invoice regardless of transmission status, which is the distinction that keeps a delivery problem from becoming an accounting one.
They are in the recording for a reason: this is where most integrations turn out to be incomplete. A credit note and a debit note are separate document flows with their own type codes, and both are in scope for reporting alongside the original invoice — a system that only sends invoices satisfies about eighty per cent of a requirement and fails the audit on the rest. Oman’s transaction type field under IBR-001-OM is what carries the distinction, and it decides which other rules apply to the document, which is why it cannot be defaulted once and forgotten.
In the GoRoute dashboard: what went out, what each document was validated against, and what the receiving side acknowledged. This is the part an auditor asks about and the part a manual process cannot produce a year later. 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.
Because a manual upload is a person, a spreadsheet and a deadline, and it fails exactly when the volume is highest. An interface removes the re-keying, removes the window in which the accounting record and the compliance record disagree, and leaves a trail nobody has to reconstruct. For volume, batch submission takes between 1 and 1,000 invoices in a single request, with validate and process as separate stages — which is the shape that matters at month-end, when the invoices arrive in an hour rather than across a day.
Almost all of it, at no cost. Validation-only calls carry no per-call charge, along with status lookups and webhooks — billing is per document exchanged — so validating the same invoice forty times while getting a mapping right costs nothing. And you can validate long before you can send, so the technical work and the commercial work run in parallel rather than in sequence.
Nothing extra in Odoo. The destination decides which rule set an invoice is validated against and which network carries it, and that is not configured per country on your side: the recipient identifier resolves the route. One connection and one account covers 40+ countries — Peppol across Europe and beyond, the DBNAlliance network in the United States, and clearance systems such as Oman’s Fawtara and Saudi Arabia’s ZATCA. For an Odoo estate running several companies, that is the difference between one integration and one per market.
Three things, and it is better to read them here than to discover them in a procurement meeting. Which Odoo versions are covered for you: version support and packaging depend on your environment and edition, so ask and get the answer in writing — from us or from any other provider. What your own customisations do: most Odoo estates in use for a few years carry local modifications to invoicing, and those are found by running your own documents through validation, not by watching a demonstration. And whether your data is ready, which is the identifier count above.
The same one that applies to everybody else, and it depends on annual supplies rather than on your accounting system. 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. 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 — and no date has been announced for that opening. The detail of what the Decision changed is on the page that owns Oman’s e-invoicing dates.
Odoo is the accounting system; Oman’s programme is satisfied by what happens to the invoice after Odoo issues it. This recording shows that path end to end: an invoice raised in Odoo, sent over a REST interface, validated against the PINT OM rules, and its status written back. It is a demonstration of the path rather than a statement about your particular Odoo installation.
The party identifiers. Oman uses Peppol scheme 0248, and the identifier is the VAT identification number carried with an OM prefix, for the seller and for the buyer. That data lives in your Odoo contact and company records, and populating it across an existing customer base is usually the longest task in the project.
Validate it. GoRoute checks a document against the full PINT OM 1.0.1 rule set including its Schematron rules and returns a compliance score with human-readable errors rather than a bare pass or fail. Validation-only calls carry no per-call charge, so validating repeatedly during a build costs nothing.
Yes, and the recording covers both. They are separate document flows with their own type codes, and both are in scope for reporting alongside the original invoice. Oman’s transaction type field under IBR-001-OM carries the distinction, and it decides which other rules apply to the document.
Yes. Batch submission takes between 1 and 1,000 invoices in a single request, with separate validate and process stages. That matters at month-end, which is when a design that sends one invoice per call tends to fail.
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.
