# 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.

## Checklist: The 4-corner model in one minute

- 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)

## 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.

## Related resources

- [PEPPOL network guide (overview)](/resources/compliance/peppol-network-guide)
- [Code lists for invoices](/resources/code-lists)
- [Netherlands country guide](/resources/countries/nl)