PEPPOL e-invoicing hotel procurement is no longer a regional curiosity. The network crossed 2.54 million registered participants across 111 countries in February 2026, up from roughly 1.4 million the prior March, with Belgium alone now representing more than half of all registered organisations (Poppel Peppol Statistics). For hospitality finance teams that have spent a decade plumbing EDI feeds and PDF inboxes into their accounts payable stack, the rail underneath supplier invoicing is being repaved. The question for the next planning cycle is not whether to participate. It is how to build for a world where structured invoicing is the default.
In our view, the 2026 inflection point is best understood as a network-effect event rather than a compliance event. Mandates create the floor. Network density creates the ceiling. Belgium’s January 2026 mandate, which requires structured invoices over PEPPOL between VAT-registered businesses, has pulled a domestic e-invoicing footprint to nearly two million participants in a country of eleven million people (EY Belgium analysis). Once that critical mass exists in one corridor, the cost of receiving a structured invoice from a Belgian supplier falls toward zero, and the calculus for every counterpart in the corridor changes.
What PEPPOL e-invoicing hotel procurement actually requires
PEPPOL is a four-corner exchange model. Corner one is the sender, corner four is the receiver, and corners two and three are certified access points operated by service providers. The access points authenticate identities, validate document structure against published rules, and route the message across the network (OpenPEPPOL Interoperability Framework; E-Rechnung Bund explainer). The content layer is PEPPOL BIS Billing 3.0, an implementation of the European EN 16931 semantic standard, expressed in UBL 2.1 XML (PEPPOL BIS Billing 3.0 specification).
For an AP team in a hotel group, three properties of this architecture matter more than the technical details. First, the message is structured at source: line items, tax codes, totals, payment terms, and counterparty identifiers are all parsable fields rather than text on a rendered page. Second, identity is resolved through the PEPPOL directory, not through the bilateral exchange of account numbers and routing keys. Third, the rules are published and validated, so a supplier in Brussels and a supplier in Helsinki produce documents the receiving access point processes the same way.
Approach one: PEPPOL-native AP architecture
A PEPPOL-native approach treats BIS 3.0 / UBL as the canonical invoice format inside the AP system, not as a peripheral connector. The supplier master is keyed to PEPPOL participant IDs. The invoice intake queue is a single channel from the access point, with PDFs and email attachments handled as a managed exception path rather than the main road. The three-way match runs against parsed UBL fields, with no OCR fallback required for compliant suppliers.
This approach has a higher up-front design cost. It requires the AP system to model UBL semantics natively, the supplier master to carry PEPPOL identifiers alongside legacy IDs, and the operations team to retire the parallel invoice handling paths that have accumulated over the years. The payoff is that every additional PEPPOL-enabled supplier joins the rail without bespoke onboarding. As more EMEA jurisdictions move PEPPOL into statutory infrastructure, that pool grows faster than any individual procurement team’s onboarding capacity.
Approach two: legacy plus adapter
The alternative approach keeps EDI, cXML, or vendor-portal flows as the primary AP architecture and bolts a PEPPOL connector on the side. Major AP automation platforms and PEPPOL access points support this pattern, and it is the path of least short-term disruption. The connector translates inbound BIS 3.0 messages into whatever internal format the AP system already speaks, often via mapping layers that have been developed for cXML and EDIFACT for two decades (IBM EDI migration overview).
In our view, the legacy-plus-adapter approach is rational for groups whose supplier base is concentrated in non-PEPPOL geographies or whose AP system is unlikely to be replaced in the next three years. It is also genuinely faster to deploy. The risk is a different one: it preserves the structural complexity of multiple invoice formats inside the AP system, and it does not benefit from network density. Each additional supplier still requires onboarding work, because the architecture treats PEPPOL as one of many inputs rather than the spine.
Why the choice matters more in hospitality than in other verticals
Hospitality AP has a structural feature that amplifies the difference between these two approaches. A 40-property group routinely deals with thousands of low-value, high-frequency supplier relationships: produce vendors, linen services, beverage distributors, regional maintenance contractors. Many of these suppliers are small, regional, and not equipped to maintain a bespoke EDI integration. They are exactly the segment that benefits most from a public, low-friction rail.
When Belgium reached one million PEPPOL participants in 2025, the suppliers driving that growth were not enterprise vendors. They were small and medium businesses connecting through accounting-software access points (Comarch coverage of Belgian PEPPOL adoption). A hotel group whose AP architecture can ingest a structured invoice from a small supplier as easily as from a national distributor changes its onboarding economics. Our broader argument for treating the AP system as a strategic asset, rather than a tactical adjunct, runs through our analysis of why procurement automation reshapes hospitality cost structures differently than BPO.
Reading the regulatory map
The regulatory map across EMEA is uneven, and that unevenness shapes the architecture decision. Belgium’s January 2026 mandate uses PEPPOL as the default channel, with the three-month tolerance period ending March 31 (Fiskaly mandate brief). France’s September 2026 go-live for large and mid-sized businesses requires routing through certified Plateformes Agréées, which interoperate with PEPPOL but are not synonymous with it, and accepts UBL, CII, and the Factur-X hybrid format (OpenText Europe roadmap). Germany continues its phased XRechnung and ZUGFeRD rollout through 2027 and 2028 without naming PEPPOL specifically. Poland’s KSeF 2.0 operates a centralised national clearance model in FA(3) XML rather than the PEPPOL four-corner model (Fiskaly Europe 2026 roadmap).
The implication for a multi-country group is that PEPPOL alone does not cover the regulatory surface. A serious AP architecture has to handle PEPPOL as the default while accommodating national clearance models where they exist. This is where the structured-data backbone matters: a UBL-native AP system can map outward to Factur-X or to KSeF more easily than a PDF-centric system can move inward to either. The VAT-in-the-Digital-Age package, which we examined in our analysis of the ViDA cascade through hospitality AP systems, sits above this national patchwork and pushes the convergence further.
What to plan for in the next 18 months
We believe three planning items belong on every CFO and CPO agenda in EMEA hospitality this year. First, audit the AP system’s native ability to ingest, parse, and validate UBL 2.1 against BIS 3.0 rules, without OCR or human transcription. Second, map the supplier base by PEPPOL participation status and by jurisdiction, because the suppliers in mandate countries will move first whether the group is ready or not. Third, decide explicitly whether PEPPOL becomes the spine of the AP architecture or a connector on its edge, and resource the choice accordingly. The decision is reversible, but the cost of reversal scales with how deeply the legacy paths get embedded in the meantime. The deeper question of where invoice data should live, and how it relates to property-level systems, is one we work through in our piece on whether the PMS or P2P stack is the system of record.
PEPPOL crossing 2.5 million participants is not a destination. It is a signal that the structured-invoicing rail is now broad enough that designing AP architecture around it is the rational default, rather than the ambitious one. The groups that recognise this in 2026 will spend the rest of the decade compounding the benefit. The groups that treat it as a connector problem will spend the same period rebuilding the integration each time a new mandate ships.