The GoRoute WooCommerce plugin turns each order into an Oman-compliant e-invoice without changing how the store sells: the invoice is built and checked on the GoRoute platform, delivered to business buyers over the Peppol network, given the Fawtara QR code for consumer sales, and reported to the Oman Tax Authority, with the status written back to the order.
The recording runs just under sixteen minutes in fourteen chapters, from installing the plugin and connecting the store with one button, through a first order, to refunds, the archive and what to check before going live. It is written out below so the page answers the questions without pressing play.
Below is the recording written out, chapter by chapter and in its own order, so the page answers what the plugin does without anyone pressing play. Where a detail comes from the WooCommerce e-invoicing for Oman product page rather than from the video, it says so.
It turns each WooCommerce order into an Oman-compliant e-invoice without changing how the store sells. The plugin sits inside WordPress next to WooCommerce, takes the order at the moment it is paid or completed, builds the invoice in the PINT OM format the Oman Tax Authority requires, checks it, delivers it to a business buyer over the Peppol network, and reports the Tax Data Document to the Authority. The store keeps its products, checkout, customers and order numbers exactly as they were.
The recording opens with that framing: e-invoicing in Oman is not an accounting-system problem alone. For an online store the checkout, the order confirmation, refunds, tax details, the QR code and the archive all have to line up, and a plugin that lives where the order is created is the shortest way to make them.
Because Fawtara does not care how a sale was made; it requires a structured invoice to reach the buyer over Peppol and a tax data document to reach the Oman Tax Authority. WooCommerce produces an order and an email, which is neither. A PDF attached to the confirmation email satisfies neither either. The connector closes that gap at the source rather than asking an accountant to re-key every web order later.
That is also why the plugin reports to the Authority even when the buyer is not on the network yet. Delivery and reporting are two separate obligations, and the second does not wait for the first. The rules themselves are set out on the Oman e-invoicing (Fawtara) compliance page.
Between the paid order and everything downstream. WooCommerce still owns the sale; GoRoute owns the invoice's compliance journey. When an order reaches the status you choose, the plugin sends the order data to the GoRoute platform, which validates it, signs it, delivers it, reports it and keeps the record. The result, and every status change after it, is written back to the order so the shop team never has to leave WooCommerce to know what happened.
Like any WordPress plugin: install it, activate it, and open its settings page. The settings ask for the store's own details as a seller, which invoice numbering series to use, and which order status should trigger an invoice. The seller's VAT number is what the Tax Authority will see on every document, so it is worth checking it once against the VAT certificate before the first order goes out.
With one button. The settings page offers a connect action that opens GoRoute, asks you to sign in to your GoRoute organisation, and hands the store an API key bound to that organisation. Nothing is copied by hand. The same page carries a network lookup, so you can type any VAT number, yours or a customer's, and see at once whether it is registered to receive e-invoices.
One detail from the demonstration is worth knowing: the settings page names the platform address the store talks to. A store being tested against the GoRoute test environment points at that address; a live store points at the production one. Mixing them is the most common reason a first invoice ends up filed rather than delivered.
The ones Oman's format needs and WooCommerce already holds. Billing name and address become the buyer; the buyer's VAT number, entered on the billing form, decides whether the sale is business-to-business or a consumer sale; each line's price, quantity and tax rate become invoice lines with the right VAT category; shipping becomes a charge; coupons become allowances. The plugin fills in what the format requires and WooCommerce does not carry, such as the transaction type code and the invoice UUID derived the way the Solution Architecture prescribes.
In the recording an order is created in the normal way, with a business customer whose VAT number is on the billing form. When the order reaches the trigger status, the order page gains an e-invoicing panel: the invoice number, the network check on the buyer, and the delivery and reporting status as they change. The invoice itself can be opened from the panel as a PDF, with the same content that was sent.
Over the GoRoute API, with the key the connection step issued. The plugin sends the order as invoice data rather than as a finished document, and the platform renders the PINT OM invoice, validates it against the Oman rules, and signs it. If a check fails, the failure is shown on the order with the rule that failed, and nothing is sent until it is fixed. If the buyer's VAT number is registered on the network, the platform resolves the buyer's access point and delivers the invoice there.
Validation is the check against the Oman rules before anything leaves the platform: mandatory fields, VAT categories, totals, identifiers. The QR code is the Fawtara code that a simplified tax invoice for a consumer must carry; it is generated by the platform and placed on the invoice. The transaction status is the record of what happened next: queued, delivered, or filed under a substitute address when the buyer is not on the network, and, separately, whether the Tax Data Document was reported to the Authority and what the Authority answered.
The dashboard's transactions page lists the same invoice with its full history: the direction, the participant it went to, the delivery status, the reporting status and every timestamp. The document can be opened as the sent XML and as a PDF. The recording switches from the WooCommerce order to the dashboard to show the same invoice from both sides.
A refund in WooCommerce produces a credit note that references the original invoice, so the correction travels the same route the invoice did: to the buyer over the network, and to the Tax Authority as its own report. A partial refund produces a credit note for the refunded amount only. An order changed before it reached the trigger status simply produces an invoice reflecting the change; an order changed after that is corrected with a credit note and, where needed, a new invoice, which is how the Oman rules expect corrections to be made.
Every invoice, credit note and report, the exact document that was sent, and the status history around it. The order in WooCommerce keeps its link to the invoice, and the dashboard keeps the document and its journey. That is what an auditor asks for: not a re-generated copy, but the document as delivered and the evidence of its delivery and reporting.
Three things the recording singles out. First, the seller details: the VAT number and legal name on the settings page are what every document will carry. Second, the buyer's VAT number: business customers need somewhere to enter it at checkout, or every sale will be treated as a consumer sale. Third, the environment: test against the GoRoute test platform with test taxpayers first, then switch the store's platform address to production once the flow is proven.
Order paid in WooCommerce; invoice data sent to GoRoute; invoice built, checked and signed; delivered to a business buyer over Peppol, or filed with the QR code for a consumer; Tax Data Document reported to the Oman Tax Authority; status written back to the order and visible in the dashboard; refunds handled as credit notes by the same route. Nothing in the store changes, and nothing has to be re-keyed.
Yes. It is a WordPress plugin installed alongside WooCommerce on the store you already run. Products, checkout, customers and order numbers stay as they are; the plugin adds e-invoicing to each order rather than replacing anything.
The invoice is still issued and reported to the Oman Tax Authority. The plugin checks the customer's VAT number against the network first; if it is not registered, the invoice is filed under the address the Oman Solution Architecture defines for a buyer not on the network, and you send the customer a PDF. When they register, later invoices are delivered over Peppol automatically.
Yes. A sale to a consumer produces a simplified tax invoice carrying the Fawtara QR code, and its Tax Data Document is reported to the Oman Tax Authority within the 24-hour window the Authority allows for consumer sales.
A refund in WooCommerce produces a credit note that references the original invoice, so the correction reaches the buyer and the Tax Authority the same way the invoice did. A partial refund produces a credit note for the refunded amount only.
In the GoRoute dashboard, and in the order itself. Each WooCommerce order shows the invoice number, the delivery status and the Tax Authority reporting status, and the dashboard's transactions page lists every document with its full history.
No. GoRoute is an OTA-accredited service provider and a Peppol-certified access point, so the store connects to GoRoute and GoRoute connects to the network and to the Tax Authority. There is nothing for the merchant to certify or host.
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.
