Multi-Country E-Invoicing API Explained: From XRechnung in Germany to PINT OM in Oman

A German invoice can be completely correct and still not be an Oman tax record. It was built to Germany's rulebook, and Oman checks against a different one. When a German supplier invoices a business in Oman, the invoice travels over Peppol and arrives unchanged as the buyer's purchase invoice. The buyer's Omani provider then builds a second document from it, a self-billed PINT OM invoice, and that is what gets reported to the Tax Authority. A multi-country e-invoicing API is the layer that knows which rulebook applies at each end, and does that work without either company changing its systems.

Key takeaways

• A German XRechnung invoice is valid in Germany, but it cannot become an Oman tax record: Oman validates against PINT OM.
• The invoice crosses Peppol unchanged and stays the Omani buyer's purchase invoice.
• The buyer's Omani provider builds a self-billed PINT OM invoice from it, only to generate the tax report. It is never sent to the German seller.
• The German supplier needs no Oman registration and no PINT OM for this flow.
• A multi-country e-invoicing API has four jobs at every border: look up, validate, derive and reconcile.

This page is for finance, tax and ERP teams at businesses that trade between Europe and the Gulf, and for the software vendors who serve them. It follows one invoice from a German ERP to an Omani ledger and names every rule it meets on the way. The Oman mechanics come from the Tax Authority's own Oman – Solution Reference Architecture v1.0.3.

What is a multi-country e-invoicing API?

A multi-country e-invoicing API is one integration that sends and receives compliant e-invoices in many countries, each under its own rules. Your ERP connects once. Behind that connection the provider finds out what each receiver accepts, validates each document against the right national specification, and adds whatever tax reporting the destination requires.

The value is not the transport. Peppol already moves documents between countries, using the same AS4 messaging and the same directory lookups everywhere. The value is in knowing that the transport is the same while the rulebooks are not. For the broader picture of what that integration covers, see GoRoute's global e-invoicing API, and our explainer on what a multi-country e-invoicing API is.

Why can't one invoice format work in every country?

Because every country publishes its own set of rules on top of a shared data model, and each invoice is checked against the rules it declares. Two families matter here.

In Europe, the shared model is EN 16931. Countries narrow it into national specifications, which the standard calls a CIUS (Core Invoice Usage Specification). Germany's is XRechnung. Peppol's pan-European one is Peppol BIS Billing 3.0. Both are recognisably the same invoice underneath.

Outside Europe, Peppol uses PINT, the Peppol International invoice model, and each country publishes a specialisation of it: PINT AE for the UAE, PINT A-NZ for Australia and New Zealand, PINT SG for Singapore, and PINT OM for Oman. We explain the relationship between the two families in Peppol vs PINT.

Every invoice announces its rulebook in one field, the CustomizationID, and that string decides which validation runs against it.

This is why a German invoice and an Omani invoice can travel on the same network and still be incompatible. A PINT OM document is never checked against the European rules at all. Oman's validation runs the shared PINT base pack of 170 assertions and then Oman's own pack of 154, covering national tax rules that no German specification was written to carry.

What is XRechnung, and when does Germany require it?

XRechnung is Germany's national e-invoicing specification: a CIUS of EN 16931, maintained by KoSIT, available in both UBL and CII syntax. It is mandatory for invoices to German federal public-sector buyers and one of the accepted formats for German B2B.

Germany's B2B mandate under the Growth Opportunities Act separates receiving from issuing:

• Since 1 January 2025, every domestic business must be able to receive EN 16931 e-invoices.
• From 1 January 2027, businesses above roughly EUR 800,000 in turnover must issue them.
• From 1 January 2028, all remaining domestic businesses must issue them.

Note the word domestic. Germany's mandate governs invoices between German businesses. An invoice to a customer in Oman is not what it regulates, which is exactly why Oman needs a rule of its own for invoices that arrive from abroad. The German detail, including ZUGFeRD, is in our Germany B2B e-invoicing guide.

What is PINT OM, and how is Oman different?

PINT OM is Oman's specialisation of PINT, and it is the format behind Fawtara, Oman's national e-invoicing programme. Omani participants are identified under scheme 0248, using the VAT identification number with its OM prefix.

The bigger difference is the model. Germany exchanges invoices on Peppol's four corners: seller, seller's provider, buyer's provider, buyer. Oman adds a fifth: the Tax Authority's gateway, which receives a tax data document about each invoice from the providers involved. Tax reporting is not a separate filing. It is built into the exchange.

Tax Authority Decision 189/2026 sets the mandatory dates: 1 April 2027 for taxable persons whose annual supplies exceed OMR 5,000,000, and 1 October 2027 for those at or below that threshold. More on the Oman rules is on our Oman page.

What happens when a German supplier invoices a business in Oman?

The invoice crosses Peppol unchanged, and Oman's tax record is built on the buyer's side of the border. Oman's architecture calls this the import scenario, and it runs in five steps.

1. Issue. The German supplier's ERP produces an EN 16931 invoice. For a domestic customer that is typically XRechnung. For a foreign Peppol buyer, the format is whatever the buyer's directory entry says it accepts. The sender's access point checks this before sending.
2. Send. The supplier's access point finds the Omani buyer on Peppol and delivers the invoice over AS4. On the network it is a Peppol BIS invoice, not a PINT OM one.
3. Deliver. The Omani buyer's accredited provider receives it and hands it to the buyer, unchanged. It is the buyer's purchase invoice, and nothing about it is rejected.
4. Derive. Because this invoice cannot produce an Oman tax data document, the same provider builds a self-billed PINT OM invoice in the buyer's name, from the data on the German invoice.
5. Report. The provider generates a tax data document from that self-billed invoice and sends it to the Tax Authority's gateway, which returns a status message.

The architecture is direct about why step four exists. The import invoice, "Peppol or non-Peppol", "cannot be used to produce a TDD by Oman Invoice Receivers, because it cannot be guaranteed that the Invoice can provide all required data necessary for creating an OM TDD". So the buyer's provider "will produce a self-billed PINT Invoice to be able to generate a TDD for tax reporting purposes."

Is the German invoice converted into PINT OM?

No, and the difference matters for audit. The German invoice is not rewritten, re-issued or replaced. It stays exactly as the supplier sent it. The Oman document is derived from it, not a translation of it.

Two documents from one purchase have different jobs:

• Pay and reconcile against the German original. It is the document your supplier will discuss, chase and credit.
• The self-billed PINT OM invoice carries the report. The architecture says it "will not be sent to the original seller, it is only used to generate the TDD." Your German supplier never learns it exists.

If the self-billed document is wrong, the correction is a self-billed correction raised on the buyer's side. Your supplier cannot credit an invoice they never saw. The codes a self-billed correction must carry are covered in correcting a self-billed invoice in Oman, and the full import case in what happens when an invoice reaches Oman from abroad.

What about invoices going the other way, from Oman to Germany?

The Omani seller's provider reports the export to the Tax Authority, and the invoice itself goes to the German buyer in a format that buyer accepts. Oman's architecture lists the export case as a tax data document from the seller's provider to the Authority's gateway, with a status message back. The German buyer is outside Oman's system, so there is no Oman reporting leg on their side.

The rule for the format is the same as before: the sender reads the receiver's directory entry and sends what it advertises. For a German buyer on Peppol that is typically an EN 16931 specification, not PINT OM.

What should a multi-country e-invoicing API handle for you?

Four jobs, at every border, and only one of them is visible when things go right.

1. Look up before sending. The receiver's SMP entry says which document types it accepts. Sending anything else is a delivery failure waiting to happen.
2. Validate against the declared rulebook, including Schematron, before the document leaves. A document that fails validation should never reach the network.
3. Derive what the destination requires. In Oman that means the self-billed invoice and the tax data document on an import. Other regimes have their own equivalents.
4. Reconcile what was sent against what the authority acknowledged. A delivered invoice with a rejected tax report is a compliance problem that nobody notices until an audit.

The last job is where most integrations are thinnest. An invoice that arrived is easy to see. A tax report that never got a positive status message usually isn't.

Where GoRoute fits

GoRoute is a certified Peppol Access Point and SMP under Seat ID POP000991, and an OTA-accredited e-invoicing service provider in Oman, accredited on 29 July 2026 via Union Digital Technologies SPC.

On the German side, GoRoute sends and receives EN 16931 documents, including XRechnung, over Peppol. On the Omani side, it passed every PINT OM v1.0.1 conformance suite on 30 July 2026, including Self-Billing and Billing & TDD. The self-billed invoice and the tax data document are the two documents an import produces.

Every document is validated against the full rule set its CustomizationID declares, Schematron included, before it leaves. Because GoRoute sits in the transaction path, it can reconcile what was issued against what the authority acknowledged, and turn each exception into audit-ready evidence rather than a dashboard metric. The country rules are on our Germany and Oman pages, and the endpoints are in the developer documentation.

If you trade between Europe and the Gulf, you integrate once. Book a demo and we will walk one of your own invoices through both rulebooks.

Sources: the Oman – Solution Reference Architecture v1.0.3 of 27 July 2026 (Final; OpenPeppol AISBL with the Oman Tax Authority), sections 6.5 and 9; the PINT OM specification v1.0.1, published at docs.peppol.eu; Tax Authority Decision No. 189/2026, Official Gazette 1660, 9 August 2026, with Oman's e-invoicing material published by the Tax Authority; KoSIT XRechnung; OpenPeppol BIS Billing 3.0; EN 16931.