One JSON invoice, sent with one call to GoRoute’s API, comes out in the format each buyer needs: Peppol BIS 3.0 in Europe, PINT A-NZ in Australia and New Zealand, PINT OM in Oman, XRechnung for German public buyers, ZUGFeRD / Factur-X by email, or a filing with the tax authority in Spain and Nigeria. You do not choose the format; GoRoute chooses it from the buyer’s country and Peppol registration.
This page is the recording written out, chapter by chapter, for anyone who would rather read than watch. Watch the recording on its own page.
Because each market settled on its own. Europe exchanges Peppol BIS Billing 3.0, German government buyers want XRechnung, Australia and New Zealand use their own edition of Peppol, Oman adds a Tax Data Document for its Tax Authority, and some countries want the invoice at the tax authority rather than at the buyer. Building and maintaining each of those yourself takes months per country. With GoRoute it is one API call, and the format is GoRoute’s problem.
The same fields everywhere: a document type, a number, an issue date and a currency, the seller and the buyer, and the lines. There is no format field to fill in; document_format defaults to auto.
POST /api/v1/invoices
{
"invoice": {
"document_type": "invoice",
"number": "INV-2026-0042",
"issue_date": "2026-10-20",
"currency": "EUR",
"seller": { "name": "Example Seller GmbH", "vat_number": "DE123456789",
"address": { "country": "DE" } },
"buyer": { "name": "Example Buyer BV", "peppol_id": "0208:0000007720",
"address": { "country": "BE" } },
"lines": [
{ "description": "Consulting", "quantity": 10, "unit_price": 120, "tax_rate": 21 }
]
}
}The field reference is in the quickstart; the identifiers above are test values.
In three steps. First it reads the buyer’s country. Second, it asks the Peppol network which documents that buyer is registered to receive. Third, it renders the invoice in that format and checks it against that format’s rules before it goes anywhere, so a document that would be refused never leaves.
PINT A-NZ, the Australian and New Zealand edition of Peppol, not Peppol BIS 3.0 and not XRechnung. The buyer’s country decides it, not the seller’s. The recording uses this to set up the six routes that follow.
| Buyer in | Format produced | Where it goes |
|---|---|---|
| Europe, the UK, Norway and other Peppol countries | Peppol BIS Billing 3.0, plus national rules where they apply (Norway’s EHF checks, for example) | Delivered to the buyer over Peppol |
| Australia, New Zealand | PINT A-NZ, including self-billing | Delivered over Peppol |
| Oman | PINT OM | Delivered over Peppol, and the Tax Data Document filed with the Oman Tax Authority |
| Germany, public-sector buyers | XRechnung, when the buyer accepts only XRechnung on Peppol | Delivered over Peppol |
| Germany or France, businesses not on Peppol | ZUGFeRD / Factur-X: a PDF with the invoice data inside | Sent by email |
| Spain, Nigeria | Verifactu, NRS | Sent to the tax authority |
Stop one is the Peppol world at large, where national rules ride on top of BIS 3.0 (Norway is the example). Stop two is Australia and New Zealand; PINT A-NZ is explained here. Stop three is Oman, where GoRoute also files the Tax Data Document with the Tax Authority. Stops four and five are Germany and France: XRechnung when a public buyer accepts only XRechnung on Peppol, and ZUGFeRD / Factur-X by email for businesses not on Peppol (the German rules in full). Stop six is Spain and Nigeria, where the same call goes to the tax authority instead.
One invoice, one buyer, one format. An invoice is rendered for its buyer. To see the same invoice as XRechnung or UBL without sending it, use POST /api/v1/invoices/preview-xml.
You can override the choice. document_format takes auto, ubl, xrechnung, cii or zugferd. Oman is always PINT OM.
The format is automatic; the facts are not. An Australian buyer needs an ABN, an Omani seller needs a VAT number and line codes, and a German public buyer needs a Leitweg-ID. POST /api/v1/invoices/validate tells you exactly what is missing before anything is sent.
With the quickstart and a free sandbox: write the invoice once, validate it, send it, and let the buyer’s country decide the rest. The country guides list what each country requires.
It shows the formats GoRoute produces today. The UAE’s PINT AE is built but not yet switched on, and Singapore, Japan and Malaysia are not yet live. It does not cover receiving invoices, webhooks or pricing; the documentation does.
Yes. You send the same JSON structure to POST /api/v1/invoices whatever the buyer's country, and GoRoute renders it in the format that buyer's country and Peppol registration call for: Peppol BIS Billing 3.0, PINT A-NZ, PINT OM, XRechnung or ZUGFeRD / Factur-X, or a filing with the tax authority in Spain or Nigeria.
It reads the buyer's country, asks the Peppol network which documents that buyer is registered to receive, then renders the invoice in that format and checks it against that format's rules before sending. A buyer in Sydney, for example, gets PINT A-NZ.
Yes. The document_format field takes auto, which is the default, or ubl, xrechnung, cii or zugferd. Oman is the exception: an Omani invoice is always PINT OM.
Not as a send. One invoice has one buyer, so it is rendered in one format. To see the same invoice as XRechnung or UBL without sending it, use POST /api/v1/invoices/preview-xml.
No. The format is chosen for you, but the facts each country requires must be in the invoice: an Australian buyer needs an ABN, an Omani seller needs a VAT number and line codes, and a German public buyer needs a Leitweg-ID. POST /api/v1/invoices/validate tells you exactly what is missing before anything is sent.
Spain's Verifactu and Nigeria's NRS. The same API call sends the record to the tax authority rather than delivering a document over Peppol.