The GoRoute e-invoicing portal is where a business sends invoices to its customers, receives them from its suppliers, and sees what happened to every document in one register. It validates each invoice against the destination country's own rules before delivery, keeps the archive an auditor asks for, and exposes the same actions through a REST API.
The 8-minute recording below is one unbroken pass through the running portal. The same walkthrough is written out further down the page, stage by stage, if you would rather read it than watch it.
Below is the recording written out, stage by stage and in its own order, so the page answers what the portal does without anyone pressing play. Nothing in the video is mocked up — it is the running portal, recorded in one pass — and nothing here describes a screen the recording does not show.
It is the browser interface to a Peppol-certified access point, and the place a finance, tax or IT team works day to day. Invoices go out to customers from it, supplier invoices arrive into it, and every document that moves either way keeps its record there. The REST API and the ERP connectors drive the same platform underneath; the portal is the view of it that needs no code.
Two things have to exist before any of it works, and the help centre's getting-started steps cover both: an account with a completed organisation profile, and a registered Peppol participant identifier. That identifier is your address on the network. You choose a scheme such as GLN or VAT, register the identifier, and set which document types you are willing to receive. Until that is done, other businesses have nowhere to send to.
The dashboard is the first screen after sign-in, and it exists to answer one question without opening a single document: what happened to the invoices. It summarises the traffic through the account — what has gone out, what has come in, and what has not finished — so an exception surfaces before a customer telephones about it. The recording opens here and then moves into the lists behind those figures.
Sales invoices are the documents going out. The portal holds them as a list of what the business has issued, and opening a row shows the invoice itself alongside the validation result and the delivery record behind it — not a status word on its own, but the evidence for it.
Invoices reach that list three ways, and the portal treats them identically once they arrive: entered or uploaded in the portal, pushed across by an ERP or accounting connector, or posted to the REST API. That matters more than it sounds. It means a business can start by working in the portal and move to an integration later without changing where anyone looks for the answer.
Receiving is the half most businesses forget to plan for. Once the participant identifier is registered and the document types are set, a supplier's access point delivers straight into the account and the invoice appears in the portal. No PDF emailed to a shared mailbox, and nobody rekeying it. What arrives is a structured document rather than a scan, so the figures are already machine-readable by the time anyone looks at them.
Where an integration is listening, the same arrival fires a document.received webhook, which is how an ERP learns about a supplier invoice without anyone opening the portal at all.
Sent and received documents also sit together in one register. The two separate lists answer directional questions — did this invoice reach this customer — and the combined register answers chronological ones: what moved on this account, in order, over a given period. It is the list to reach for when the question starts with “when” rather than “who”, and it is where the recording goes to show a whole period of traffic at once.
Every document passes the same compliance gate before it leaves, and that gate has five layers: UBL 2.1 XSD, business rules, eDEC code lists, the baseline CEN EN16931 and Peppol BIS Billing 3.0 Schematron, and whichever jurisdiction pack applies — PINT Oman, PINT Australia–New Zealand, PINT EU, Singapore, Malaysia or Japan, or a national CIUS such as XRechnung for Germany. The right pack is selected from the document's own CustomizationID, and the result reports which packs matched.
A failure at this stage is almost always a business-rule violation rather than a broken file. The three the help centre sees most are a missing mandatory field, tax and line totals that do not reconcile, and a currency, unit or country code outside the ISO list.
Past the gate, a document moves through queued → sending → sent, and a failure carries a reason rather than a silence: TIMEOUT, VALIDATION_ERROR or RECIPIENT_NOT_FOUND. Failed deliveries are retried automatically and the transaction log holds the detail. A status still showing pending after 24 hours is the point to raise it with support, quoting the transaction identifier.
Most invoices are not typed into a portal. They already exist in the system that produced them, and GoRoute's connectors carry them across without changing how finance works. Each has its own recording: Odoo, TallyPrime, Microsoft Dynamics 365 Business Central, Zoho Books, Oracle APEX, and Microsoft Excel for a business with no ERP integration at all.
Underneath, every one of them does what a direct integration does: post the UBL document to the REST API, take back an acceptance and a message identifier, and follow the lifecycle from there. That is why an invoice raised in Odoo and an invoice raised in the portal end up in the same register carrying the same kind of record. A connector is a route in, not a separate system.
Both are settings in the portal, and this is the chapter developers usually come for. An API key is generated in the dashboard and passed on every request in the X-API-Key header. It is scoped to your organisation, so every query behind it is filtered to your own tenant — certificates, keystores, participant identifiers, webhooks and audit trails are isolated the same way. Keys can be rotated, and a 401 or 403 immediately after a rotation almost always means an old key is still sitting in the caller.
Webhooks are configured in the same place. GoRoute posts document.received, document.validated, document.sent, document.failed and document.delivered to the URL you set, with HMAC-signed payloads, retries with exponential backoff and dead-letter logging. That is what lets an ERP show a delivery status without polling for it.
To try it before wiring anything to a live account, the developer programme issues a 14-day sandbox with an sk_test_ key, the full validation gate, and four deterministic 9999:test-* receivers that reproduce success, timeout, validation failure and recipient-not-found end to end.
The last working stage of the recording is the part an auditor asks about. Every invoice, validation result, delivery receipt and tax submission is archived with timestamps and audit logs, and the original UBL XML is kept alongside — so the legal document itself is there to retain for whatever period your jurisdiction requires, rather than a rendering of it.
In practice that turns an audit request from a search through mailboxes into a query against one register: which documents went to a given counterparty, what each of them was validated against, and when the receiving access point acknowledged them.
Yes, and it is deliberately brief here because it is another page's subject. The same platform covers 40+ countries through one interface, both Peppol delivery and the jurisdictions that require an invoice to be cleared by a tax authority before it reaches the buyer. The country detail sits on the global e-invoicing page, and the platform-level tour is the separate global platform demo. This page stays on the portal screens.
Three groups, and the recording's closing argument is that they need one portal rather than three tools. Finance works in the sales and purchase lists. Tax and compliance live in the validation results and the archive. IT and the ERP owners work in connectors, API keys and webhooks. Split those across separate systems and a delivery failure ends up owned by nobody.
Send invoices to customers, receive them from suppliers, see both in one register, check what each document was validated against and how far its delivery got, generate API keys and webhooks, and pull records back out of the archive. The 8-minute recording on this page covers all of it in one pass.
No. Invoices can be created or uploaded in the portal itself, or sent from a spreadsheet using Connect for Excel, which exists for businesses with no ERP integration at all. An ERP connector is a route in, not a requirement.
Register a Peppol participant identifier and set which document types you accept. Once that is in place a supplier's access point delivers straight into your account and the invoice appears in the portal, structured rather than as a PDF.
In the portal. The key goes in the X-API-Key header on every request and is scoped to your organisation. Developer sandbox keys are prefixed sk_test_ and limited to 30 requests a minute and 1,000 a day.
It does not leave, and the failure names the rule it broke rather than failing quietly. The usual causes are a missing mandatory field, tax and line totals that do not reconcile, or a currency, unit or country code outside the ISO list.
Every invoice, validation result, delivery receipt and tax submission, with timestamps and audit logs, and the original UBL XML alongside so the legal document itself is retained rather than a rendering of 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.
