Zoho Books stays the system your team works in. GoRoute is authorised against your Zoho apps once, using Zoho’s own OAuth 2.0 consent screen, and from then on each invoice is converted into UBL 2.1 XML in the Peppol PINT Oman profile, validated against Oman’s rules, delivered to your buyer, and reported to the Oman Tax Authority as a separate tax data document.
The recording runs 12 minutes 7 seconds in fifteen chapters: why Zoho Books users in Oman need readiness at all, what the connector does, the invoice workflow inside Zoho Books, sending the data to GoRoute, validation, Fawtara readiness and Peppol processing, status tracking, transaction detail and document history, and how errors and corrections reach a person. The same walkthrough is written out further down the page, chapter by chapter, if you would rather read it than watch it.
Below is the recording written out, chapter by chapter and in its own order, so the page answers what the Zoho Books connection does without anyone pressing play. Nothing here describes a screen the recording does not show; where a rule identifier or a code list comes from the Oman Zoho Books guide or the Zoho integration page rather than from the video, it says so.
Because a correct Zoho Books invoice and a document Oman accepts are not the same thing, and the difference is not cosmetic. Oman’s programme asks for a structured file in a named profile, carrying fields that never appear on a printed invoice, validated against a published rule set, delivered over a certified network and reported to the Tax Authority separately. None of that is a criticism of Zoho Books, which is doing the job it was built for. It is the reason a connection exists.
It is an authorised connection rather than something you install. GoRoute is authorised against your Zoho apps using OAuth 2.0 — the standard consent screen Zoho itself provides — and reads invoice data from there rather than asking your team for exports. The same authorisation covers Zoho Books, Zoho CRM and Zoho Creator, which matters more than it sounds: in a Zoho One estate the customer master is often in CRM rather than in Books.
After that the path is the same for every source system, and it is worth knowing in outline because it explains where problems surface. Conversion turns invoice data into UBL 2.1 XML in the PINT Oman profile, where a missing field shows up as an empty element rather than an error. Validation checks the document against the shared Peppol rules and Oman’s own pack, by rule identifier, before anything is sent. Delivery carries the invoice to the buyer through a certified access point. Reporting files a separate tax data document with the Oman Tax Authority, against its own rule pack.
The recording opens in Zoho Books rather than in GoRoute, which is deliberate. The starting point is the customer invoice a business already produces — from a quote, a sales order, a retainer or a service bill. Nothing about how it is raised changes, no new screen appears in the finance team’s day, and no parallel process runs alongside the ledger. That is the first question every finance lead asks before agreeing to an integration, and the recording answers it by showing it.
An ordinary Zoho Books invoice, with its customer, its lines and its tax rates, is picked up as it stands. What decides whether it survives the next stage is not how it was created but what it carries: a customer with a VAT identification number in Oman’s format, lines whose 0% rates have a reason behind them, goods lines with classification codes, and amounts at the right precision. Those are properties of the record, not of the workflow, which is why the data work is where Oman projects run long.
The data travels over the authorised connection and becomes a structured document on our side. No file is exported, emailed or uploaded by a person, which removes the step where most small-business compliance processes quietly break: the one that depends on somebody remembering. Where invoices never start in Zoho Books at all — a project billed from a spreadsheet, say — the spreadsheet route runs the same validation on a CSV, and a business can run both routes at once.
The invoice data becomes UBL 2.1 XML in the Peppol PINT Oman profile.
Three of the fields Oman requires are produced here rather than asked of you: a
version 5 UUID on the document — derived from a name rather than
random, so the same invoice always produces the same identifier and a retry is
recognisable as a retry (IBR-002-OM);
an issue time as well as an issue date; and a
transaction type saying what kind of supply this is — export,
import of goods, reverse-charge import of services, summary invoice, continuous supply,
special-zone supply, profit margin, self-billing.
The transaction type is not bookkeeping trivia: several rules only fire because of it. An export invoice claiming re-export of goods must reference a supporting document, and a summary invoice’s period must start and end inside one calendar month.
The document is checked against the full PINT OM rule set including its Schematron
rules, and what comes back names the rule that fired by its own identifier —
IBR-069-OM rather than
“invalid tax line”. An error naming the field and the rule is a ticket
somebody can act on.
Three things about Oman’s rules catch a Zoho Books file specifically.
VAT identification numbers must be exactly twelve characters —
OM followed by ten digits
— for the seller, the buyer and any third party
(IBR-003-OM).
Amounts must not carry more than three decimal places
(IBR-DEC-03-OM), because
the rial has 1,000 baisa and two decimals is what most files have always used; line VAT
is checked against rate times net amount within a tolerance measured in baisa, so a line
rounded at the wrong precision falls outside it. And every 0% line needs a
coded reason: an exempt line takes one of the twelve codes
VATEX-OM-01 to
VATEX-OM-12 under
CL-05-OM, a zero-rated
line one of the sixteen codes
VATZR-OM-01 to
VATZR-OM-16 under
CL-10-OM.
An accounting system records a tax code and a rate; it does not usually record why a line is 0%. That mapping needs your finance lead rather than your integrator, and it is the single item most likely to still be open the week before go-live. Severity also comes from the rule file rather than from how a message reads: Oman’s pack contains rules worded “should” that are flagged fatal, and it deliberately accepts some documents with a warning, so “rejected” and “accepted, please confirm this was deliberate” must not be flattened into one red cross.
Two deliveries, not one. The invoice goes to your buyer over the Peppol network, through a certified access point at each end. A tax data document, derived from that invoice and carrying it, goes to the Oman Tax Authority against its own rule pack. This is the second most common misunderstanding after the format: sending an invoice does not report it, and reporting it does not send it. It is also why a clean validation on the invoice can still leave work to do.
Every document that has been submitted appears in one register with its state attached, and a failure carries a reason rather than a silence. An invoice that came from Zoho Books, one raised in the GoRoute portal and one posted straight to the REST API land in the same register carrying the same kind of record, because the connectors are routes in rather than separate systems.
The document itself, what was sent, when, to whom, and what came back. That history is the audit answer: timestamps, signatures, delivery receipts and authority responses, retained rather than reconstructed. For Omani clients it is held in Oman — invoices, keys, tax data documents and audit logs — which is a question security reviews usually raise late, at the point where changing the answer is expensive. The detail is on data residency and compliance in Oman.
A refused document is refused before anything is sent, with the rule that fired named, which means the correction happens in your own file rather than in a dispute with an authority. Validating a real invoice early is cheap on purpose: validation runs long before you are ready to send anything, so the mapping work and the commercial work run in parallel instead of in sequence. The visibility point matters as much as the mechanism — a finance team that can see why a document stopped does not need to raise a ticket to find out.
For a CFO: a compliance obligation that does not become a change to how the business invoices. For an accountant: errors that arrive as named rules rather than as rejected filings. For a firm supporting several Omani clients: one place to see every client’s documents, and, if the firm wants to sell this as its own service, a branded portal with per-client onboarding rather than a Peppol application of its own. Three owners are worth naming in week one whichever route you take — the customer master, the item master, and whoever answers for the VAT treatment.
It does not settle the state of your own Zoho Books file, which is what
decides your timetable. Two counts do more for a plan than any demonstration: how many
active customers have no VAT identification number in the
OM-plus-ten-digits form,
and how many distinct 0% tax rates are in use. Nor does it settle
which Oman deadline applies to you: 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 — by annual
supplies, not by which accounting system you run.
The field-by-field version of everything above is in Zoho Books e-invoicing in Oman: what connects, and what Oman asks for. A document can be validated against the full Oman rule set before you commit to anything, through the free sandbox; the market as a whole is on the Oman page; and if it is easier to talk it through against your own file, book a working session.
Yes, through an authorised connection to GoRoute rather than anything installed in Zoho. You authorise GoRoute against your Zoho apps using OAuth 2.0, Zoho's own consent screen. Each invoice is converted into UBL 2.1 XML in the Peppol PINT Oman profile, validated against Oman's rules, delivered to the buyer through a certified Peppol access point, and accompanied by a separate tax data document filed with the Oman Tax Authority.
Six things. A version 5 UUID on the document, an issue time as well as a date, and a transaction type saying what kind of supply it is — all three produced in the conversion. Then a VAT amount and a total including VAT on every line, an exemption reason code on every zero-rated or exempt line, and a twelve-digit Harmonized System code on goods lines — those three have to come from your business.
Two fields and one list. Your own VAT identification number and every Omani customer's must be exactly twelve characters, OM followed by ten digits, under IBR-003-OM. Amounts must not carry more than three decimal places, under IBR-DEC-03-OM, because the rial has 1,000 baisa. And every 0% tax rate in your file needs a decision: zero-rated or exempt, and which Oman code applies.
Fixed lists, and the rule packs check the value rather than accepting any text. An exempt line must carry one of the twelve codes VATEX-OM-01 to VATEX-OM-12 under CL-05-OM. A zero-rated line must carry one of the sixteen codes VATZR-OM-01 to VATZR-OM-16 under CL-10-OM. A 0% line with no reason code fails outright under IBR-069-OM.
They are part of the same integration rather than a separate project, authorised through the same OAuth 2.0 consent. For an Oman rollout the practical question is where the missing data will live: customer VAT identification numbers belong wherever your customer master is genuinely maintained, and if that is CRM rather than Books, that is where the clean-up has to happen.
No. Your buyer receives the invoice; a separate tax data document, derived from that invoice and carrying it, goes to the Authority. It has its own rule pack, which is why an invoice that validates cleanly can still leave work to do. Sending an invoice does not report it, and reporting it does not send it.
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.
