Guide
PEPPOL in the EU: how exchange actually works
PEPPOL is a 4âcorner network where your access point delivers invoices to the recipientâs access point. Success is mostly about correct addressing (participant IDs), profile alignment, and validationânot about âsending an email with XMLâ.
The 4-corner model in one minute
Corner 1 is you (the sender), corner 2 is your access point. Corner 3 is the recipientâs access point, corner 4 is the recipient. Routing happens between access points based on a recipient participant ID.
This article treats PEPPOL in the EU: how exchange actually works as a practical reference, not just a navigation page. It explains the term or workflow in context, shows why it matters for European e-invoicing, and connects the topic to invoice creation, validation, routing, archiving, and ERP implementation decisions.
Participant IDs and endpoint discovery
A participant ID combines a scheme and a value (for example a business identifier). The scheme matters: a valid-looking number can still fail if the scheme is wrong.
In projects, âwe canât deliver invoicesâ is frequently an addressing issue: wrong scheme, wrong ID, or the recipient is not registered for the document type/profile you use.
Profiles: BIS vs CIUS (why âjust UBLâ is not enough)
PEPPOL BIS defines specific invoice rules and constraints on top of UBL. Many countries then apply CIUS rules to align with national requirements.
Treat the profile as a contract: if you generate âgeneric UBLâ, you will likely fail schematron validation.
Validation and code lists (units, VAT categories, payment means)
Even if routing works, invoices can still be rejected for wrong code list values (e.g., unit codes), inconsistent totals, or missing business references.
Make code lists part of your user input validation and test suite.
The 4-corner model in one minute
The 4-corner model in one minute is where the general explanation of PEPPOL in the EU: how exchange actually works becomes operational. The section focuses on You do not send to an email address; you send to a participant ID, The recipient chooses their access point and Profiles and validation rules must match (BIS/CIUS), so it can be used to check the required fields, process decisions, and validation controls before the invoice workflow is used in production.
- You do not send to an email address; you send to a participant ID
- The recipient chooses their access point
- Profiles and validation rules must match (BIS/CIUS)