The moment you finalise a Peppol invoice, and what the Waiting Queue is not telling you — transcript

Presentation 1 of 4 in Send an invoice over Peppol · about 9 minutes · for the whole-system operator — you run the books.

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This presentation is for whoever has just pressed Finalise on an invoice to a corporate customer who asked for Peppol delivery, and wants to know what happened in the seconds after. In about nine minutes you will know what was written, what the first screen is and is not showing you, and the one thing that screen will make you believe that is not true.

Step 1 — Know what Finalise starts on the Peppol side

After this step you will know that the Peppol row is written by the same machinery as everything else Finalise does. Pressing Finalise does not save the invoice; it starts a primary job that fans out to secondary jobs — the journal, the stock movement, the LHDN e-invoice — and one of those secondaries is the Peppol one. It is subscribed through the same trigger template as LHDN e-invoicing, so on any tenant that submits to MyInvois it is already listening. It asks three questions: is the document final, does this company have Peppol Status enabled, and is this a document type e-invoicing covers. Yes to all three, and a row is written to the Peppol Waiting Queue within seconds. Nothing about the buyer, the addresses or the participant identifiers is looked at.

Reference: My Peppol Admin Applet — The two routes into the Waiting Queue

Step 2 — Read the Waiting Queue for what it is

After this step you will stop reading the Waiting Queue as a list of documents that are ready. It is a list of every eligible document finalised at a Peppol-enabled company, unchecked. Open it after your test invoice and you will see the row, and you will see a Status column that is blank. It is blank on every row, always, because the screen reads a column this queue does not have; nothing is wrong with your document. For the same reason no row can be ticked. So GadgetSphere Distribution’s invoice to a corporate client sits there looking exactly like an invoice to a customer with no participant identifier at all. The screen cannot tell them apart, because nothing has looked yet.

Screen: the Waiting Queue listing with the Doc No., Company, Entity Name and Amount columns filled and the Status column empty

Reference: My Peppol Admin Applet — Screens and menus

Step 3 — Expect a second row if the notification flag is on

After this step you will understand why one invoice can appear twice. Peppol Status writes a row at the moment of finalise. The separate peppol checkbox in Notification Config writes another row later, after LHDN has accepted the e-invoice. They are not two stages of one journey. Each row is built into its own Peppol document, both documents are produced from the same invoice, and nothing removes the second. So with both switches on, your partner receives the same invoice twice — once now and once after validation. When we measured, tens of thousands of documents across BigLedger’s customers were sitting in waiting queues with two rows each. Which moment BigLedger recommends is an open question; until it is answered, choose one and leave the other off.

Reference: My Peppol Admin Applet — The two routes into the Waiting Queue

Step 4 — Know which documents were let in that cannot travel

After this step you will not wait for a debit note to arrive. The gate at finalise admits every sales document type e-invoicing knows about, and a self-billed purchase document too. But only four Peppol shapes exist: an invoice, a credit note, and the self-billed versions of each. A sales debit note, a sales refund note, or a self-billed purchase credit or refund note passes the gate, lands in the Waiting Queue, and is not held there for you to fix. It is picked up later, built into an empty document, and lost from the pipeline without a message. If a partner needs one of those, send it the way you always did and say so in the covering note.

Reference: My Peppol Admin Applet — The journey after the Waiting Queue, stop by stop

Step 5 — Understand why vanishing is not delivery

After this step you will know where to look when the row disappears. The job that moves documents out of the Waiting Queue deletes the row the instant it creates the Peppol document — before it checks for a sender identifier, before it checks for a receiver, before it validates a single field. So your invoice leaving the Waiting Queue proves only that a document was built from it. Whether that document has anyone to go to is decided one line later, and recorded on a different screen. When a row you were watching is gone, do not conclude it was sent. Open Internal Submission, then To Peppol AP, and read what it says there. The next presentation is about how often that move happens at all.

Reference: My Peppol Admin Applet — The journey after the Waiting Queue, stop by stop

Check yourself

Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.

1. Your invoice is in the Waiting Queue with a blank Status. What does that tell you? It failed a check and is waiting for you
Nothing — the column reads a field the queue does not have, so it is blank on every row
It has been sent and is waiting for the partner's receipt

2. Peppol Status and the peppol notification checkbox are both on. What does the partner get? One invoice, after LHDN accepts it
One invoice, at finalise, with the LHDN reference added later
The same invoice twice — each switch writes its own row and each row is built and sent on its own

3. A sales debit note to a Peppol customer appears in the Waiting Queue. What happens to it? It is held until the customer record is complete
It is built into an empty document and lost, because no Peppol shape exists for it
It is delivered as an invoice

4. The row you were watching has disappeared from the Waiting Queue. What has been established? The partner's access point has received it
It passed validation
Only that a Peppol document was built — the row is deleted before any check, so read To Peppol AP

Answer key

Nothing — the column reads a field the queue does not have, so it is blank on every row — My Peppol Admin Applet — Screens and menus
The same invoice twice — each switch writes its own row and each row is built and sent on its own — My Peppol Admin Applet — The two routes into the Waiting Queue
It is built into an empty document and lost, because no Peppol shape exists for it — My Peppol Admin Applet — The journey after the Waiting Queue, stop by stop
Only that a Peppol document was built — the row is deleted before any check, so read To Peppol AP — My Peppol Admin Applet — The journey after the Waiting Queue, stop by stop

This is a self-check. Your answers are marked in your browser and stay there — nothing is sent anywhere, nothing is recorded, and the marking is readable in the page source, so it is not a credential. Open the answer key at any time.

Next: Who moves your invoice out of the Peppol Waiting Queue, and how often that actually happens · Back to the series · Play this as a presentation

Last updated on September 19, 2026

The moment you finalise a Peppol invoice, and what the Waiting Queue is not telling you Who moves your invoice out of the Peppol Waiting Queue, and how often that actually happens