Sending and receiving Peppol invoices: a step-by-step guide

To send or receive invoices over Peppol you need an account with an accredited access point, a participant identifier registered in that provider's SMP, and software that produces and reads Peppol BIS Billing 3.0 documents. Sending is: validate the invoice, look up the recipient, hand the document to your access point, and wait for the transport receipt and any business response. Receiving is the same in reverse, with the obligation to accept at least BIS Billing 3.0 invoices and credit notes. Prices are set by each provider, not by the network.

What you need before the first invoice

Three things, and none of them can be obtained from OpenPeppol directly: a service provider, an identifier and a compliant document.

An access point

A service provider accredited by a Peppol Authority. It signs the Service Provider Agreement, passes conformance testing and holds the PKI certificate the network requires. Most businesses do not contract one themselves; they use invoicing or accounting software that is connected to one. Belgium's FPS publishes a list of compliant software solutions.

A participant identifier

Your address on the network — in Belgium the enterprise number under scheme 0208, in Germany a Leitweg-ID for public bodies or the VAT number (9930) for businesses, in the Netherlands the KvK number (0106). The rules and a scheme table are on the Peppol identifiers page.

A compliant document

An invoice or credit note in Peppol BIS Billing 3.0 (UBL 2.1) that passes the EN 16931 and Peppol Schematron rules. Sending access points validate outgoing documents; a file that fails never enters the network.

Sending an invoice: step by step

The sequence below is what happens between your software and the recipient's, whichever provider sits in between.

1. Register with the access point. Create the legal entity (company name, address, country, identifiers) with the provider. Providers typically approve the entity before it may send, and register the identifiers you supply in their SMP — advertising them on the network so that others can address you.
2. Build the invoice. Produce a BIS Billing 3.0 UBL document with the customisation and profile identifiers of the specification, the seller's and buyer's EndpointID with schemeID, and every attachment embedded (base64) or linked inside the document. Attachments sent by a separate e-mail are not part of the invoice; in Belgium the FPS states they are legally part of the invoice and must travel with it.
3. Validate. Run the EN 16931 and Peppol Schematron rule sets. Fatal rules (for example a missing buyer endpoint or a VAT total that does not add up) block sending; warnings do not.
4. Look up the recipient. The access point resolves the buyer's identifier via the SML to the buyer's SMP and reads which document types it accepts. If the identifier is unknown, or the SMP does not list BIS Billing 3.0, the invoice cannot be sent over Peppol — agree another secure channel with the customer.
5. Transmit. The access point wraps the document in the Peppol envelope (SBDH), signs it and sends it over AS4 to the receiving access point. The receiving access point returns a signed AS4 receipt. That receipt is the proof that the receiving access point took the message — not that the customer has read it.
6. Record the outcome. Providers report the result asynchronously, usually by webhook, together with the evidence (the exact document sent and the receipt). Store the evidence with the invoice.
7. Wait for business responses. Optionally, the buyer's side sends a Message Level Response and, in the "Billing with Response" profile, an Invoice Response with the processing status (see below).

Re-sending is where most duplicate invoices come from. A transmission whose outcome is unknown — a timeout, a provider incident — may already have been delivered. The correct behaviour is to query the provider for the status using an idempotent reference, not to send again.

Receiving invoices

Receiving is what the Belgian mandate requires of every VAT-registered business, including those that only sell to consumers. The steps:

1. Register as a receiver with your access point and have your identifier published in its SMP with, at minimum, the BIS Billing 3.0 invoice and credit note document types. Belgian service providers must register the enterprise number; the FPS FAQ notes that publication on the network counts as agreement to receive structured invoices.
2. Decide how documents reach your software: a webhook from the provider, polling of the provider's API, or an integration your software vendor maintains.
3. Validate the incoming document against the same rule sets the sender used. A structurally invalid invoice may be rejected at message level.
4. Read the invoice into your purchase ledger: match the supplier by its identifier, check the totals, book it as a bill.
5. Respond where your process supports it — an Invoice Response with "rejected" is the Peppol way to refuse an invoice that was not meant for you, and the Belgian FPS points to exactly that mechanism.

Self-billing is a separate document type: the supplier, not the customer, must register to receive self-billing invoices and credit notes. Credit and debit notes that correct a structured invoice are sent in the same format and over the same channel as the original.

Receipts and responses: AS4 receipt, MLR and Invoice Response

Peppol distinguishes three levels of acknowledgement, and confusing them is the most common misunderstanding of "was my invoice delivered".

An AS4 receipt therefore proves transport, an MLR proves the file could be processed, and an Invoice Response reports what the buyer decided. Many receivers send none of the last two. Software should show each level for what it is and never turn a transport receipt into "paid" or "accepted".

Common errors and what they mean

What it costs

OpenPeppol does not charge end users; costs arise at the service provider. Models seen on the market include per-document fees, monthly subscriptions with included volume, and enterprise contracts on quotation; some accounting products include the connection in their subscription. Prices differ enough between providers and volumes that no figure here would be reliable — ask the provider or your software vendor. For Belgium, FPS Finance has pointed to tax measures for the transition (an increased investment allowance and, for 2024–2027, an increased deduction for subscription invoicing software); whether they apply to a given business requires professional confirmation.

How KRONENWERK sends and receives over Peppol

KRONENWERK generates a Peppol BIS Billing 3.0 UBL invoice for every invoice a Belgian company issues, validates it against the Peppol and EN 16931 Schematron rules before issuance and records the tax verdict and the VIES check of the buyer's VAT number with the invoice. That part is SUPPORTED.

Transport is SUPPORTED WITH LIMITATIONS. KRONENWERK is not a Peppol access point. It sends and receives over Peppol through an accredited access point provider (Storecove) once the company is connected in Settings → Delivery; production sending depends on that account and its configuration. What the connection does when it is in place:

• The company is registered as a legal entity with the provider and its identifier (scheme 0208 for a Belgian company) is published; a company without a connection gets a clear failure, never a send in its name.
• Each send is idempotent: the invoice's own reference becomes the provider's idempotency key, so a retry cannot create a second invoice. An outcome the provider has not reported is shown as unknown, not as failed.
• Delivery status is taken from the provider's webhook events and the transport evidence — the document as sent and the receiving access point's receipt. The invoice shows "transport accepted" or "delivered" only when the route reports it; a generated or validated file is never shown as sent.
• Received documents reported by the provider are fetched and read into bills, like uploaded XRechnung, ZUGFeRD or UBL files.

Until the connection is made, a Belgian invoice shows "structured invoice ready · Peppol connection required", and the e-mail panel states that an e-mail does not replace it. Product details are on e-invoicing in KRONENWERK; the Belgian legal frame on the Belgium hub; the network itself on what Peppol is. Developers who want the API side — drafts, webhooks such as invoice.issued — should read Peppol integration. A received file can be checked without an account with the e-invoice checker.