API

Peppol API integration: how to embed e-invoicing into your SaaS platform

Contenuti

No headings found on page

If your SaaS platform handles invoicing, billing, or any kind of financial workflow for Belgian businesses, chances are your clients are already asking about Peppol (or will be soon).

Since January 1, 2026, B2B invoicing in Belgium must transit through the Peppol network in Peppol BIS 3.0 format. Every Belgian business in your client base needs a solution. Some are asking explicitly, most are signalling it through support tickets, workarounds, and the growing friction of managing e-invoicing outside your platform.

The question for your engineering team is not whether to build Peppol API integration into your product. It's how to do it without turning a compliance feature into a multi-quarter project.

Why SaaS platforms are adding Peppol as a native feature 

There are two ways a SaaS platform can respond to a compliance mandate: let clients handle it themselves with a third-party tool, or absorb it into the product and make it invisible. The second option is the one that reduces churn, increases stickiness, and removes a reason for clients to look elsewhere.

Embedding Peppol API integration natively means your clients issue and receive compliant invoices without leaving your platform. No separate login, no format conversion on their end, no manual steps. The compliance layer runs underneath your product, and your clients see a seamless invoicing experience, not a regulatory checklist.

For SaaS platforms serving multiple Belgian clients, this also means a single integration that scales across your entire client base. You build it once, you maintain it in one place, and every new client you onboard inherits the same compliant infrastructure automatically.

 

What your platform needs to handle

A production-ready Peppol API integration for a SaaS platform covers four core functions:

Sending invoices

Outgoing invoices must be converted to Peppol BIS 3.0 format, validated, digitally signed, and transmitted to the recipient's Access Point. Your integration handles this programmatically; your clients just trigger the send from your UI.

Receiving invoices

Incoming invoices arrive from the network, are validated, and need to be delivered into your platform in a processable format. This includes error handling for malformed documents and retry logic for failed deliveries.

 

Status tracking and webhooks

Real-time invoice status (sent, delivered, rejected, pending) is what your clients will expect to see in your dashboard. A webhook-based architecture pushes status updates to your platform without continuous polling, keeping your infrastructure lean and your UI responsive.

 

Multi-tenant support

Each of your clients has their own Peppol identifier, their own invoice flows, and their own compliance obligations. Your integration needs to isolate these from day one: credentials, identifiers, and document history per tenant, not per platform.

 

The technical flow: from your platform to the Peppol network

A Peppol API integration with a SaaS platform typically follows three steps.

 

Step 1: Register clients on the Peppol network

Each client needs a Peppol identifier, which is their endpoint on the network. Your integration handles registration programmatically via API, so onboarding a new client doesn't require manual intervention on either side.

 

Step 2: Send and receive via REST API

Outgoing invoices are submitted to the Access Point via a REST endpoint. The Access Point validates the format, resolves the recipient's endpoint in the Peppol directory, and delivers the document. Incoming invoices are pushed to your platform via webhook as soon as they arrive.

 

Step 3: Process responses programmatically

Every transmission returns a response: delivery confirmation, validation error, or rejection notice. Your integration processes these automatically and surfaces the relevant status to your end users through your existing UI.

For implementation details and code examples, refer to the A-Cube Peppol BE documentation.

 

What to look for in a Peppol API built for SaaS

Not every Peppol Access Point is built with SaaS integration in mind. When evaluating providers, filter the criteria through what your engineering team actually needs:

  • REST API with complete documentation: authentication flows, endpoint references, error codes, and real-world examples in the languages your team uses

  • Webhook support: status updates pushed to your platform, not polled

  • Multi-tenant architecture support: client isolation at the API level, not bolted on afterward

  • A sandbox that mirrors production: not just a format validator, but a full end-to-end test environment where you can replicate real invoice flows before shipping

  • OpenPeppol accreditation: non-negotiable; only accredited providers can transmit on the live network

  • Technical support that speaks developer: documentation gaps and edge cases need fast answers, not ticket queues

 

Embed Peppol e-invoicing into your platform with A-Cube

A-Cube is an accredited Peppol Access Point provider built for SaaS integration. The Peppol API is REST-based, fully documented, webhook-enabled, and multi-tenant ready, fully designed to fit into your existing architecture without requiring a dedicated compliance team to maintain it.

The sandbox is available from day one. Test client registration, outgoing and incoming invoice flows, webhook delivery, and error handling, all before your Peppol API integration goes anywhere near production.

Start with the sandbox and get your integration validated before go-live, with no commitment required.