Cross-border e-invoices via PEPPOL

What PEPPOL is, in plain terms

It is a pan-European document delivery network. The logic is like e-mail: you have your operator, the recipient has theirs, and the network makes sure the document travels between them under the same rules.

That is why an e-invoice to Finland or Germany does not require you to have a contract with their systems — it is enough that both sides are participants.

Two routes in X7

When you click Send as e-invoice, X7 picks one of two paths:

The recipient is Estonian. X7 checks the Estonian registry of recipients: the company must be listed there and have an operator. If not, sending stops with a clear message.

The recipient is foreign. The cross-border route is used: the operator receives the recipient's registry code and country, and from there the document travels the network to their access point.

X7 builds the Estonian XML and the PDF; delivery and matching the document to the recipient's profile are the operator's job.

The country field decides

The route follows the recipient's country, taken in this order:

1. the details frozen on the invoice itself;
2. the client record;
3. if empty — Estonia.
   

The third step is the source of the most frequent error: a foreign client has no country, X7 treats them as Estonian and looks them up in the Estonian registry. In that case the message says outright that the country is not set: “The buyer was not found in the Estonian e-invoice registry. The client's country is not set …”. The invoice itself is perfectly correct — one empty field is the whole problem. If the country field holds text X7 cannot recognise (a misspelling, say), sending stops with “The buyer's country … was not recognised” — use a two-letter code.

Warning

Check the client's country before the first send. If the invoice already exists, remember that it holds a snapshot of the details as of its creation — editing the client record afterwards does not change a document already issued.

The participant identifier

On the network a participant is identified by a “scheme + value” pair: the scheme says which code the country uses, the value is the code itself. For Estonia that is scheme 0191 and the company's registry code.

You do not enter this pair by hand in X7 — it is assembled from the code and the country. But it is worth knowing: when a client insists the e-invoice “never arrived”, the conversation quickly comes down to which identifier they are registered under.

VAT on a cross-border invoice

Almost all such invoices are services or goods to an EU business client, which means reverse charge. Two requirements are broken most often:

• the buyer's valid VAT number on the document;
• a reverse charge note in the invoice text.
  

An invoice without them will still be sent, but it can be rejected at the recipient's end — slower and more annoying than an error while sending.

Reverse charge: invoicing an EU client · How to check a counterparty

If delivery failed

1. Open the stored operator response — it sits next to the sent XML and PDF.
2. Check the recipient's country and registry code.
3. Ask the client whether they are registered on the network and under which identifier.
4. Until that is settled, send a PDF so payment is not held up.
   

Where this is heading

More and more EU countries are introducing mandatory structured invoicing between businesses, and almost everywhere the shared baseline is the same PEPPOL profile. The practical conclusion is simple: a carefully filled country, registry code and VAT number on the client record are not bureaucracy — they decide whether the invoice arrives.