The document a supplier sends to say what has actually been shipped — against which order, in what quantities. Elsewhere in logistics it is called an advance shipping notice. On Peppol it travels as a UBL 2.1 DespatchAdvice, and it is the step most often missing when order-to-invoice automation breaks.
At a glance
IBT-016 · cac:DespatchDocumentReferenceurn:fdc:peppol.eu:poacc:trns:despatch_advice:3Peppol carries the whole post-award conversation, not only the invoice. Tax mandates normally reach the last two documents; the earlier ones are driven by what your trading partner requires.
Large buyers, retailers and public bodies — parties receiving goods at volume, who need to book a delivery before the invoice arrives.
Three-way matching needs order, receipt and invoice. Without a despatch advice the middle term is manual, and the invoice waits.
You can only receive one if the document type is published in your SMP entry. Senders will not route what you have not declared.
The mandatory core is small. Most of the operational value sits in the optional shipment detail, which is why implementations vary so much between buyers.
| Element | What it says |
|---|---|
| Identifier & issue date | Which despatch advice this is, and when it was raised |
| Order reference | The order being fulfilled — the link that makes matching possible |
| Despatch & delivery parties | Who shipped, and where it is going |
| Lines: item and quantity | What is actually in the consignment, which may differ from what was ordered |
| Shipment & packaging | Consignment detail, packages, and the actual delivery date |
These three are routinely confused. The distinction is simply who is speaking, and about what.
| Document | Sent by | Says | Invoice reference |
|---|---|---|---|
| Despatch advice | Supplier | “This is what I shipped” | IBT-016 |
| Receiving advice | Buyer | “This is what arrived” | IBT-015 |
| Invoice | Supplier | “This is what you owe” | — |
Both references are optional. Where a jurisdiction's rules mention them they constrain rather than require — Oman's PINT OM Schematron, for instance, asserts only that each may occur at most once.
Same transport as an invoice. What differs is the document type identifier, and the fact that the receiver must have declared the capability.
curl -X POST https://app.goroute.ai/peppol-api/documents \
-H "X-API-Key: $GOROUTE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"receiver_scheme": "0088",
"receiver_id": "7300010000001",
"document_type": "urn:oasis:names:specification:ubl:schema:xsd:DespatchAdvice-2::DespatchAdvice##urn:fdc:peppol.eu:poacc:trns:despatch_advice:3::2.1",
"process_id": "urn:fdc:peppol.eu:poacc:en16931:any",
"document": "<DespatchAdvice xmlns=...>…</DespatchAdvice>"
}'
Check the receiver first with the participant lookup — it returns the document types they have actually published. See Peppol API integration and developer resources.
We register the capability on your SMP entry and handle validation and AS4 transport as a certified Access Point — the same path your invoices already take.
Related: e-invoicing glossary · Peppol API integration · SMP-as-a-Service · Oman e-invoicing