Where a Peppol invoice stops, stop by stop, and who can restart it — 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 the one to open when something has gone wrong and you do not yet know what. It takes the four things you can actually observe — the invoice is not in the Waiting Queue, it is stuck there, it left and never reached History, or it is in History and the partner says otherwise — and for each names the stop, the cause and the person who can move it. About nine minutes.

Step 1 — Nothing appeared in the Waiting Queue: check the four gates

After this step you will know why an invoice never entered the pipeline at all. Four things decide it, and none of them is on the invoice screen. First, the company’s Peppol Status must be enabled — not the customer’s, the company’s. Second, the document must be a sales type, or a self-billed purchase type, and must not be marked to skip e-invoicing; a skipped document is skipped on the Peppol side too. Third, your tenant must hold the e-invoice trigger subscription that the Peppol secondary rides on — if you submit to MyInvois, you do. Fourth, and rare, a company can carry a list of processors to include or exclude at finalise, set by BigLedger; one company in the estate has one. The first is by far the commonest, and the Organisation applet is where to look.

Reference: My Peppol Admin Applet — Lifecycle and effects

Step 2 — It is in the Waiting Queue and never leaves: read that as a scheduling fact

After this step you will stop trying to fix a stuck queue from inside the applet. A row that sits in the Waiting Queue for days has not failed anything; nothing has looked at it. Either your tenant has no clock for the sweep that builds Peppol documents — true of most tenants — or it has one that fires once a day and takes twenty rows, and yours was not among them. Neither is visible on any screen, and neither is something you can change. Pressing Process runs one such batch of twenty in database order. The person who can change it is your BigLedger contact, and the request is specific: schedule the waiting-queue-to-document sweep, or shorten its schedule and raise its cap to match the volume you finalise.

Reference: My Peppol Admin Applet — Troubleshooting

Step 3 — It left the Waiting Queue and is not in History: follow it to the error

After this step you will find the reason in under a minute. Open Internal Submission, then To Peppol AP, and find the document. If its Validation Error says a sender or receiver identifier is missing, a default flag is not set on your company’s identifiers or the customer’s; set it, and know that this document will not be rebuilt — the fix is for the next one, and this one reaches the partner only through the after-LHDN row, a re-issue, or a support request. If the Validation Error is a list of rule messages, the field it names is wrong on the master record, with the same consequence. If it says valid, move to the Queue: a row there with a send result failed, and Submit resends it once. If the document is under To Peppol AP with no identifiers and no text, it is a document type Peppol cannot carry.

Reference: My Peppol Admin Applet — Troubleshooting

Step 4 — It is in History and the partner says nothing arrived: hand them the receipt

After this step you will know what is yours to answer and what is theirs. A History row is the receiving access point’s signed receipt, with the date and the document number on it. From that point the document is on their side of the network, between their access point and their accounting system, and the person to ask is their provider. Give them the number and the date. Two things can still be yours. If the partner says they received it twice, both of your Peppol switches are on and each sent its own copy; choose one. And if the invoice was accepted on transport but rejected on business rules — a missing order reference is the classic — the fix is on your document, not on the network.

Reference: My Peppol Admin Applet — Troubleshooting

Step 5 — Know what is logged where you cannot see it, and who can

After this step you will know when to escalate and what to ask for. When a run of the sweep itself fails — a document it could not build, a database it could not reach — the failure is written to a table of job errors that no screen in BigLedger reads. Across the estate that table held about a thousand failed sweep runs, on the same handful of tenants that run the sweep at all. Nothing on the Waiting Queue changes when this happens; the rows simply stay. So when a queue that used to drain stops draining, the question for support is not “is my document valid” but “read the job-error table for the Peppol sweep on my tenant and tell me what the last run said”. That sentence gets an answer in one exchange; “Peppol is not working” gets three.

Reference: How Work Actually Runs — When it goes wrong

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.

Back to the series · Play this as a presentation