The Peppol document flow

What actually happens to a Peppol invoice between the moment the seller hits "send" and the moment the buyer's ERP books it. Eight steps, two Access Points, one AS4 message, one acknowledgement and an optional business-level response. Below is an original SVG diagram, free to embed.

By Peppol Validator · Last updated 10 April 2026

The Peppol document flow in eight steps. The dashed return arrows are the Message Level Response (MLR) and the optional Application Response (Invoice Response).

The eight steps

1
Seller creates the invoice
The seller's ERP, accounting package or billing platform produces the invoice in whatever native format it uses internally. At this stage the document is just data inside the seller's own system: it has no signature, no Peppol envelope and no transport identity yet.
2
Sender Access Point packages it as UBL
The sender Access Point converts the seller's native invoice into the agreed Peppol format, which is Peppol BIS Billing 3.0 on top of UBL 2.1 with a CIUS over EN16931. This is where the document picks up its formal Peppol identity: customisation ID, profile ID, document type identifier and the structured XML expected by every other Access Point on the network.
3
Validate & sign
Before the document leaves the sender Access Point, it is validated against the EN16931 (CEN) schematron rules and the Peppol BIS Billing 3.0 schematron rules. If any fatal rule fails, the document is rejected back to the seller and never reaches the network. If validation passes, the Access Point signs the message with its X.509 certificate so the receiver can verify the origin.
4
SML / SMP lookup
To deliver the document the sender Access Point needs the recipient endpoint. It hashes the recipient's participant identifier and queries the Service Metadata Locator (SML), which returns the URL of the recipient's Service Metadata Publisher (SMP). The SMP returns the receiver Access Point's endpoint, the supported document types and the public certificate to use for AS4.
5
AS4 transmission
The sender Access Point transmits the document directly to the receiver endpoint over AS4 (the OASIS ebMS 3.0-based Peppol transport profile). The message is signed and encrypted, and follows reliable-messaging conventions so duplicate or missing transmissions can be detected and recovered.
6
Receiver-side validation
The receiver Access Point decrypts the AS4 message, verifies the certificate chain and runs the EN16931 and Peppol BIS schematron rules a second time. This is partly defensive (to confirm the document was not altered in transit) and partly to apply any local CIUS rules that the sender side may not enforce.
7
Deliver to the buyer's ERP
Once validation passes, the receiver Access Point forwards the document to the buyer's accounting system in the format the buyer expects. Because every field is structured, the buyer's ERP can book the invoice automatically and reconcile it against a purchase order without manual data entry.
8
Message Level Response and optional Invoice Response
The receiver Access Point sends a Message Level Response (MLR) back to the sender Access Point to acknowledge delivery and confirm the validation outcome. Optionally, the buyer's system sends an Application Response (also known as Invoice Response) back through both Access Points to communicate the business-level processing status: accepted, rejected, conditionally accepted, under query.

What happens when something fails

The flow has three different failure modes and they fail at different corners. Sender-side schematron failures are caught before transmission, in step 3. The seller's Access Point rejects the document back to the seller. Nothing reaches the network. This is the failure mode you want, because the cost of fixing the invoice is just an internal ticket.

AS4 transport failures happen between steps 5 and 6. The MLR is the mechanism to detect them: if the sender Access Point does not receive a positive MLR within the agreed window, it retries (AS4 supports reliable messaging). Modern Access Points handle this transparently.

Receiver-side schematron failures happen at step 6. The receiver Access Point sends back a negative MLR explaining which rules failed. The sender now has a problem: the document was already transmitted, so the seller has to re-issue or correct it. This is the most expensive failure mode, which is exactly why it pays to validate every outgoing invoice locally before it reaches the network.

Embed this diagram

Copy the snippet below into any HTML page, blog post or wiki. The image is served as an SVG so it scales to any size and stays sharp on retina screens. Please keep the attribution line below the image.

<a href="https://peppolvalidator.com/diagrams/document-flow">
  <img src="https://peppolvalidator.com/diagrams/document-flow/svg"
       alt="Peppol document flow diagram"
       width="800" height="720" />
</a>
<p><small>Diagram by <a href="https://peppolvalidator.com">Peppol Validator</a></small></p>

The SVG file also carries a Dublin Core copyright block (RDF metadata), so the attribution travels with the image when it is downloaded or screenshotted.

Related references

Peppol four-corner model diagram : the static architecture this document flows through.
Peppol validation pipeline diagram : what the "Validate" steps do under the hood.
Peppol validation errors reference : the schematron rules that decide whether step 3 or step 6 succeeds.
Peppol Access Points : what corners 2 and 3 actually do in practice.

Validate before you send

Run every outgoing invoice through the Peppol Validator to catch schematron failures locally, before they become receiver-side rejections. Free, instant, no signup.

Open Peppol Validator All diagrams

Frequently asked questions

What is the Peppol document flow?

The end-to-end lifecycle of a single Peppol invoice. The seller creates the document in their ERP, the sender Access Point packages it as UBL and validates it, the document is transmitted over AS4 to the receiver Access Point, which validates it again and forwards it to the buyer's accounting system. A Message Level Response (MLR) is sent back to acknowledge delivery, and the buyer optionally sends an Application Response (Invoice Response) to communicate the processing status.

What is a Message Level Response (MLR)?

A technical acknowledgement that the receiver Access Point sends back to the sender Access Point after receiving and validating an AS4 message. The MLR confirms that the document was received, that the AS4 envelope was well-formed, and whether the payload passed schematron validation. The sender knows from the MLR whether to consider the delivery complete.

What is an Application Response (Invoice Response)?

An optional business-level response from the buyer back to the seller that communicates how the invoice is being processed. Statuses include accepted, rejected, conditionally accepted, in process or under query. Not every Access Point or buyer system supports Invoice Response: in many countries it is opt-in. When supported, it travels back through both Access Points the same way the original invoice did.

Where does validation happen in this flow?

Validation happens at least twice. The sender Access Point validates the document against the EN16931 (CEN) and Peppol BIS Billing 3.0 schematron rules before transmission, to catch errors early. The receiver Access Point repeats the validation after decryption, both to confirm the document is well-formed and to satisfy local CIUS rules. A document that fails fatal rules is rejected and never reaches the buyer's ERP.

Can I embed this diagram in my own documentation?

Yes. The diagram is an original SVG, free to embed with an attribution link back to peppolvalidator.com. The embed snippet on this page gives you the exact HTML to paste. The SVG file also carries a Dublin Core copyright block so the attribution stays with the image when downloaded or screenshotted.