E-invoice sending and tracking software turns an invoice from your billing system into the structured document your customer's country requires, checks it against that country's rules before it leaves, delivers it over Peppol as a certified access point, and records what happened to it. GoRoute is an e-invoice dispatch platform rather than a mail merge: every document carries its own validation result, its dispatch state and its delivery receipt, so “did the customer get it” is a query against one register instead of a phone call.
Four steps, and a failure stops at the first one that fails
E-invoice sending and tracking software converts a customer invoice into the structured format that customer's country accepts, validates it against that country's rules before dispatch, delivers it over an e-invoicing network on your behalf, and holds a state per document through to a delivery receipt. Emailing a PDF sends a picture of an invoice and tells you nothing afterwards. An electronic invoice sending software sends a document a machine can post to a ledger, and can prove where it went.
The tracking half is what teams underestimate. A sending project is usually scoped as a format problem — produce the right XML — and format is the easy part, because a validator will tell you when you have it wrong. What costs money later is not knowing the state of an invoice that has left: whether it was accepted, whether it reached the buyer's system, and whether the silence on an overdue account is a collections problem or a delivery problem. An e-invoice sending solution worth buying answers that without anyone opening a support ticket.
This page is about what the platform does with an invoice you send. The other direction — what happens to invoices your suppliers send to you — is on the e-invoice receiving page. Country coverage and the compliance scope are on the global e-invoicing platform page; the endpoints and the interface are on the API services page.
If you would rather watch it than read it, the video walkthroughs show real invoices leaving SAP, Oracle, Dynamics 365, Odoo, Zoho Books, TallyPrime, WooCommerce and Excel, unedited and end to end.
Four steps. A document that fails one of them stops there rather than going out broken.
UBL 2.1, JSON or CSV goes in; out comes the profile the recipient's country requires, chosen for you rather than configured per customer
Checked against the Schematron rules for that profile before dispatch. A failing invoice comes back with the rules it broke
The recipient is looked up in the SMP, then the document is handed over AS4 to their access point, which returns a receipt
The state sits on the document in the register, and fires as a document.delivered webhook to your system
Step two is the one that pays for itself. A validator that runs before dispatch turns a compliance failure into a message you read in seconds; a validator that runs at the far end turns it into a rejection you learn about days later, from a customer who is now not paying you. If you want to run that check on its own — in a test harness, or as a gate inside your own billing job — there is a separate validation endpoint that returns the same result and sends nothing. It is documented on the API services page.
A state per document, and the evidence behind it. Sales documents have their own list in the portal, purchase documents have theirs, and both sit together in one combined register. The separate lists answer directional questions — did this invoice reach this customer. The combined register answers chronological ones: what moved on this account, in order, over a given period.
Each entry carries what the document was validated against, how far it got, and the timestamps around it. The archive keeps the original UBL XML alongside the record rather than a rendering of it, with validation results, delivery receipts and audit logs. That matters on the sending side for a reason it does not on the receiving side: when a customer disputes that an invoice was ever issued, the delivery receipt from their own access point is the answer, and it is a stronger answer than a sent-items folder.
For an integrated team the same states arrive as events. GoRoute posts document.sent, document.validated, document.received, document.failed and document.delivered to the URL you set, with HMAC-signed payloads, retries using exponential backoff and dead-letter logging. Automated e-invoice transmission means nothing without that last part: a queue that retries and then records what it could not deliver is the difference between an integration you can trust and one somebody checks by hand every morning.
The network, the validation and the tracking are the same in all three. Only where the invoice starts changes.
No integration, no ERP. Invoices are raised and sent in the browser, with the register and the archive in the same place. This is a complete answer for a team issuing tens of invoices a month, and it is where most businesses start.
See the portal walkthrough →Odoo, TallyPrime, SAP, Oracle, Microsoft Dynamics 365 and Sage each have a documented path, and Connect for Excel exists for teams whose invoices live in a workbook.
All connectors →One REST endpoint behind an API key, taking UBL 2.1, JSON or CSV, so a whole billing run can be posted without anyone transcribing it. The developer programme issues a sandbox to try it against before anything touches a live account.
Peppol API integration →It is a fair question to ask any provider, and the answer is not always the company on the invoice. Sending over Peppol requires a certified access point to hand the document over, and a Service Metadata Publisher — an SMP, the directory entry that says which documents a participant accepts and where delivery goes. GoRoute is certified for both under POP000991, so the dispatch and the receipt are ours to show rather than a third party's to be asked for.
That is also what secure e-invoice sending software comes down to in practice. Delivery is over AS4, which signs each transfer and returns a receipt for it, so the proof that a document moved is produced by the protocol rather than asserted by a dashboard. Webhook payloads to your own endpoint are HMAC-signed for the same reason: your system should be able to tell a real event from a replayed one. The certifications and standards behind the platform are listed on the technical factsheets page.
The choice of e-invoice network software is largely this choice. A reseller can connect you through another company's access point, which works, but the record of your address, and the ability to change it, sits one party further away. A provider or group that needs to hold its own customers' entries under its own identity can run SMP-as-a-Service instead, and registration on Peppol is where an individual entry is managed. If the vocabulary is new, what a Peppol access point is explains the four-corner arrangement in plain terms and how to choose one sets out what to compare.
Most e-invoice sending software demos well, because a successful send is easy to show. The differences live in what happens when something goes wrong, and these are the questions that surface them. They are worth asking of us as much as of anyone else.
On the last two: the developer programme issues a 14-day sandbox with four deterministic test receivers that reproduce success, timeout, validation failure and recipient-not-found, so all three failures can be rehearsed rather than discovered. And the country rulebook belongs on the country page rather than here — which profile applies where, and whether a tax authority also has to see the document, is set out per market on the global platform page and the country pages it links to.
Thirty minutes on your own invoice data: one document validated, dispatched and tracked to its delivery receipt, plus a failed send so you can see what your team would actually be handed. If you would rather look first, the walkthroughs and the API documentation are open.
E-invoice sending and tracking software turns an invoice from your billing system into the structured document your customer's country requires, checks it against that country's rules before it leaves, delivers it over a network such as Peppol, and records what happened to it. The tracking half is the part a PDF by email cannot do: the software holds a per-document state and a delivery receipt, so “did the customer get it” is a query rather than a phone call.
Four things, in order. The document is converted into the profile the recipient's country requires. It is validated against the Schematron rules for that profile. The recipient is looked up in the SMP, the Peppol directory entry that says which documents they accept and where delivery goes. Then it is handed over AS4 to the recipient's access point, which returns a receipt. Each of those steps is a state on the document rather than a step you have to watch.
No. Invoices can be raised and sent entirely in the portal, which is where most businesses start. A connector into the accounting system you already run, or the REST API, are routes out rather than requirements, and you can add one later without changing your address on the network.
Through a webhook. GoRoute posts document.sent, document.validated, document.received, document.failed and document.delivered to the URL you set, with HMAC-signed payloads, retries using exponential backoff and dead-letter logging. That is what lets a collections queue show an undelivered invoice without anyone polling for it.
It is not dispatched. Validation runs before the document leaves, so a failing invoice comes back to you with the rules it broke instead of being rejected days later by the recipient or a tax authority. If you would rather check without sending, there is a separate validation endpoint that returns the same result and dispatches nothing — it is described on the API services page.
You find that out before you send, not after. The SMP lookup is what tells you whether a participant identifier exists and which documents it accepts, so an unreachable recipient fails at the addressing step. A customer who is not registered has to be reached another way until they are, and their registration is their own provider's job rather than yours — the receiving side explains what they need in place.
Yes. The API accepts UBL 2.1, JSON or CSV, so a run of invoices exported from a billing system can be posted without anyone transcribing them. For a team whose invoices live in a workbook, Connect for Excel sends Oman Fawtara invoices from the sheet itself, validating each against PINT OM v1.0.1 on the way out.
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. Testing the failures is the point: a sending integration is judged on what it does when a document is rejected, not on the happy path.
The mechanics are the same wherever delivery is over Peppol: your own identifier, the recipient's identifier, validation against a profile, and an access point that hands the document over. What differs is which profile applies and whether a tax authority also has to see the invoice. Those requirements are set out on each country page rather than here.
Whether it is a certified access point in its own right or resells someone else's, whether validation runs before dispatch or after, what states a document moves through and whether you can see them, what proof of delivery you are given, whether a team can send without an ERP, what the input formats are, who updates the validation rules when a country changes them, and whether you can rehearse a failed send in a sandbox first.
What a business must send, in what format, and by when is set by its own tax authority and changes over time. This page describes how sending works on the GoRoute platform; confirm the current obligation for your market on the relevant country page and with the authority itself.
