Supplier e-invoices: the manual check, self-billing and month-end
Steps 4 to 6 of handling incoming supplier e-invoices: check by hand the supplier e-invoices BigLedger cannot pair, self-bill the purchases for which LHDN puts the obligation on you, and read the month-end report correctly. It follows Steps 2 and 3, and it works from the export of PD Matching Q. you took in Step 1. For GadgetSphere, around 20 authorised distributors account for the overwhelming majority of the spend, so you check the big suppliers properly and spot-check the rest. Decide who clears rows before anybody starts: clearing a row says I have seen this supplier’s e-invoice, and nothing in BigLedger checks that they did.
- Step 4: check the rest by hand, and clear them off the list.
- Step 5: when the supplier will not issue one.
- Step 6: know what month-end can and cannot prove.
Step 4: Check the rest by hand — and clear them off the list
Outcome: every purchase above your review threshold has a validated supplier e-invoice on file, and your worklist shrinks as you go.
This is the step that does the real work, because Step 3 covers only the small fraction of suppliers who deliver electronically.
Your supplier’s validated e-invoice reaches you the way any invoice does — by e-mail, from their own portal, or with the goods. What makes it a validated e-invoice rather than an ordinary invoice is that it carries an LHDN identifier and a QR code. If those are not on the document, LHDN has not cleared it, whatever the covering note says.
Take the export from Step 1 and, for each purchase you review, check four things against the supplier’s document:
- The buyer is you — your company’s name and tax number, not a sister company’s. GadgetSphere buys through three legal entities (
GS,GSOandGSD), and a distributor billing the retail company while e-invoicing the distribution company is a common and expensive mistake. - The amount agrees with the purchase invoice you booked.
- The document date falls in the period you are closing. A supplier who e-invoices late puts their document in a different month from your purchase.
- The supplier’s tax number is on it and matches your supplier record. Where they differ, yours is usually the stale one.
File the supplier’s validated e-invoice with the purchase document, the way you file a delivery order. Nothing in BigLedger stores it for you.
Then clear the row: select it in PD Matching Q. and press Push to Unmatched History. That is what the button is for — “I have dealt with this one, it is not waiting for an electronic counterpart.” It parks the row in Unmatched PD Hist., and Pushback to PD Matching Queue on that screen brings it back if you clear something by mistake. Used this way, the queue becomes a genuine month-by-month worklist instead of a list that only grows.
Clear two other kinds of row the same way. A purchase you voided stays on the list (Step 1), so clear it with a note of the void. And on Inc. E-Invoice Match Q., clear each supplier document you have dealt with by hand, so that Auto Match reaches the ones behind it (Step 3). Purchases you booked as Purchase Invoice No Stock In never reach the list at all; if you book that way, run the same four checks from that document type’s own listing.
Decide who clears rows. Clearing a row is somebody saying I have seen this supplier’s e-invoice, and nothing in BigLedger checks that they did. In a group the size of GadgetSphere, the person who keys purchase invoices should not be the only one clearing them. Each month, have someone else take a handful of rows from Unmatched PD Hist. and ask to see the filed e-invoice for each.
The most common thing that stops you here is a supplier who will not produce an e-invoice at all — either because they are not yet inside their LHDN compliance phase, or because the obligation is not theirs. That is Step 5.
Step 5: When the supplier will not issue one
Outcome: the purchase is still reported to LHDN — by you.
For certain transactions LHDN puts the obligation on the buyer instead of the seller. In BigLedger those are ordinary purchase documents flagged as self-billed. They go through exactly the same submission pipeline as your sales e-invoices, with the roles swapped: your company is the buyer, and your supplier is the issuer of record.
Three things to know before you flag anything:
- A self-billed purchase document never appears in the PD Matching Queue, by design. You are issuing the e-invoice, so there is nothing incoming to pair it with. Between them the two routes take every purchase document of these types: a self-billed one goes out through the submission pipeline, any other comes to the matching list if its supplier has a tax number. One that is both self-billed and marked Skip E-Invoice goes to neither.
- You watch its progress on the purchase document itself, on the E-Invoice tab: Submission holds the submission type and the supplier’s identity block, and Progress shows it moving through the four stages — pending in the posting queue, in the batch pool, in the submission queue, submitted to LHDN.
- A self-billed line usually comes from an expense account rather than a stock item, so it has no item classification code to inherit. A blank classification is sent as
022 Others, which may not be what you want on the document.
Step 6: Know what month-end can and cannot prove
Outcome: you read the Discrepancies Report correctly instead of chasing a zero that is supposed to be zero.
My E-Invoice Admin Applet → Monthly Report → Discrepancies Report
Its IRB Audit Summary tab gives each document type an Internal Submission figure with a Cancelled figure beside it, and carries two further rows: From E-commerce (self billed) and From Supplier (Matched).
Those last two figures always read zero — nothing in BigLedger fills them, however many pairs you make in Step 3 and whether or not your suppliers send over PEPPOL (applet page). A zero here is not a reconciliation failure and there is nothing to chase. Your record of pairs is Reconciliation (Purchase) → Matched History, together with your own note of each hand-made pair (Step 3). On the purchase document types, the Internal Submission figure counts only the e-invoices you issued yourself as self-billed (Step 5), because a purchase document enters the outgoing pipeline only when it is self-billed. Your suppliers’ e-invoices are not counted anywhere on this report. The rest of the report is sound: it compares the documents you finalised against the e-invoices BigLedger raised for them, in both directions, and it is what the month-end cycle is built on.
What success looks like for this part
Every purchase you reviewed on PD Matching Q. is matched or pushed to Unmatched PD Hist., with the supplier’s validated e-invoice filed with it; someone other than the person who keys purchase invoices has taken a handful of cleared rows and seen the filed e-invoice for each; and every purchase you flagged self-billed shows on its E-Invoice tab, under Progress, that it was submitted to LHDN. You count your pairs on Matched History, not from the From Supplier (Matched) figure, which always reads zero. Then run the whole routine’s success check.
Common mistakes in this part
| Mistake | What you see | What to do instead |
|---|---|---|
| Chasing the zero in From Supplier (Matched) | RM 0 against every document type in that column of the Discrepancies Report | It is always zero — nothing fills it, even when you have made pairs. Count your pairs on Matched History, and reconcile from the Internal Submission figures and the Document vs E-Invoice Discrepancy tab |
The mistakes that span the whole routine are on the front page.
Related documentation
- Incoming Supplier E-Invoices: the whole routine, with its success check.
- The Month-End E-Invoice Cycle: the reconciliation Step 6 feeds into.
- Purchase Invoice Applet: where a purchase document, self-billed or not, is created.
- Supplier Applet: the tax number that decides whether a purchase reaches the matching queue.