Where to use what
May 20, 2026 · View on GitHub
Peppol exchange follows a four-corner model:
- C1 — the Sender (the business that creates the document, e.g. a supplier's ERP issuing an invoice)
- C2 — the Sending Access Point (technical sender, transmits on C1's behalf)
- C3 — the Receiving Access Point (technical receiver, receives on C4's behalf)
- C4 — the Receiver (the business that processes the document, e.g. a buyer's accounting system)
C2 and C3 are typically operated by service providers and run the same software in opposite directions. C1 and C4 are end-user applications.
Below, projects are mapped to the corner where you will most likely use them. Some libraries (validation, data models, identifiers) appear at more than one corner.
C1 — Sender (creating outbound documents)
Build a valid business document, choose Peppol identifiers, validate before handing off to C2, convert formats when needed.
- ph-ubl — UBL 2.x data model to build the invoice / order / credit note
- ph-cii — CII data model if you have to produce CII instead of UBL
- peppol-commons (
peppol-id) — predefined Peppol identifiers (Document Types, Processes, Participant Identifier Schemes) - phive + phive-rules + ddd — validate the document before handing it to C2 (
dddresolves the VESID forphive) - en16931-cii2ubl / en16931-ubl2cii — convert between CII and UBL when the back-office format differs from what you must send
C2 — Sending Access Point (outbound transmission)
Wrap the document in an SBDH, look up the receiver in an SMP, transmit via AS4, validate at the boundary, generate the required network reports.
- phoss-ap — turnkey Spring Boot Access Point (handles both C2 and C3)
- phase4 — AS4 protocol library (the engine inside
phoss-ap) - peppol-ap-support — AP-side helper functions
- peppol-commons (
peppol-sbdh,peppol-smp-client,peppol-id) — SBDH wrapping, SMP lookup of C3, identifiers - peppol-reporting — TSR / EUSR data model for the mandatory OpenPeppol network reports
- phive + phive-rules — boundary validation before sending
C3 — Receiving Access Point (inbound transmission)
Publish your endpoint in an SMP, receive via AS4, verify the signature and trust chain, unwrap the SBDH, validate, generate a Message Level Status (MLS — replacing the older Message Level Response / MLR, which is being phased out), generate the required network reports.
- phoss SMP — operate an SMP server to publish the C3 endpoint that senders look up (receive-side only)
- smp-mate — maintenance tool to bulk-provision participants in your SMP (German documentation)
- phoss-ap — same Access Point software as at C2
- phase4 — same AS4 library as at C2
- peppol-ap-support — same helpers as at C2
- peppol-commons (
peppol-sbdh,peppol-mls,peppol-mlr,peppol-id) — SBDH unwrapping, Message Level Status (MLS) generation; legacy Message Level Response (MLR) support viapeppol-mlris being phased out - peppol-reporting — TSR / EUSR generation
- phive + phive-rules — inbound validation; or run phorm as a standalone validation REST service that C3 calls
C4 — Receiver (processing inbound documents)
Parse the received document, re-validate, convert it to whatever format your back-office prefers.
- ph-ubl — parse UBL documents
- ph-cii — parse CII documents
- phive + phive-rules — re-validate the received document inside your application
- en16931-cii2ubl / en16931-ubl2cii — convert into the format your back-office prefers
- kaltblut — extract embedded XML from hybrid ZUGFeRD / Factur-X PDF invoices (useful when such invoices arrive alongside Peppol traffic)
Outside the corners — network infrastructure
These do not belong to a single corner. They support the Peppol network operated by OpenPeppol and the SMP service providers.
- smp-query-webapp — standalone SMP query service (pre-built Docker image)
- phoss Directory — operate a Peppol Directory server
- phoss Directory Client — query the Peppol Directory (used by SMPs and any participant)
- peppol-commons (
peppol-sml-client) — access the Service Metadata Locator (used by SMP servers when registering) - phoss-peppol-mcp — MCP (Model Context Protocol) server exposing Peppol Network capabilities as tools to AI models such as Claude
Country-specific add-ons
These augment whichever corner handles that country's specific rules — usually C2/C3 for transport peculiarities and C1/C4 for document-content rules.
- peppol-sk — Slovakia (SK)
- peppol-om — Oman (OM)
- peppol-uae — United Arab Emirates (UAE)
- peppol-vida — Peppol ViDA pilot