Peppol Access Point: A Technical Reference for ERP Integration Teams

"Peppol Access Point" is one of those terms that sounds like a piece of hardware and turns out to be a software role with a certification, a certificate chain, a routing protocol, and an opinionated set of message-level requirements behind it. ERP and B2B SaaS teams hit the term the moment their first mandate (Belgium, Poland, France, Germany, Italy) lands on the roadmap, and the literature splits immediately into two camps — vendor brochures that paper over the architecture, and OpenPeppol specifications that assume you already know it.

This is the technical reference we wanted when we first integrated against the network. It covers what an Access Point is in the four-corner model, what it does on the AS4 layer, how SMP/SML discovery actually resolves, the BIS-versus-PINT format dependency that determines what payloads it can carry, and the G3 PKI migration that completed on April 1, 2026 and quietly changed the operating picture. No vendor framing. The goal is that you can read this and decide, on technical grounds, whether to operate your own AP, certify against one, or sit upstream of one.

Invoice Navigator is not an Access Point. We are the validation and compliance safety layer that sits before the AP — catching format, schematron, and business-rule errors locally so they never become a network-level rejection downstream. This piece is reference content; the positioning is incidental.

The Four-Corner Model in One Paragraph

Peppol routes documents through four corners. Corner 1 is the sender's back-office system (the ERP, accounting platform, or invoicing UI). Corner 2 is the sending Access Point — the certified service provider that takes the document from C1 and pushes it onto the network. Corner 3 is the receiving Access Point — the certified provider that the recipient has registered with. Corner 4 is the recipient's back-office system. The two endpoints (C1 and C4) never speak directly. All transport, signing, encryption, addressing, and acknowledgement happens between C2 and C3 over a protocol called AS4. The four-corner model is the entire reason Peppol can scale interoperability without bilateral connections: every sender talks to one AP, every receiver registers one AP, and the APs handle the mesh.

A practical consequence: when an ERP team says "we are Peppol-enabled," that almost always means "we have a contract with a C2 provider" — not "we built an AP." The two are very different commitments.

What an Access Point Actually Does

An Access Point performs four jobs. They look simple as bullet points and turn into several thousand lines of production code in practice.

On the sending side (C2):

Lookup. Take a recipient Peppol participant identifier (e.g. 0208:0700000001 for a Belgian KBO number), query the SML to find the responsible SMP, query the SMP to find the recipient's AS4 endpoint URL, AP certificate, and the list of document types and processes the recipient supports.
Validate. Confirm the outgoing document conforms to the declared profile (typically Peppol BIS Billing 3.0, increasingly Peppol PINT) and that the recipient supports it.
Wrap. Wrap the document inside a Standard Business Document (SBD) envelope, sign it with the AP's Peppol PKI certificate, encrypt the payload, and assemble an AS4 message.
Transmit. POST the AS4 message to the recipient AP's endpoint over TLS 1.2 or higher on port 443, handle the synchronous AS4 receipt, and persist enough state to issue a Message Level Status (MLS) downstream.

On the receiving side (C3):

Authenticate. Verify the inbound AS4 message signature against the sending AP's Peppol PKI certificate, validate the certificate chain back to the active Peppol root (G3 since April 1, 2026), and confirm the certificate has not been revoked.
Decrypt and unwrap. Strip the AS4 and SBD envelopes, surface the payload to the recipient's processing layer.
Acknowledge. Return an AS4 receipt to C2 synchronously. Issue an MLS (or, on older deployments, the legacy MLR) document asynchronously to confirm or reject at the business layer.
Route to C4. Deliver the document to the recipient's back-office system over whatever local protocol the recipient and AP have agreed (API push, file drop, message queue, etc.).

Nothing in those eight responsibilities is unusual on its own. The combination — certified PKI, dynamic discovery, mandatory encryption, mandatory acknowledgement, document-profile gating — is what makes building an AP a non-trivial project rather than an afternoon.

SMP/SML Discovery: How Routing Actually Resolves

The discovery layer is the part of Peppol that is most often misunderstood. There are two pieces:

The Service Metadata Locator (SML) is a single, centralised, OpenPeppol-operated service. Its only job is to map a Peppol participant identifier to the URL of the SMP that holds that participant's capability record. Resolution is DNS-based: the participant identifier is hashed, expressed as a DNS subdomain under edelivery.tech.ec.europa.eu, and a NAPTR record returns the SMP URL. There is exactly one SML in production. Sending APs cache the response.

The Service Metadata Publisher (SMP) is operated by each AP for the participants registered with it. When an ERP-side team registers a Belgian client's KBO number as "deliver Peppol invoices here," what actually happens is the receiving AP adds an SMP entry for that participant: the AP's AS4 endpoint URL, its Peppol certificate, the document types the participant accepts (e.g. urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0), and the supported transport profile (peppol-transport-as4-v2_0). When a sender wants to address that participant, the sending AP does the SML lookup, then queries the SMP, then sends the message to the endpoint and the certificate it was given.

A participant can only be registered with one SMP at a time. Moving from AP A to AP B means AP A removes the SMP record, AP B adds its own, and the SML eventually reflects the change. There is a propagation window — typically minutes, occasionally hours — during which inbound messages can be misrouted. Production-grade APs handle this with retries and bounce notifications; brochure-grade ones drop the message.

For ERP teams, the operational implication is that the participant identifier you assign to a customer becomes the addressable entity. Identifier choice matters: the German Leitweg-ID, the Belgian KBO/0208, the French SIRET/0009, the Italian IPA code — these are all valid identifier schemes but they are not interchangeable. Picking the wrong scheme is the most common reason a "Peppol-enabled" customer is not actually reachable.

AS4: The Transport Layer

AS4 is the transport protocol Peppol uses between C2 and C3. It is profiled from ebMS3, with strict additional constraints documented in the Peppol AS4 Profile. The constraints worth knowing:

One-Way/Push only. Pull and synchronous request/response are explicitly prohibited. The receiving AP cannot ask the sending AP for a message — only accept what is pushed.
Mandatory signing and encryption. Every AS4 message must be signed with the sender's Peppol PKI certificate and must have exactly one encrypted payload (the Standard Business Document containing the actual invoice or order).
Mandatory TLS 1.2+. Transport security is non-negotiable. Plaintext HTTP is not a fallback. AS4 endpoints listen on port 443.
Message size limits. Up to 100 MB for post-award traffic (invoices, credit notes, etc.). Up to 2 GB for pre-award procurement traffic. APs that do not meet the larger limit cannot be used for tender or contract documents.
Synchronous receipts. When C3 acknowledges receipt of an AS4 message, C2 gets that receipt synchronously on the same TCP connection. Business-level acceptance or rejection is a separate, asynchronous message (the MLS).

The current AS4 profile is version 2.0.3, published in early 2026. Implementations that pinned against earlier versions (2.0.1 and 2.0.2 are the most common older ones in the wild) still interoperate, but new APs certifying against the network must implement 2.0.3.

In practice, almost every production AP outside the largest enterprise vendors is built on one of three open-source AS4 stacks: phase4 (the Helger Java implementation, by far the most widely deployed), Holodeck B2B, and the CEF-derived DOMIBUS. Picking up phase4 and standing up a development AP is a one-week project; getting it through Peppol certification and into production is a six-month one.

BIS, PINT, and the BIS 4.0 Convergence

What an AP can actually transmit depends on what document profiles it supports. The two relevant families today are:

Peppol BIS Billing 3.0 is the European specification, fully aligned with EN 16931, the EU's semantic standard for e-invoicing. It is the workhorse format for every EU mandate currently in production (Belgium, Poland KSeF Phase 2, France's incoming September 2026 mandate, Germany's XRechnung downstream, Italy's outbound cross-border traffic). If your customer base is EU-only, BIS 3.0 covers everything.

Peppol PINT is the international invoice model, launched in July 2023 to extend Peppol outside the EU's EN 16931 regime — Australia, New Zealand, Singapore, Japan, Malaysia each have their own PINT-billing specification. PINT shares Peppol's network and AS4 transport but has its own semantic profile per jurisdiction.

OpenPeppol has been telegraphing convergence — eventually a unified Peppol BIS 4.0 that subsumes both — and the EU PINT Billing v1.0.0 specification published October 2025 is the first concrete artefact of that path. As of May 2025, mandatory PINT wildcard support is required of all certified service providers, meaning receiving APs must declare PINT capability in their SMP entry even if no inbound PINT traffic is expected. The full BIS 3.0 → BIS 4.0 migration is the 2026–2027 story; no jurisdiction has flipped yet.

The ERP-side consequence is that document generation code written against EN 16931 today is forward-compatible with BIS 4.0 in semantics but will need additive changes (new business terms, modified UBL/CII syntax bindings) for the syntax. Validators built around EN 16931-1:2026 and Schematron v1.3.16 are the conservative baseline.

The G3 PKI Cutover: What Changed on April 1, 2026

Until last month, Peppol APs ran on the G2 PKI trust chain. As of April 1, 2026, G2 certificates have been revoked. Every certified AP and SMP now runs on G3. The migration timeline ran:

August 11, 2025 — T0. OpenPeppol published the new G3 root and intermediate CA chains.
February 11, 2026 — T1. Service providers were required to be dual-capable — trusting both G2 and G3 — and to have either a test or production G3 certificate.
April 1, 2026 — T2. All G2 certificates (test and production) were revoked. From this date forward, any AP or SMP still presenting a G2 certificate is offline.

The migration was technically smooth at the network level; the rough edges have been at the integration layer. ERP teams that hard-coded the G2 root CA into local trust stores (instead of consuming the Peppol trust list dynamically) shipped to production deployments that were silently rejecting inbound MLS notifications from C3s starting April 1. The fix is straightforward — rotate the trust store to G3 — but the failure mode is invisible until a customer asks why their delivery receipts stopped arriving.

If you are evaluating an AP provider in mid-2026, the relevant due-diligence question is not "are you G3-capable" — every certified provider has to be — but "what is your certificate-rotation playbook for the next cycle." G3 is good for years; the lesson from the G2 cutover is that the next migration starts with eighteen months of notice and ends with a hard cutover that no individual provider can soften.

Build, Buy, or Wrap: The Decision

Three production paths for an ERP vendor that needs to be on the Peppol network:

Build your own Access Point. You operate C2 (and C3, if you receive). You hold the Peppol certificate, you run the SMP for your customers, you certify against OpenPeppol, you pay the annual membership and the certificate costs. Realistic only if you have engineering bandwidth to maintain the AS4 stack, monitor the G3 trust chain rotations, handle SMP propagation incidents, and you have enough invoice volume to justify the operating cost. The benefits are control and unit economics at scale (no per-message provider markup). The cost is roughly one dedicated engineer-year of effort up front and ongoing operational responsibility.

Buy a certified Access Point as a service. You integrate against a provider's REST or SFTP interface; they handle AS4, SMP, PKI, certification, and the trust-chain rotations. Pricing is either per-message (typical range €0.05–€0.25 per outbound, with inbound free or near-free at most providers) or per-customer (a fixed subscription per registered recipient, irrespective of volume). Provider examples in active EU traffic include EDICOM, Pagero, Basware, Storecove, Qvalia, Comarch, Billit, e-invoice.be, and Flowin. Selection criteria are coverage (do they have AS4 endpoints in all jurisdictions you ship to), latency, documentation quality, support SLAs, and pricing model fit.

Wrap an AP with a compliance layer. This is the architectural pattern we see most often at mid-sized ERP vendors: contract with a buy-side AP for transport, but place a validation and compliance layer (Schematron, EN 16931 business rules, country-specific CIUS rules, format coercion) in front of it. The wrap layer is where rejections get caught locally — before they become an AS4-level rejection or an MLS scarto. This is the pattern Invoice Navigator's validation API is built for; it is also the pattern that every well-engineered in-house Peppol integration converges on independently.

The cost difference between the three matters: a fully operated AP runs €30k–€100k+/year all-in (membership, certificates, engineering); buy-side AP costs scale with volume and start in the low thousands; the wrap-layer cost is the compliance layer alone, on top of whichever transport you choose. The volume break-even between "buy" and "build" is typically in the 100k+ outbound invoices per year range.

An ERP Integration Checklist

For a team about to sign with a buy-side AP, an eight-point pre-integration check:

Confirm participant-identifier coverage. Every jurisdiction you ship invoices into needs the relevant identifier scheme (KBO/0208 for Belgium, SIRET/0009 for France, NL KvK/0106 for the Netherlands, Leitweg-ID for Germany, IPA code for Italy, etc.). Ask the AP for the explicit list.
Confirm BIS 3.0 and PINT capability. PINT wildcard support is mandatory since May 2025; confirm anyway. If you have any non-EU traffic, confirm the specific PINT-billing variant is in scope.
Confirm AS4 profile version. 2.0.3 is the current target. Older versions still interoperate but are a sign of slow upgrade cadence.
Ask about the G3 rotation experience. A provider that struggled with the April 1, 2026 cutover is a provider that will struggle with the next one.
Inspect the API. Pay specific attention to: how errors surface (synchronous vs webhook), what the MLS lifecycle looks like, how attachments and structured data are mapped (most APs accept UBL XML directly; some accept JSON and serialise for you), how participant-registration is handled.
Test a real round-trip. Send a test invoice from your sandbox through the AP to a known test recipient (most APs operate a Peppol test endpoint at 0088:test). Time the cycle: AS4 receipt, MLS acceptance, downstream delivery confirmation.
Confirm the local validation story. Either the AP validates inbound documents against EN 16931 + BIS 3.0 Schematron before transmission, or it doesn't. If it doesn't, you need a pre-send validator on your side (or a wrap-layer compliance API). Find out before you ship.
Confirm SMP behaviour. Specifically: how the AP handles a participant moving to or from another AP (the SMP-propagation case), and what their bounce-handling policy is during the propagation window.

Where Validation Fits

The AP is a transport layer. It is not a compliance layer. A document that conforms to the AS4 envelope but violates EN 16931 Schematron rule BR-CO-15 will be accepted by C2, transmitted across the network, accepted by C3, delivered to C4, and rejected at the business layer with an MLS scarto hours later. The sender pays for the round-trip, the recipient triages a rejection notification, and the original ERP user has to re-issue the invoice — all because nothing in the AS4 pipeline catches semantic errors.

Pre-send validation is the layer that prevents this. Schematron rules, business-rule checks, country-specific CIUS validation, and format coercion (UBL ↔ CII, EN 16931 ↔ XRechnung 3.0 ↔ PINT) all belong upstream of the AP. The pattern Invoice Navigator implements is a validation API (/developers) that runs the full Schematron and BR rule set in single-digit milliseconds, returns structured error codes against an errors database, and lets the ERP retry locally before the AP ever sees the document. The same approach works whether the validation runs inline (block the send on failure) or out-of-band (warn but ship anyway).

The relationship to Peppol rejection mechanics in detail is in our existing Peppol MLR / MLS rejection guide — useful reading once you have the AP picture.

FAQ

What is a Peppol Access Point?

A Peppol Access Point (AP) is a certified service provider that connects an end-user's back-office system to the Peppol network. APs handle the AS4 transport, the PKI signing and encryption, the SMP/SML discovery, and the message-level acknowledgements that the Peppol four-corner model requires. There are two AP roles — sending (corner 2) and receiving (corner 3) — and most certified providers operate both. End users do not connect to the network directly; every sender contracts a sending AP and every receiver registers a receiving AP.

How much does a Peppol Access Point cost?

Pricing depends on whether you operate your own AP or buy one as a service. Buy-side APs typically charge either per-message (€0.05–€0.25 per outbound invoice, with inbound often free or near-free) or per-customer (a flat subscription per registered participant). Some providers — Flowin, for example — charge per connected enterprise rather than per volume. Operating your own AP runs roughly €30,000–€100,000 per year all-in, accounting for OpenPeppol membership (currently €1,500 per year for the smallest tier), Peppol G3 certificates (per AP and per SMP), engineering effort to maintain the AS4 stack, and on-call coverage for production incidents and certificate rotations. The build-versus-buy break-even sits at roughly 100,000+ outbound invoices per year.

Who are the main Peppol Access Point providers in 2026?

The market is fragmented. In the EU, the most active certified APs include EDICOM, Pagero, Basware, Storecove, Qvalia, Comarch, Billit, e-invoice.be, Flowin, and PeppolSoft. SAP, Oracle, and Microsoft Dynamics ship their own native Peppol connectors that contract with downstream APs. The Belgian, German, and French mandates have produced a local sub-market — Billit and e-invoice.be in Belgium, Comarch in Poland, several DATEV-adjacent providers in Germany. There is no single "best" choice; coverage of the jurisdictions you ship into and the quality of the integration API matter more than brand.

Does a Peppol Access Point have an API?

Yes — every buy-side AP exposes an integration interface. The shape varies: REST APIs that accept UBL XML or JSON are now standard at every provider; a minority still offer SFTP-based document drop for batch processing. The interfaces worth asking about specifically are: how outbound documents are submitted (sync vs async, XML vs JSON), how delivery status surfaces (webhook callbacks vs polling endpoints), how the MLS lifecycle is exposed, and how participant registration and SMP entries are managed (programmatic vs portal-only). For ERP integration, programmatic SMP management is the feature most often missing from cheaper providers and most often needed at scale.

What changed with Peppol G3 PKI on April 1, 2026?

The Peppol network completed its migration from the G2 PKI certificate authority to G3 on April 1, 2026. From that date, G2 certificates (test and production) are revoked and no longer trusted. Every certified AP and SMP now operates on G3. The migration ran across roughly eight months: new G3 chains published August 11, 2025; dual-capability mandatory by February 11, 2026; G2 hard cutover on April 1, 2026. ERP integrations that hard-coded the G2 root CA into local trust stores experienced silent MLS delivery failures starting April 1; the fix is to rotate the trust store to G3 or, preferably, consume the Peppol trust list dynamically. AP customers were not directly affected at the wire level — the certificate is the AP's responsibility — but downstream signature verification on inbound notifications can still misfire if local trust stores are stale.

What is the difference between Peppol BIS 3 and Peppol PINT?

Peppol BIS Billing 3.0 is the European document specification, fully aligned with EN 16931, the EU's semantic standard for e-invoicing. It is the format used by every EU mandate currently in production. Peppol PINT (Peppol International Invoice Model) is a newer specification launched in July 2023 to support countries outside the EN 16931 regime (Australia, New Zealand, Singapore, Japan, Malaysia each have their own PINT-billing variants). Since May 2025, all certified APs must support PINT as a wildcard capability even if they handle no PINT traffic. OpenPeppol has telegraphed a future BIS 4.0 that converges the two specifications; the EU PINT Billing v1.0.0 spec published October 2025 is the first artefact of that convergence path.

Should an ERP vendor operate its own Peppol Access Point?

Usually no. Operating your own AP is a year-one engineering commitment (an AS4 stack like phase4 or DOMIBUS, plus SMP, PKI handling, certification testing, OpenPeppol membership) and an ongoing operational responsibility (certificate rotations, trust list updates, on-call for network incidents). The economic break-even versus a buy-side AP sits at roughly 100,000+ outbound invoices per year. Below that volume, contracting with a certified AP and placing a validation/compliance wrap layer in front of it produces the same outcome at a fraction of the operating cost — and lets the engineering team focus on the ERP product instead of network infrastructure. The pattern most mid-sized ERP vendors converge on is: certified AP for transport, validation layer (such as Invoice Navigator) for compliance, native code only for the ERP-specific document mapping.

Sources: