Peppol Configuration Guide
Watch this as a presentation — 1 on this page, slides with narration.
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 a sender or receiver ID is missing.
- 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 the moment LHDN accepts the submission — which is before LHDN has said Valid, so this row does not wait for validation either. Step 1 covers both, because turning on one and not the other is the commonest way a new company ends up half-configured.
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.
Peppol configuration: 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 Organisation Applet (registration and IDs) and the My Peppol Admin Applet (the queues). If either 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 once LHDN has accepted the submission (accepted, not yet validated — the row is written when the submission goes through, before Valid or Invalid comes back). 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 the e-invoice has been submitted. 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 the two are read together as an or: the company’s tick or the customer’s tick is enough on its own, and unticking one side does not switch the row off while the other is still on.
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.
The Peppol processors have to be scheduled, and a new tenant does not get them. A tenant is created with 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.
Check whether it is yours to do. Open the Scheduler applet, press +, and click Scheduler Code. If EINVOICE_WAITING_QUEUE_TO_XAP_DOC_PROCESSOR is in the Select Processor picker, you can schedule it yourself — every fifteen minutes is a sensible starting cadence for a queue that takes twenty rows a sweep — and press Run once to prove it works. If the picker does not offer it, that part is ours: ask in the same message as the applet access in Before you start, and name the processor code, the cadence you want and your tenant (what to send).
Step 2: Register your company and add its participant ID
Outcome: your company is published on the Peppol network, and BigLedger’s access point knows that anything addressed to it belongs to you.
Organisation Applet → your company → Peppol Config
This is the same tab as Step 1, and it has two sub-tabs that do two different jobs. You need both, in this order: Peppol Registration puts your company on the network, and Peppol Ids is what makes it addressable. Registering does not do the second job for you.
First, register — the Peppol Registration sub-tab. Press + and fill in the form:
- Special Identifier — which kind of Malaysian registration the identifier is. The list is
01SSM number,02Sabah,03Sarawak,04foreign businesses,05testing. - Business Identifier — the registration number itself.
- The business card that will be published in the Peppol directory: company name and registration number, contact name, e-mail and phone, and any websites or additional identifiers you want listed.
SAVE stores the registration as a draft. BigLedger builds your participant ID from the first two fields: 0230: + special identifier + registration number. For GSD, registered with SSM, that is 0230:01 followed by its SSM number. Write it down, because you type it again below.
A draft is not on the network. Tick the row in the Peppol Registration list and press Final. That is the moment BigLedger creates your participant with the Malaysian service metadata publisher (SMP), the directory other access points look you up in. Then open the row again. A Sign With Pdf tab is shown once the registration is FINAL. Choose the KYC document there (the PDF that evidences the company’s identity) and press Sign With PDF. BigLedger stores the file and signs it into the SMP for you, and if the SMP refuses it the upload fails with an error rather than looking as if it worked.
Then add the ID — the Peppol Ids sub-tab. Press +, type the participant ID the registration produced, and press Verify Participant ID. Verify looks the ID up in the SMP, so it passes only once the registration is FINAL, and Add stays greyed out until it does. Switch Default on and press Add.
Adding the ID is the step that makes you routable. When you add it, BigLedger writes a routing row at its access point that sends any document addressed to that ID to this company. Changing or deleting the ID changes or removes the row with it. A registration with no ID behind it on Peppol Ids has no routing row, so a partner’s document addressed to you is delivered to nobody. The default ID is also the sender on every document you send (Step 3).
How you know it worked. On your side: the registration row says FINAL, and the ID is listed on Peppol Ids with Default on. You cannot see the routing row from your tenant, so the last check is BigLedger’s. Ask your BigLedger contact to confirm it: an operator opens your tenant in the access point’s Registered Companies screen and looks for exactly one row for your ID, against GSD. No row means the ID was never added on Peppol Ids. Two rows mean two companies hold the same ID, and both receive every document sent to it.
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.02 or 03 are checked by hand against the state registry, and MDEC — which runs the Malaysian Peppol authority — puts that at 2 to 10 working days. The figure is MDEC’s, not BigLedger’s, and nothing in the applet speeds it up. 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 the builder refuses, 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.
Screenshot withdrawn; a recapture from a demo tenant is on the list.
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 |
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 — typically a daily run, twenty documents at a time, and only if the sweep has been scheduled for you at all (see Step 1). 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.
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, the outage is at the access point rather than in your data and there is nothing in the applet that will fix it — send the document numbers, the UTC times of the failed attempts and your tenant (what to send) |
| Nothing — the row sits in the Waiting Queue for days | The sweep has no schedule on your tenant — none is set up by default — or it runs once a day and takes twenty rows | Process runs one sweep now, for twenty rows of the queue’s choosing, which clears today’s backlog and tells you nothing about tomorrow’s. For that, open the Scheduler applet: a row for EINVOICE_WAITING_QUEUE_TO_XAP_DOC_PROCESSOR with Status ACTIVE and a recent Last Run Date is the answer. No such row, and the picker offers the code, means you can add it yourself |
| 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 |
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:
- In the Organisation applet, on your company’s Peppol Config, the Peppol Registration row is FINAL with the KYC PDF signed, and your participant ID is on Peppol Ids with Default on. BigLedger has confirmed one row for that ID in Registered Companies.
- 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 on the Organisation applet’s Peppol Config → Peppol Registration and add the ID it produced, rather than typing an ID you constructed |
| Registering in My Peppol Admin → Peppol Config → Registration | The form saves without complaint, and nothing exists: no registration, no ID, no routing row | That screen sends nothing. Register and add the ID on the Organisation applet’s Peppol Config tab (Step 2) |
| Registering, but never adding the ID on Peppol Ids | Every invoice you send stops at Missing Peppol Sender or Receiver ID, and nothing your partners send you arrives | Add the registered ID on Peppol Ids with Default on. That is the step that writes the routing row |
| 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 when LHDN accepts the submission — 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 — the gate on that route is never opened, so nothing is written there | Watch the Waiting Queue |
| Going live without scheduling the Peppol processors | Everything configures cleanly, the Waiting Queue fills, nothing is ever sent, and there is no error anywhere | Schedule them in the Scheduler applet before the first document, not after — none is in the default set a new tenant gets. Press Run once and watch a row leave the Waiting Queue; that is the only proof that counts |
| 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 MDEC’s own figure is 2 to 10 working days. Register them first |