Reading To Peppol AP, Queue and History — what each Peppol screen is evidence of — transcript

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 an invoice that left the Waiting Queue and now has to say, to a customer or to a manager, whether it arrived. In about ten minutes you will be able to read the three screens under Internal Submission as evidence rather than as labels, and you will know the one status that promises more than it delivers.

Step 1 — Read a To Peppol AP row as “a document was built”

After this step you will know what the first screen after the Waiting Queue proves. Internal Submission, then To Peppol AP, lists one row per Peppol document built from your invoices. On the row you can read the sender identifier that was found for your company and the receiver identifier found for the customer — both looked up by the default flag on each side at the moment of building. The row exists whether or not those lookups succeeded, whether or not the document is valid, and whether or not anything was sent. So a row here is exactly one fact: the sweep reached your invoice. Everything after that is in the Validation Error column, which is where you read next.

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

Step 2 — Read the three kinds of Validation Error

After this step you will be able to tell a configuration mistake from a rule breach at a glance. The Validation Error on a To Peppol AP row says one of three things. The bracketed phrase saying the document is valid means it passed and went on. Missing Peppol Sender or Receiver ID means one of the two default flags was not set — on your company’s list of identifiers or on the customer’s — and this is by far the commonest stop: of all the Peppol documents ever built across BigLedger’s customers, nearly all stopped here. Anything else is a list of messages from the Malaysian Peppol profile’s own rules, naming the field the document broke them on. Read the message; it is the closest thing to a reason you will get anywhere in this pipeline.

Reference: My Peppol Admin Applet — Troubleshooting

Step 3 — Treat SUBMITTED as handed over, not delivered

After this step you will not tell a customer their invoice was delivered because a screen said SUBMITTED. When a document passes validation, the sweep creates a row in the sending queue and, at that same moment, stamps SUBMITTED on the To Peppol AP row. The send has not happened yet. It happens a second later, and it can fail — a network fault, a receiving access point that rejects the message. None of that changes the SUBMITTED you are looking at. So SUBMITTED means “handed to the sender”. To find out what the sender did with it, move to the next two screens, in this order: Queue, then History.

Reference: My Peppol Admin Applet — Lifecycle and effects

Step 4 — Read the Queue: blank means in flight, a status means it failed

After this step you will know what to do with a row in the sending queue. A row appears here when the document is handed to the sender, with no status at all while the transmission is in progress — which is usually seconds. If the send fails, the row stays and its status becomes the sender’s verdict: a transport error, an error message from the receiving access point, or one of a few rarer results. Nothing retries a failed row on its own. You resend one row at a time with Submit, or remove it with Delete. A transport error is worth one resend; an error from the receiving access point usually means the identifier or the document type is wrong for that partner, and resending the same thing gets the same answer.

Reference: My Peppol Admin Applet — Lifecycle and effects

Step 5 — Read History as the partner’s access point signing for it

After this step you will know the strongest proof of arrival you can offer. When the receiving access point returns a signed receipt, the queue row is removed and a row appears under History with the status success. That receipt is the only “it arrived” BigLedger can show, and it is precise about who signed: the partner’s access point, not the partner’s accounts department. What happens between their access point and their accounting system is their provider’s business. When a partner says nothing arrived and you have a History row, give them the document number and the date on that row and let them take it to their provider. When we counted, the whole estate held a few dozen History rows in total; a single successful one on your tenant is a real milestone.

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

Step 6 — Know there is no way back from a failed row, and what the builder filled in for you

After this step you will fix master data before the first document rather than after. A To Peppol AP row that failed on a missing identifier cannot be rebuilt from any screen: its Waiting Queue row is already gone, and the buttons that would re-drive it are switched off in the applet. The backend has an endpoint for exactly that; nothing calls it. So correcting the default flag fixes the next document, not this one — what still reaches the partner is the second row the notification flag writes after LHDN accepts, a credit note and a fresh invoice, or a support request. Two more things happen quietly at build time: a company or customer with no tax number is written into the document with a placeholder tax number, and an invoice with no reference gets an order reference of N A. Both pass here and both are what a receiving system’s business rules reject.

Reference: My Peppol Admin Applet — Troubleshooting

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.

Next: Where a Peppol invoice stops, stop by stop, and who can restart it · Back to the series · Play this as a presentation