GoRoute is one REST API that converts, validates and delivers an invoice to the buyer and, where the country requires it, to the tax authority — across more than 40 countries, over Peppol, over DBNAlliance and into clearance systems such as Oman’s Fawtara. This recording is that platform running.
It runs 10 minutes 52 seconds in twelve chapters: what GoRoute is, why global e-invoicing is complex, the platform and its dashboard, the invoice workflow and its routing, Peppol and compliance, multi-country coverage, ERP and billing integration, and the white-label route for partners. 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 platform does without anyone pressing play. Nothing here describes a screen the recording does not show; where a figure or a rule comes from the global e-invoicing page, the API services page or the Oman e-invoicing page rather than from the video, it says so.
An enterprise e-invoice sending platform: one REST API that issues, validates and delivers invoices at scale from the finance systems a company already runs. Two destinations, not one. The invoice goes to the buyer over a network such as Peppol, and in countries that clear invoices before they reach the buyer it also goes to the tax authority. Both happen through the same interface.
The infrastructure underneath is certified rather than asserted. GoRoute operates a Peppol-certified Access Point and SMP under Service Provider ID POP000991, held by ClayDesk LLC, and is an e-invoicing service provider accredited in Oman by the Oman Tax Authority on 29 July 2026 through Union Digital Technologies SPC. Those are facts a buyer can check with the issuing bodies, which is the point of stating them rather than describing the platform as leading.
Because three things differ per country, and they differ independently of each other. The format differs — UBL, CII, FatturaPA, Factur-X, the PINT profiles — and each carries its own schema and its own validation rules. The network differs: Peppol across most of Europe and much of Asia-Pacific, InvoiceNow in Singapore, DBNAlliance in the United States, SDI in Italy. The model differs: post-audit, where the invoice travels straight to the buyer and the authority looks later, or real-time clearance, where it does not reach the buyer until the authority has seen it.
Built in-house, that is ten or more API integrations, twenty or more format specifications, certificates and PKI to operate, and a regulatory calendar somebody has to own for as long as the company trades. The chapter makes the argument in the form of a comparison, and the comparison is the reason the rest of the recording exists: one integration, one input format, and the tracking of regulatory change becomes somebody else’s standing job.
Four stages, and the recording walks them in order. You send the invoice as JSON or as UBL XML, with the recipient’s identifier. It is validated against the destination’s own rules before it leaves your boundary. It is routed — the recipient identifier decides whether that is Peppol, a clearance system or a regional network — and converted and signed as that destination requires. It is delivered, and a webhook returns the receipt.
The part worth noticing is where validation sits. It happens before transmission, not after rejection, which is what turns a compliance problem into a development ticket rather than a phone call from a customer. Behind all four stages sits a complete audit trail: timestamps, signatures, delivery receipts and tax authority responses, retained for the statutory periods these regimes require.
The register of what has been sent, what is in flight and what failed, with the document itself reachable from each row. An invoice raised in the portal, one pushed by an ERP connector and one posted straight to the API all land in the same register carrying the same kind of record, because the connectors are routes in rather than separate systems.
This is the section a finance lead watches rather than a developer. If you want the screens themselves rather than the tour, the portal demo is written out step by step — raising an invoice, sending it to a customer, and finding it again afterwards.
By the recipient, not by configuration. The identifier on the invoice says who the buyer is and in which scheme, and that determines the network, the format and the signature. Format conversion is automatic: you send one input and the platform produces the FatturaPA, the Factur-X, the ZATCA XML or the PINT profile the destination expects. Signatures follow the same rule — XAdES, CAdES, and the cryptographic stamps and QR codes some authorities require.
What comes back matters as much as what goes out. Delivery confirmations, rejection alerts and incoming-invoice notifications are pushed to your endpoint as webhooks rather than waiting to be polled for, and every one of them is also queryable, which is the difference between an integration that knows where a document is and one that hopes.
Peppol is a four-corner post-audit network: the invoice travels from the sender’s Access Point to the receiver’s Access Point, and tax authorities audit afterwards. Clearance regimes work the other way round. Saudi Arabia’s ZATCA and Oman’s Fawtara require the document to be submitted to the authority, which validates and stamps it as it reaches the buyer. Both models run through the same API, which is the only reason a single integration can cover both kinds of country.
Compliance in this context is a specific thing rather than a posture: Schematron validation against EN 16931, against Peppol BIS Billing 3.0, and against the national rule set that applies — the full PINT OM v1.0.1 rules for Oman, including their Schematron. The result is a compliance report naming the rule that fired, not a bare pass or fail, because a rule identifier is something a developer can act on.
More than 40 jurisdictions, spread across Europe, the Middle East, Asia-Pacific, the Americas and Africa. In practice that is Germany’s XRechnung, France’s Factur-X, Italy’s FatturaPA, Poland’s KSeF, Belgium’s live B2B mandate, Singapore’s InvoiceNow, Malaysia’s MyInvois, Japan’s PINT JP, ZATCA in Saudi Arabia, Fawtara in Oman, and the Latin American clearance systems.
The value is not the length of the list. It is that a rule change in one of those countries is absorbed in the platform rather than in your code — Schematron updates, code list revisions, new profile versions. A finance system that had to follow twelve regulators itself would spend its life being modified.
Four ways in, and a business usually uses more than one. A published connector for the common systems — Odoo, Microsoft Dynamics 365 Business Central, Zoho Books, TallyPrime. A spreadsheet route for the invoices that never start in a system at all. The web portal for occasional documents. And the REST API for everything else.
One design detail decides whether the integration survives month-end: batch submission takes between 1 and 1,000 invoices in a single request, with validate and process as separate stages. An integration that sends one invoice per call works perfectly in testing and falls over on the last working day of the month.
For accounting firms, managed service providers and resellers, the same platform runs under someone else’s name. A white-label portal carries the partner’s logo, domain, colours and pricing; clients are onboarded and monitored from a partner dashboard; and the partner owns the relationship and the first line of support. What the partner does not do is apply for a Peppol seat, obtain certificates or operate a server.
Two neighbouring services answer different questions, and the recording is careful to separate them. A firm that wants to be the certified provider itself, on its own Peppol seat, but not to run the machines, wants managed Access Point and SMP operations. One that already operates an Access Point and only needs participants registered wants SMP-as-a-Service.
Checkable credentials rather than adjectives, and they are worth writing down because you can ask any provider for the equivalent. A Peppol-certified Access Point and SMP under POP000991. PINT OM v1.0.1 conformance re-certified in July 2026 with every suite passed — Billing and tax data document 7/7, self-billing 7/7, reporting 2/2, eDelivery 7/7 and BIS Billing 5/5. Accreditation in Oman by the Oman Tax Authority on 29 July 2026. In-country data residency for Omani clients, covering invoices, keys, tax data documents and audit logs.
Three things, and it is more useful to say so than to imply otherwise. It does not settle which countries you are actually obliged in, which depends on where you sell and on each regime’s own thresholds. It does not settle the state of your own data — the buyer identifiers, tax registration numbers and item classifications that decide whether documents are accepted, and which are usually the longest task in any rollout. And it does not settle commercials.
What you can do without talking to anyone is validate a real document against a real rule set: the sandbox and the developer documentation are open, and validation-only calls carry no per-call charge. If Oman is your market, the Oman e-invoicing page covers the mandate dates and what the programme asks for beyond a working connection. When it is easier to talk it through against your own systems, book a working session.
One REST API that converts, validates and delivers invoices to buyers and to tax authorities in more than 40 countries, run on a Peppol-certified Access Point and SMP (Service Provider ID POP000991, ClayDesk LLC). You send one input format; the platform produces whatever the destination requires.
Peppol, the DBNAlliance network in the United States, Finland's Finvoice, and the tax-clearance systems that do not use a network at all — Saudi Arabia's ZATCA and Oman's Fawtara among them. The recipient identifier decides which one, so routing is not something you configure per invoice.
It runs 10 minutes 52 seconds and carries twelve chapter marks, so you can go straight to the dashboard at 03:05, invoice routing at 04:12, ERP integration at 07:28 or the white-label section at 08:40. Every chapter is also written out on this page.
Where the country requires it, yes, and they are two different things. Peppol is a four-corner post-audit network: the invoice goes to the buyer and the authority audits later. A clearance country such as Oman or Saudi Arabia requires a submission to the authority as well, which the platform makes through the same API call.
Yes. Batch submission takes between 1 and 1,000 invoices in a single request, with validation and processing as separate stages. That shape matters at month-end, which is when a design that sends one invoice per call tends to fail.
No. Accounting firms, managed service providers and resellers can run the same platform under their own brand, domain and pricing, onboarding their own clients from a partner dashboard, without applying for a Peppol seat or operating a server. The certified infrastructure underneath stays ours.
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.
