What Peppol actually means for your ERP team
Peppol is often explained as a network diagram. For ERP teams, the real questions are about formats, Access Points and status handling. Here is the practical view.
By Devitso Insights
Peppol is an open framework for exchanging electronic business documents between organizations — governed by OpenPeppol AISBL and used by a growing list of countries as the backbone for e-invoicing mandates. Most introductions stop at the four-corner model diagram. If you run an ERP landscape, that diagram answers almost none of your actual questions.
The questions that matter in practice are concrete: Which of our document flows are in scope — outgoing sales invoices only, or also orders and despatch advice? Which Peppol BIS profile applies, and how does our ERP data map onto its UBL structure? Which Access Point will carry our traffic, and how do delivery statuses and errors get back into the system our accounts team actually watches?
Format mapping is the real project
Connecting to an Access Point is a defined, bounded task. Mapping your ERP's billing output to a Peppol BIS profile is where the effort lives: tax categories, item identification, party identifiers, allowances and charges, rounding behavior. Every ERP has fields that almost fit, and the gap between “almost” and “valid” is what validation rules exist to catch.
Treat the mapping as a designed artifact with an owner, a test suite and a change process — not as a one-time configuration. Mandates evolve, profiles version, and your product catalog changes.
Statuses decide whether the project succeeds
An invoice that leaves your ERP and disappears into a network is a liability, not an achievement. The difference between a working Peppol integration and a painful one is almost always status handling: transport acknowledgements, business-level responses and rejections need to land back in a place where someone acts on them, with enough context to act correctly.
This is why we recommend designing the monitoring and exception path before the happy path. If your team can see every document's state and resolve a rejection without a support ticket to three parties, the integration will survive contact with reality.
Where to start
Start with an inventory: document types, countries, counterparties and the mandates that apply to each. From there, the architecture usually falls into place — one integration layer that normalizes, validates and routes, with Access Point connectivity as a configured endpoint rather than a hard-wired dependency.
The practical takeaway
Peppol connectivity is only one part of the project. Mapping, status handling and operational ownership determine whether the integration succeeds.
Planning a Peppol integration?
Explore how Devitso approaches ERP connectivity, validation, routing and status monitoring.