Building Peppol into an ERP system, accounting package or your own software product involves two decisions. The first is architectural: how does your software connect to the Peppol network? The second is practical: what should the API of a Peppol Service Provider offer to make that connection reliable and scalable? This page compares the three common architecture patterns and gives a checklist for assessing an API. Field mapping and detailed validation rules are outside its scope. For the underlying standard, see the page on EN 16931.
Three architecture patterns
No single pattern is always the best choice. The right one depends on your scale, how much control you want over the process, and how much capacity you have for your own maintenance.
Connector in the package
Integration via the API of a Peppol Service Provider
Own middleware
What to look for in an API
If you integrate through an API, whether directly or through middleware, the quality of that API largely determines how much work the integration takes and how stable it stays.
API quality checklist
- Webhooks and status messages: do you get real-time notifications about document status (delivered, rejected, in progress), or do you have to poll?
- Sandbox: is there a test environment that mimics the real network without test messages reaching production?
- Validation: does the API validate documents before sending, and do you get useful error messages? See also E-invoice formats and Peppol document types and standards.
- Peppol ID registration via API: can you register and manage your end users' Peppol IDs programmatically?
- Multi-tenant: can you manage multiple end customers separately under one technical connection, each with its own Peppol ID?
Testing before go-live
A working API connection does not yet mean the whole process works. Test end-to-end in the sandbox with a few regular trading partners before you put a customer live. Cover sending and receiving, the processing of status messages and the handling of rejected documents.
Then roll out in phases. Start with one customer or one document flow, for example outgoing invoices only, and scale up once that runs stably. This keeps errors limited to a small group and lets you learn from real use before your full customer base moves over.
What this means for integrators
Translate the architecture choice and the API checklist into concrete action points.
Checklist for integrators
- Decide which architecture pattern fits your scale: a single integration, or multiple customers and tenants
- Ask every candidate API provider about sandbox availability, error handling and multi-tenant support
- Plan a test phase with real trading partners before go-live
- Define how Peppol ID registration is automated in your onboarding process
What this means for software vendors
For software vendors, the choice is also a product decision. Building your own connector gives you maximum control, but you also take on the ongoing maintenance. Integrating with the API of a Peppol Service Provider keeps the user experience inside your own product and outsources the network connection. A white-label solution from a Peppol Service Provider brings e-invoicing into your product fastest, with less influence over functionality and roadmap. Consider the role e-invoicing plays in your proposition: is it a core feature that sets you apart, or a basic service that simply has to work?
Closing
A solid Peppol integration starts with a deliberate architecture choice and a critical look at the API you build on. Whichever pattern you choose, the questions in the checklist determine how scalable and maintainable your solution will be. For more on invoice formats and document types, see E-invoice formats and Peppol document types and standards. Want to compare Peppol Service Providers that offer an API? Visit the comparison tool on peppol.nu.
