Peppol E-Invoicing Explained: Network, Access Points & B2B Invoices

Short answer: Peppol is a governed network for exchanging structured business documents. A Peppol e-invoice is machine-readable data—not a PDF emailed to accounts payable—and it travels between the sender and receiver through approved Access Points.

That simple definition hides three decisions a small business has to make: whether a customer or authority requires Peppol, whether the invoice data meets the applicable rules, and which Access Point will perform the authoritative validation and network delivery. Keeping those decisions separate prevents an attractive “Peppol-ready” label from being mistaken for proof that a particular invoice was accepted.

What is Peppol e-invoicing?

Peppol began in public procurement, but the network is also used for business-to-business electronic invoicing. OpenPeppol describes the interoperability framework that lets organizations exchange standardized documents through accredited service providers.

Peppol is not a file extension, a government tax portal or a promise that every country follows the same mandate. It combines Peppol standards, governance and a network of Access Points. The electronic document is commonly represented in Universal Business Language (UBL) XML under Peppol BIS Billing rules, while the legal obligation and rollout date come from the relevant national authority.

Peppol e-invoicing explained: electronic invoice vs PDF

A PDF is a visual invoice. A Peppol e-invoice is structured data that accounting or ERP software can process field by field. That difference makes electronic invoice exchange less dependent on retyping, optical character recognition or a custom integration between every pair of trading partners.

Structured electronic invoices still need human-readable context, but appearance is not the compliance test. The invoice data, participant identity, document profile and Access Point validation determine whether the electronic exchange works.

How does the Peppol network work? The 4-corner model

The usual Peppol model has four corners:

1. The sender. The supplier creates the electronic invoice.
2. The sender’s Access Point. The supplier’s service provider validates and carries the document.
3. The receiver’s Access Point. The buyer’s provider receives it through the network.
4. The receiver. The buyer’s accounting, procurement or ERP system consumes the structured invoice.

The model is useful because the supplier and buyer do not need to build a private integration with each other. They still need correct participant identifiers, compatible document types and providers that can serve the required country and transaction.

What are OpenPeppol, a Peppol Authority and an Access Point?

OpenPeppol maintains the international governance framework and Peppol Business Interoperability Specifications. A Peppol Authority governs local implementation in a defined jurisdiction and may add authority-specific requirements. A Peppol Access Point is the service provider that connects a sender or receiver to the network under the applicable agreements and accreditation rules.

This division matters. Invoicing software may prepare a business document or integrate with a service provider, but only a properly authorized provider supplies network access. A business that only sends or receives invoices normally uses a certified or accredited Access Point; it does not become one. OpenPeppol’s current Peppol Authority directory is the better source for jurisdiction contacts than an old blog table.

Which countries use Peppol in 2026, and is it mandatory?

Peppol adoption now spans Europe and parts of the Asia-Pacific region, with country profiles for markets including Australia, Belgium, Denmark, Finland, France, Germany, Ireland, Italy, Japan, Malaysia, the Netherlands, New Zealand, Norway, Poland, Singapore and Sweden. OpenPeppol maintains the current country profiles, while local authorities publish the actual e-invoicing requirements.

There is no single global answer to “Is Peppol mandatory?” Some rules apply to business-to-government (B2G) procurement, some to business-to-business (B2B) transactions, and some use a different reporting or exchange model. Scope can depend on VAT status, turnover, customer type, invoice date and transition period. In 2026, confirm the rule with the relevant authority for the seller, buyer and transaction instead of treating a country name as a compliance verdict.

Local branding can differ too. Singapore’s InvoiceNow network, for example, operates on the Peppol framework. Australia’s tax authority describes Peppol as an international eProcurement framework using approved Access Points. These examples show adoption; they do not make Invoice Crowd a certified service in either country.

What a Peppol ID does

A Peppol participant is addressed with an identifier scheme and an endpoint value. The identifier may be based on a business registration, VAT number or another national identifier, depending on the scheme. A business should obtain the receiver’s exact Endpoint ID and Electronic Address Scheme (EAS) from the customer, its Access Point or an authoritative directory workflow rather than guessing from a company name.

A syntactically tidy identifier can still be wrong for the intended recipient. Participant discovery and capability checks belong with the Access Point or another authoritative service; storing a value in invoicing software is not evidence that the endpoint exists or can receive the selected document.

The public Peppol Directory can help locate some registered participants, but directory visibility is not a substitute for provider discovery or customer confirmation. A Peppol ID may also be tied to the participant’s current service provider arrangements, so transfer and continuity questions should be answered by the relevant Access Point.

What are the benefits of B2B e-invoicing today?

The practical benefit is interoperable document exchange. A sender can use its software and Access Point while the buyer uses a different ERP and provider. Shared addressing, Peppol standards and structured fields reduce one-off integrations across the supply chain.

• Less rekeying. Structured data can move into the receiver’s workflow without copying totals from a PDF.
• Earlier validation. An Access Point can reject invalid identifiers, unsupported profiles or rule failures before a person discovers them later.
• Clearer routing. A Peppol ID and capability discovery help direct a business document to the intended participant.
• Interoperability. B2B and B2G document exchange is not locked to one buyer-supplier integration.
• Better evidence. Provider status can show whether an invoice was accepted for network processing, although it does not prove buyer approval or payment.

Those benefits depend on correct source data and compatible trading partners. Peppol does not correct a wrong VAT treatment, approve an invoice, initiate payment or guarantee that every cross-border mandate is satisfied.

What the invoice data must get right

A structured invoice must preserve meaning at line, tax, total and payment level. Common fields include supplier and customer identities, invoice number and date, currency, buyer reference, line descriptions and quantities, tax categories, allowances or charges, totals and payment information.

Failures often come from ambiguity rather than a missing logo or a spelling mistake:

• Missing or mixed tax treatment. Each line needs a tax meaning the receiver can interpret. Blank is not the same as zero-rated or exempt.
• A buyer reference in the wrong field. An internal note or invoice number should not silently stand in for the reference supplied by the buyer.
• Standalone charges without tax meaning. Shipping or another charge may need to be represented as a properly taxed line.
• Totals that cannot be reconstructed. Rounding, discounts and tax must reconcile from the structured components.
• An unsupported document type. A network may define credit notes and orders even when a particular software connection supports sales invoices only.

A safe e-invoicing workflow refuses an ambiguous document. It does not repair the meaning silently just to produce XML.

Do you need an Access Point provider?

To send a document across the Peppol network, a business needs an Access Point relationship—directly or through software that has one. The provider’s onboarding, identity checks, coverage, pricing and evidence model matter. A free sandbox is not proof that production delivery is free, and a software subscription does not automatically include Access Point charges.

Before choosing a service provider, ask:

• Which countries, participant schemes and document types are supported?
• What business verification is required for production?
• How are documents priced, and what happens when account balance is insufficient?
• How does the provider expose validation errors and delivery status?
• Can you export the UBL and evidence if you change providers?
• Who is responsible for inbound invoices, corrections and retention?

What does Peppol e-invoicing cost?

There is no universal Peppol invoice price. A provider may charge a subscription, onboarding fee, document fee, prepaid balance or a combination. Accounting software may include some connectivity or charge separately. Production identity verification, country coverage, inbound document handling, retention and support can also affect cost.

Ask for the full production price rather than relying on a free sandbox. Confirm whether sending and receiving are both included, what happens when credits run out, whether failed documents are charged, and how data and evidence can be exported if you move to another service provider.

Can Peppol integrate with an existing ERP or accounting system?

Yes, when the system can map its invoice data to the required Peppol BIS profile and connect through a suitable Access Point. The integration might be built into accounting software, supplied by a service provider, or implemented through an API. The difficult work is not merely producing XML: identifiers, tax semantics, purchase orders, references, status handling and error recovery must retain their meaning.

Before connecting an ERP, test both valid and rejected documents. Keep the internal invoice number linked to provider evidence, and do not mark an invoice delivered, approved or paid from an ambiguous callback. An electronic exchange should strengthen the audit trail, not replace one unclear status with another.

Peppol and e-invoicing terminology you will encounter

Peppol invoices are structured documents exchanged under the Peppol framework. The phrase Peppol service provider usually refers to a company operating network services such as an Access Point. You may also see “certified Peppol Access Point,” “certified access point” or “certified service” in provider directories; the relevant Peppol Authority decides which accreditation language and requirements apply.

Peppol BIS Billing 3.0 is the commonly used name for the billing specification that constrains invoice data on the network. Peppol providers may also support other procurement documents, but support for purchase orders or responses must be checked separately. One supported profile does not imply that every electronic document exchange is available.

A single Peppol connection can make a business interoperable with trading partners served by different providers. That is the value of Peppol business interoperability: the sender does not arrange a private connection with every receiver. It still does not mean all B2B transactions, all invoices for B2B customers or every cross-border rule use the same profile.

Headlines saying “e-invoicing is becoming mandatory,” “mandatory e-invoicing” or “mandatory B2B e-invoicing” need a jurisdiction, scope and effective date. E-invoicing mandates can be shaped by tax reporting, government procurement, local VAT rules and wider policies such as VAT in the Digital Age. Treat those phrases as a reason to open the current authority guidance—not as implementation instructions.

How Invoice Crowd handles Peppol-related work

The current Invoice Crowd Peppol workflow separates file creation from network delivery.

1. Provider-independent UBL file exchange

For a supported standard sales invoice, Invoice Crowd can build UBL 2.1 XML using the Peppol BIS Billing profile and run bounded local preflight checks. The business downloads the XML and uploads it to the Access Point portal or service it has chosen. This default path does not require an Invoice Crowd provider account, platform API key, legal-entity record or webhook worker.

The boundary is important: Invoice Crowd’s local check is not complete authoritative validation. The Access Point remains responsible for current rules, participant discovery, network acceptance and delivery evidence.

2. Optional customer-managed Peppol.sh delivery

The application also contains an optional connection for a customer-managed Peppol.sh Personal account. It is disabled by default. Where the platform and connection flags are deliberately enabled, the customer provides the API key for its own funded provider account and selects the exact company returned by that provider workspace. The key is stored encrypted and is not returned in full.

This path does not make Invoice Crowd an Access Point, remove provider verification, include provider credits or guarantee production acceptance. The customer and provider still own onboarding, funding, coverage and certification evidence. Connected sending fails closed when the invoice meaning cannot be preserved, and status refresh is manual rather than an inbound provider webhook.

3. Manual supplier UBL import

A supplier UBL file can be uploaded manually from Bills. A supported file with an exact receiver match is validated conservatively and becomes an unposted draft bill for review. The import never posts accounting, marks the bill paid, adjusts inventory or contacts a network provider. Unsupported or unsafe XML fails without creating a partial record.

Which documents are supported in Invoice Crowd?

Outbound UBL export is limited to standard sales invoices. Estimates, recurring templates, subscriptions, payment links, bills, purchase orders, vendor credits, credit notes and other unsupported types fail closed. That is a product boundary, not a statement about everything Peppol specifications may support.

Likewise, a manual supplier invoice import is not an automated Peppol inbox. Invoice Crowd currently has no inbound Peppol.sh receiver or webhook. The user obtains the UBL file and chooses to import it as a draft.

How to get started with Peppol e-invoicing: a readiness checklist

1. Confirm the obligation. Check the current authority guidance for the business, customer, transaction and effective date.
2. Confirm the recipient. Obtain the exact EAS and Endpoint ID from reliable evidence.
3. Clean the source invoice. Review tax categories, buyer reference, quantities, currency, charges, discounts and payment details.
4. Create and inspect the UBL. Treat local preflight as an early check, not a certificate.
5. Validate with the Access Point. Prove provider onboarding, recipient discovery, acceptance and the evidence returned.
6. Test failures. Use a rejected tax setup, an unknown recipient and insufficient provider balance so the team knows how each state appears.
7. Keep accounting review separate. Delivery does not equal approval, payment or posting.
8. Set a freshness date. Peppol BIS releases and national mandates change; recheck before relying on a scheduled article or rollout plan.

Frequently asked questions