Peppol Configuration Guide

Watch this as a presentation — 1 on this page, slides with narration.

Where a Peppol invoice stops, stop by stop, and who can restart it

10 slides · about 9 min · Send an invoice over Peppol, 4 of 4

Some of your corporate customers will ask you to stop e-mailing PDFs and start delivering invoices straight into their system. That is what Peppol is for. By the end of this guide one real sales invoice will have left your company, crossed the network and landed in a trading partner’s software — and you will know exactly where to look when the next one does not. Budget an afternoon for the setup, plus a wait of a few working days if your company is registered in Sabah or Sarawak.

Meet GadgetSphere

GadgetSphere Distribution Sdn Bhd (GSD) sells to corporate clients — the arm that invoices other businesses rather than shoppers. Two of its larger clients have asked for Peppol delivery, and a third has said it will in the new year. Nothing about GadgetSphere’s LHDN e-invoicing changes because of that; Peppol is an extra channel bolted alongside it, not a replacement.

What you need to know first

Peppol delivers; LHDN clears. MyInvois is a clearance channel — you send the tax authority a document and it comes back Valid. Peppol is a delivery network — your document travels from BigLedger’s access point to your partner’s access point, addressed by participant ID. They are two separate journeys for the same finalised document, and you need both.

Peppol runs beside the LHDN pipeline, not after it. The moment a document is finalised — before LHDN has been told anything — it lands in the Peppol waiting queue, on the strength of three things only: the document is FINAL, the company has Peppol enabled, and the document type is one Peppol can carry. Nothing at that point checks the buyer’s tax number, the addresses or the participant IDs. Three useful consequences:

A document in an e-invoice pool is in the Peppol waiting queue as well. The two are not connected: the pool row is waiting for the buyer’s details, the Peppol row is not waiting for anything. It will fail later, one stage on, when the Peppol document is built and the sender or receiver ID cannot be found.
A Peppol delivery can succeed while the LHDN submission is still Invalid, and vice versa. Neither tells you anything about the other.
There is a second, separate switch — the peppol checkbox in Notification Config — which adds a second waiting-queue row after LHDN accepts the e-invoice. Step 1 covers both, because turning on one and not the other is the commonest way a new company ends up half-configured.

Ignore the Posting Queue screen. Older material — including earlier versions of this guide — describes a Posting Queue → Waiting Queue journey. That route still exists in the code, but its gate reads a company field that no screen has written since June 2024, and the queue table behind it is empty on every BigLedger tenant. A document that never appears in the Posting Queue is not stuck; it was never going there. Watch the Waiting Queue.

Peppol is not “for cross-border only”. The traffic BigLedger reports to OpenPeppol every month is overwhelmingly the Malaysian domestic billing profile. A Malaysian supplier delivering to a Malaysian buyer over Peppol is the ordinary case, not the exotic one.

You do not join the network yourself. BigLedger operates an accredited Malaysian access point. Registering your participant with the Malaysian service metadata publisher, the certificates, the network-side migrations and the statistics BigLedger has to file as a service provider are all handled for you. There is nothing for you to install and no certificate for you to obtain.

There is no customer-facing Peppol test network in BigLedger. The testbed screens in the applet exist for BigLedger’s own accreditation work and their menu entries are switched off. Your test is the one in Step 7: send a real, small document to a real trading partner and watch it arrive.

Before you start

The company is already live on MyInvois — see MyInvois Setup. Peppol reuses that master data wholesale, so doing it second saves the work twice.
You have the company’s business registration number and a PDF that evidences the company’s identity, for the know-your-customer step.
Your trading partner has given you their Peppol participant ID, in writing, and has confirmed which document types they are registered to receive.
You can open the My Peppol Admin Applet. If it is not in your applet list, ask your BigLedger contact to add it.

Step 1: Turn Peppol on for the company

Outcome: finalised documents from this company start producing Peppol waiting-queue rows.

Organisation Applet → your company → Peppol Config

Set the company’s Peppol status to enabled. Nothing enters the Peppol pipeline for a company that is not enabled — no queue row, no error, exactly as with the LHDN e-invoice switch.

Then, on the same tab, look at Notification Config and its peppol checkbox. That is a different switch for a different moment: Peppol Status puts a row in the waiting queue when the document is finalised, and the notification checkbox puts one there again after LHDN accepts the e-invoice. They are not a pair to tick together. Each row becomes its own Peppol document, both are built from the same invoice, and nothing removes the duplicate — with both on, your partner receives the same invoice twice. (On 2026-09-19, 35,000 documents across BigLedger’s tenants were sitting in the waiting queue with two rows each.) Choose the moment you want the partner to receive the invoice: at finalise, or only once LHDN has accepted it. Which of the two BigLedger recommends is an open question (Q-1143); until it is answered, pick one and leave the other off. The checkbox also exists on each customer record, and either the company’s or the customer’s being ticked is enough.

The other two boxes on that screen — other UCC channels and through customer portals — are not read by anything today. Ticking them changes nothing.

GadgetSphere enables GSD only. The retail company sells to walk-in shoppers who have no participant ID, so there is nothing for it to deliver.

Ask your BigLedger contact to schedule the Peppol processors at the same time. A new tenant is given a standard set of scheduled jobs, and no Peppol processor is in it. Without them, everything above works and the waiting queue simply fills up: no error, no e-mail, and nothing on the screen saying why. This is worth asking for in the same message as the applet access in Before you start.

Step 2: Register your company’s Peppol participant ID

Outcome: your company is published on the Peppol network and can be addressed by other participants.

My Peppol Admin Applet → Peppol Config → Registration → Create

A participant ID is two parts joined by a colon — a scheme and an identifier. The form asks for them separately:

Special Identifier — which kind of Malaysian registration the identifier is. The list is 01 SSM number, 02 Sabah, 03 Sarawak, 04 foreign businesses, 05 testing.
Business Identifier — the registration number itself.

You also fill in the business card that will be published in the Peppol directory: company name and registration number, country, contact name, e-mail and phone, and any websites or additional identifiers you want listed. Then upload the KYC document — the PDF that evidences the company’s identity. BigLedger signs it into the Malaysian service metadata publisher for you.

Peppol ID Registration listing with Company Code, Company Name, Company Reg. No., Registration Date and Registration Status columns — Peppol Config → Registration — one row per company you have registered, with the registration status.

Do not invent or copy a participant-ID format from another country’s documentation. Malaysian participants are published under scheme 0230, so a finished ID looks like 0230: followed by your special identifier and registration number. Every Malaysian participant ID in BigLedger’s production tenants uses that prefix. An ID built with any other prefix will not resolve, and the symptom is not a validation message — it is a delivery that silently never arrives.

Sabah and Sarawak take longer. Registrations under special identifier 02 or 03 are checked by hand at the local authority, which takes 2 to 10 working days. Start those first and plan the rest of your go-live around them.

Step 3: Record your trading partner’s participant ID

Outcome: BigLedger knows where to send this customer’s documents.

Customer Applet (or Supplier Applet) → the trading partner → Peppol Config tab

Add the participant ID your partner gave you and mark exactly one of them as the default. The default is the address BigLedger uses when it builds the document.

The most common failure on this whole page lives here. A customer with Peppol IDs on file but none marked default produces a Peppol document stamped “Missing Peppol Sender or Receiver ID”, which stops before it is ever sent. So does your own company having registered IDs with none of them flagged default — the sender and the receiver are read the same way, by the default flag, one from your company’s list and one from the customer’s. If your first document stalls, check those two flags before anything else.

Step 4: Make sure the master data LHDN needs is complete

Outcome: the Peppol document can be built and passes the network’s own validation.

Peppol does not have its own data requirements to learn. It builds its document from the same fields the LHDN pipeline needs — buyer and supplier name, tax number, identity type and value, an address with line 1, city and state, a contact number of 8 to 20 characters, industry code, and the classification and tax fields on every line.

What is different is when you find out. Nothing checks these before the document enters the waiting queue, so an incomplete customer does not hold the row back — it produces a Peppol document that cannot be built, one stage later. If you have already worked through MyInvois Setup, this step is done. If a document is failing the check, Validation Rules & Troubleshooting names the field.

The capture that sat here was withdrawn: it showed an entity details pane carrying a mobile telephone number beside a passport identity type. A recapture from a synthetic demo tenant will replace it.

Step 5: Know which documents can actually travel

Outcome: you do not spend a morning wondering why a debit note never arrived.

BigLedger builds four Peppol documents, and nothing else:

What you raise	What travels
Sales invoice, cash bill	Peppol invoice
Sales credit note, sales return	Peppol credit note
Purchase invoice flagged self-billed	Peppol self-billed invoice
Purchase debit note or purchase return flagged self-billed	Peppol self-billed credit note

A sales debit note, a sales refund note, and a self-billed purchase credit note or refund note have no Peppol shape. They pass the earlier checks, reach the point where the document would be built, and then produce nothing — with no message telling you so. If you need to send one of those to a trading partner, send it the way you always did and say so in the covering e-mail.

Step 6: Carry the order reference onto the invoice

Outcome: your partner’s system accepts the invoice on its business rules, not just on transport.

If the sale started life as a purchase order or a sales order, make sure that number is on the invoice. It is carried onto the Peppol document as the order reference, and the Malaysian profile’s validation looks for it. A document can cross the network perfectly and still be turned down at the far end for nothing but a missing order reference — which reads as “Peppol is broken” and is not.

Step 7: Send one document and follow it through

Outcome: proof on a real sale that the whole chain works.

Finalise one straightforward invoice to the partner you set up in Step 3, then walk it through the three screens in order:

My Peppol Admin Applet → Waiting Queue — the finalised document, which arrives here the moment you finalise it, with a blank Status (the column reads a field the queue does not have — nothing is wrong). It leaves when the scheduled sweep builds it, once a day on most tenants that have the sweep at all, twenty documents a run. Process runs one such sweep now — twenty rows in database order, not the row you selected — so on an empty test queue it moves your invoice, and on a busy one it may not. (The Posting Queue beside it stays empty; see the warning near the top of this guide.)
Internal Submission → To Peppol AP — the Peppol document itself, with the sender and receiver participant IDs on the row. The document vanishes from the Waiting Queue the instant this row is created, before anything is checked, so this is the screen to look at when it disappears. Read the Validation Error: [THIS_DOCUMENTS_IS_VALID] means it passed; Missing Peppol Sender or Receiver ID means a default flag from Step 2 or 3 did not take; anything else is a rule of the Malaysian Peppol profile the document broke. SUBMITTED on this row means handed to the sender, not delivered.
Internal Submission → Queue, then History — the transmission, which starts the moment the document passes validation. A row in Queue with a blank status is in flight; a row with an error status failed and stays until you Submit it again (one at a time) or delete it. A row in History means the partner’s access point signed for it — the only proof of arrival BigLedger can show you.

Internal Submission To Peppol listing with Doc Type, Doc No, Sender ID, Receiver ID, Org ID, Buyer Name and Buyer ID columns — Internal Submission → To Peppol AP — one row per Peppol document built, with the sender and receiver participant IDs you can check at a glance.

When a transmission does not succeed, the queue row says which kind of failure it was:

What the row says	What happened	What to do
AS4 error message received	The transmission arrived and the receiving access point turned it down — most often the receiver is not registered for that document type, or their own validation rejected the business document	Confirm the participant ID and the document types your partner can receive, correct the customer record, resend
Transport error	A network or access-point outage during sending	Resend from Internal Submission → Queue. If it keeps happening, raise a support request
Nothing — the row sits in the Waiting Queue for days	The sweep has no schedule on your tenant (true of most), or it runs once a day and takes twenty rows	Ask your BigLedger contact whether the sweep is scheduled and how often. Process runs one sweep now, for twenty rows of the queue’s choosing
The row left the Waiting Queue and is not in Queue or History	It stopped at validation — a missing default flag, or a profile rule	Open To Peppol AP and read the row’s Validation Error

Internal Submission Queue listing showing rows with AS4_ERROR_MESSAGE and TRANSPORT_ERROR submission statuses and a Submit button — Internal Submission → Queue — failed transmissions, with a Submit button that resends one row at a time.

Step 8: Watch what arrives from the other direction

Outcome: you know where a supplier’s Peppol document lands.

My Peppol Admin Applet → External Reception → Docs Queue / Docs History / From Peppol AP

Documents other participants address to your participant IDs are delivered by the access point into these screens. They also feed the purchase-side matching queue with a match source of PEPPOL — which is one of only two ways a supplier’s document ever reaches BigLedger at all. Incoming Supplier E-Invoices explains what that queue can and cannot do for you.

What success looks like

Thirty seconds, on the company you just set up:

Peppol Config → Registration shows your company with a completed registration status.
One real invoice you finalised today is in Internal Submission → History — not merely marked SUBMITTED under To Peppol AP, and not sitting in the Queue with an error.
On that invoice’s To Peppol AP row, the Sender ID is your company’s participant ID and the Receiver ID is the one your partner gave you — both beginning 0230:.
Your partner confirms they received it. Until somebody at the other end says so, you have tested four screens and not a delivery.

Common mistakes

Mistake	What you see	Fix
Building a participant ID from a format found elsewhere	Nothing arrives, and nothing reports an error	Malaysian participant IDs are published under scheme `0230`. Register through Peppol Config → Registration rather than typing an ID you constructed
Several Peppol IDs on a customer, or on your own company, and none marked default	“Missing Peppol Sender or Receiver ID” on the to-Peppol document	Mark exactly one as default on each side — the customer’s Peppol Config tab and your company’s
Turning Peppol Status and the peppol notification box on	The partner receives every invoice twice — once at finalise, once after LHDN accepts it — and two rows per document build up in the Waiting Queue	Choose one moment and switch the other off (which one BigLedger recommends is Q-1143)
Pressing Process and expecting it to send the document you ticked	The document you were looking at is still in the Waiting Queue; twenty other rows moved	Process runs one sweep of twenty rows in database order and no row can be selected. Wait for the schedule, or press it again
Reading SUBMITTED under To Peppol AP as delivered	The partner has nothing; the row is in Internal Submission → Queue with an error	SUBMITTED is written before the send. Only a row in History is a receipt
Waiting for the Posting Queue to show something	It never will — that route is dormant on every tenant	Watch the Waiting Queue
Going live without asking for the Peppol processors to be scheduled	Everything configures cleanly, the Waiting Queue fills, nothing is ever sent, and there is no error anywhere	Ask your BigLedger contact to schedule them; none of them is in the default set a new tenant gets
Expecting Peppol to wait for LHDN	Confusion about why a document went to a partner while its e-invoice is still Invalid	The two pipelines are independent. Fix each on its own screen
Sending a debit note, a refund note, or a self-billed credit or refund note	The document never appears in To Peppol AP and nothing says why	Only invoices and credit notes — plain and self-billed — have a Peppol shape. Deliver the rest the way you did before
Leaving the purchase-order number off the invoice	The transmission succeeds and the receiver rejects the document	Carry the PO or SO number onto the sales document so it becomes the order reference
Registering a Sabah or Sarawak company the week you go live	The registration is still pending on launch day	Those two are verified by hand and take 2 to 10 working days. Register them first