Peppol’s four-corner model: how an e-invoice arrives

Peppol’s four-corner model (4-corner model) means an e-invoice travels between seller and buyer through four parties: C1 is the seller, C2 is the sending service provider the seller has chosen, C3 is the receiving service provider the buyer has chosen, and C4 is the buyer. The standard route is C1 → C2 → C3 → C4, with C2 converting the seller’s invoice into a standard Peppol e-invoice and C3 converting it again into a form the buyer’s system can read. You don’t need the same operator or the same software as your customer, because one connection to one service provider is enough for any sender and any receiver to reach the whole network. And in Estonia, an e-invoice requirement doesn’t automatically mean Peppol. The Ministry of Finance works from a principle of format freedom, and both the Estonian and the European e-invoice standard are in use.

How a €1,200 invoice gets from your software into your customer’s books

Take a concrete case. You invoice an Estonian client for €1,200, and that client is registered in the business register as an e-invoice recipient.

• C1 (you): you create the invoice in your sales software and hit “Send”. As far as your work goes, it ends there.
• C2 (your operator): the sending Access Point, your operator’s technical gateway into the network, turns your invoice into a compliant Peppol message and must validate it against the Peppol BIS rules before sending, meaning it checks that the required fields and the structure match the standard.
• Finding the address: C2 asks a central lookup service (Service Metadata Locator, SML) which capability register (Service Metadata Publisher, SMP) holds your client’s details, then reads from there which documents that client is actually able to receive.
• C3 (your client’s operator): receives the invoice and reshapes it for your client’s accounting software.
• C4 (your client): the €1,200 purchase invoice appears in their accounting in machine-readable form, with nobody retyping a single number.

One boundary matters here. Validation is technical. The sending Access Point does not confirm that the invoice is commercially correct or that your client agrees to pay it. A dispute over price or quantity is still settled between you and your customer.

Why Peppol isn’t an invoice portal

This is the most common mix-up. SML and SMP exist for finding addresses and receiving capabilities; think of them as an electronic address book. There is no shared environment where a seller “uploads” an invoice and a buyer “downloads” it: the invoice moves directly between service providers. The end user doesn’t need to be an OpenPeppol member either, but their receiving capability has to be published in the network — otherwise nobody on the sending side can find them at all.

Does Estonia’s e-invoice requirement mean Peppol?

No. Estonia introduced a general obligation in 2019 to issue an e-invoice when the buyer is a public-sector body. In 2025 that was replaced by a buyer’s-choice model that extended to the private sector: an e-invoice may be demanded by any accounting entity that has registered itself as an e-invoice recipient in the e-Business Register (Accounting Act § 7¹ (7)). Unless you agree otherwise, the seller then has to issue an e-invoice. The amendment to the Accounting Act entered into force on 1 July 2025, and the register also records the recipient’s e-invoice operator identifier or other receiving channel. So the requirement is about the format and the channel the buyer has published. Peppol is one widespread way to deliver it, not the only one the law recognises.

The Peppol network, EN 16931 and ViDA are three different things

Most of the confusion comes from treating these three as one thing.

Peppol’s four-corner model is a delivery network and a set of agreements: who connects to whom, how an address is found, how a message arrives securely.

The European e-invoice standard (EN 16931) is an agreement on the content and structure of the invoice itself. Article 7 of Directive 2014/55/EU requires contracting authorities to receive and process e-invoices that comply with the European standard in public procurement, but it does not name Peppol as the one mandatory delivery channel.

ViDA is a VAT reporting reform. The package was adopted on 11 March 2025 and published in the Official Journal of the European Union on 25 March 2025; Member States must adopt the measures by 30 June 2030 and apply them from 1 July 2030 for digital reporting of cross-border transactions. That concerns reporting, not whether Peppol is compulsory. None of these dates makes the four-corner model legally mandatory in itself, and none of them forces every domestic B2B invoice through Peppol.

In practice this comes down to two things. Today, what counts is the receiving channel your customer has entered in the business register. By 2030, what counts in addition is whether the data behind your cross-border sales exists in structured form. A machine-readable invoice already does that part of the work for you.

Also available in: eesti keeles

Last reviewed: 21 September 2026

FAQ

Mis on Peppoli nelja nurga mudel ja kes on selle osalised?

Peppoli nelja nurga mudel kirjeldab e-arve liikumist müüjalt ostjani nelja osalise kaudu: C1 on müüja, C2 müüja Access Point, C3 ostja Access Point ja C4 ostja ise. Mudel tagab koostalitusvõime, võimaldades osapooltel arveid vahetada ilma sama operaatorit või raamatupidamistarkvara kasutamata.

Kas Eesti e-arve kohustus nõuab Peppoli võrgu kasutamist?

Ei, Eestis kehtib formaadivabaduse põhimõte ning Peppol on vaid üks paljudest edastuskanalitest. Alates 1. juulist 2025 võib ostja nõuda masinloetavat e-arvet, kuid müüja edastab selle kanali ja käitleja kaudu, mille ostja on äriregistrisse märkinud.

Mis vahe on Peppoli võrgul, EN 16931 standardil ja ViDA direktiivil?

Peppol on tehniline edastusvõrk ja reeglistik dokumentide turvaliseks kohaletoimetamiseks, samal ajal kui EN 16931 määratleb e-arve semantilise andmesisu ja struktuuri. ViDA on Euroopa Liidu käibemaksureform, mis kehtestab alates 1. juulist 2030 piiriülestele tehingutele kohustusliku standardiseeritud digiaruandluse.