Use Cases
Watch this as a presentation — 1 on this page, slides with narration.
“The customer has no TIN. What do I send?” That depends on who the customer is, and that is what this page is about. A walk-in buying a cable, a company buying forty laptops, a freelance agent you pay, a software vendor abroad and a partner who wants documents delivered to their own system each take a different road to LHDN, and the road is decided at the moment a document reaches FINAL. Each shape below says who does the job, what BigLedger does behind the screen and what it leaves to a person, and how you know it went right. After the shapes come what they share: where every status comes from, what goes wrong, what none of them will do for you, and the monthly check.
The running example is GadgetSphere Sdn Bhd: the retail company GS with 22 branches, the online
company GSO, and the distribution company GSD that sells to corporate customers, SST-registered,
buying some stock in US dollars from regional distributors.
What decides the road, before any shape
Pressing Finalise does not talk to LHDN. A background job reads the document once and sends it to one of three places, or nowhere: the company’s E-Invoice Status must be ENABLED, the document must be a sales document — or a purchase document with Self-Billed switched on — and Skip E-Invoice must be off. Then the document’s submission type decides:
- Consolidated goes to the Batch Pool to wait for the month’s consolidated e-invoice — unless it is a sales invoice or cash bill of RM 10,000 or more, which is diverted to the Individual Pool.
- Individual, Single General or blank goes to the Posting Queue. There BigLedger builds the e-invoice and checks the mandatory fields. Complete, it is sent. Incomplete, it is parked in a pool by its submission type, and a blank one goes to the Batch Pool — for a sales invoice or cash bill, only under that RM 10,000 line.
The pool is the design, not a fault: a pool never sends a document that is not ready, and it never guesses a buyer on your behalf. The cost is that a pooled document waits, quietly, for a run or a person (Pools and queues).
1. Invoicing a business customer
The shape. GSD sells 10 ultraportable laptops at RM 3,800 to a corporate client and invoices them:
RM 38,000 of sales and RM 2,280 of SST, RM 40,280 in all. The client has a tax number and wants a
validated e-invoice in its own name.
What BigLedger does. A new sales invoice starts with the submission type Individual. At FINAL it goes to the Posting Queue; the posting run builds the e-invoice from the document’s e-invoice buyer block, or from the customer record when that block is empty, and checks it. Passed, it is sent, and the status check copies LHDN’s verdict back. On the default clocks each of those three hops runs every ten minutes, so an invoice finalised this morning normally reads Valid well before lunch. Nobody approves anything on the way: FINAL is the trigger.
Two things happen that the screen does not announce:
- At RM 10,000 or more, a business registration number with no tax number is looked up for you. BigLedger asks LHDN for the tax number and writes it onto the customer record, the invoice and the e-invoice. The RM 40,280 invoice qualifies; a RM 3,800 one for a single laptop does not.
- The buyer is copied when the e-invoice is built, not read live. Correcting the customer record afterwards changes the next invoice, not this one.
When the customer is a chain with forty outlets
A pharmacy chain buys from GSD on one account, and each outlet wants its own address on the e-invoice.
The sales invoice’s E-Invoice tab offers one of two buttons, chosen by a setting: Select Einvoice
Address, which picks one of this customer’s billing addresses and changes only the address, or Select
From Another Customer, which copies a different customer’s whole buyer block. The chain’s outlets are
billing addresses on one customer record, so the first is the one you want; the second exists for the
employee who buys for his employer
(scenario: the buyer is not the account).
When the distribution company should never consolidate
GSD sells to businesses only, so nobody there should mark an invoice Consolidated. The company’s
Disable Consolidated Submission switch takes that choice out of the drop-down on its documents —
enforcement at the point of choice, which is the right control when the mistake would be a person’s. It is
not a switch on the consolidation run: the run stamps Consolidated on what it builds and reads the
switch at no point, and it still takes any GSD receipt that reached the Batch Pool another way. Both halves
are true; BigLedger has confirmed the switch is meant to govern the choice only.
Where it goes wrong. Nearly always the buyer’s details:
- A missing field — no identity type, an address without a state, a phone number shorter than 8 characters — parks the invoice in the Individual Pool, with the missing fields named on the row. It waits there for a person, for as long as it takes.
- A wrong tax number that is present passes BigLedger’s own check, which tests that the field is
filled, not that it is right. LHDN refuses it — either at the door, which leaves the e-invoice reading
IN_QUEUEwith the reason on its submission-queue row, or as Invalid with the reason on the record. - A rejected e-invoice left past month-end on an invoice under RM 10,000 —
Invalid, or refused by LHDN when it was sent — is swept into the month’s consolidated e-invoice under General Public (since 13 October 2026; one never sent is left for the submission run). That is right for a walk-in and wrong for a corporate client who wanted its own document.
Whose job, and how they know. The billing clerk checks the buyer block on the E-Invoice tab before FINAL, because nothing compares it with the client’s purchase order. Whoever owns e-invoicing reads the Individual Pool and the IN_QUEUE and Invalid rows on To IRB E-Invoice every morning, and clears failed sends inside the month. The account manager passes on anything the client says about rejecting an e-invoice: a rejection made on LHDN’s MyInvois portal lands in BigLedger only as a date on the record, and creates no request anyone is shown. They know a day went right when every invoice finalised yesterday reads Valid.
2. Consolidating a month of retail receipts
The shape. Twenty-two branches selling to walk-in shoppers who have no tax number to hand and no interest in giving you one — roughly 38,000 receipts a month.
What BigLedger does. Each cash bill finalises normally: the sale, the stock and the accounting are right at once. A new cash bill starts with no submission type, so a shopper who gives complete details gets an individual e-invoice and one who does not is parked in the Batch Pool, with the reason on the row. From the 1st of the next month a consolidation run takes last month’s unprocessed rows in batches, groups them by company and document type, and builds one consolidated e-invoice per group under the buyer General Public, dated the last day of the receipts’ month. A consolidated submitter then sends them, one document per call to LHDN. They must be validated by the 7th of the following month (Consolidated e-invoices).
The RM 10,000 line — LHDN’s and BigLedger’s, one sen apart. LHDN bars consolidation of a single transaction exceeding RM 10,000. BigLedger diverts a sales invoice or cash bill of RM 10,000 or more to the Individual Pool, and refuses a manual move of one back into the Batch Pool. So a RM 10,000.00 sale needs the buyer’s real identity too, which means capturing it at the counter, not discovering it on the 3rd. The company setting Enable high sales value validation makes the till refuse Final on a new RM 10,000+ bill until the buyer block is complete.
The arithmetic to plan around. At the default, the consolidation run takes 100 receipts every half hour. 38,000 receipts at 100 a run is 380 runs — nearly eight days, past the 7th. BigLedger can give your tenant’s consolidation clock a bigger batch or a shorter interval, so what yours does is on its own Scheduler row, and reading that row in the last week of the month is cheaper than finding out on the 6th. Sending goes one document per call to LHDN; plan on a few hundred an hour.
By document or by branch. BigLedger has two consolidation runs, and the document LHDN receives differs: the default prints one receipt per line; the by-branch run, which support schedules in its place, prints ranges of a branch’s document numbers and caps a document at 200 lines. Which one you are on is a Scheduler row, not a company setting (the two side by side).
Whose job, and how they know. Branch supervisors make sure a big sale leaves the counter with a buyer identity. Whoever owns e-invoicing works the Individual Pool before the month ends, checks on the 1st that the consolidation clock is ACTIVE and recent, and on the 3rd that last month’s Batch Pool is emptying. They know the month is reported when every consolidated e-invoice dated last month reads Valid and the Batch Pool holds nothing unprocessed from it.
3. Self-billing a supplier who cannot invoice you
The shape. GadgetSphere pays local freelance agents who are not required to e-invoice, and buys software subscriptions from foreign vendors who have never heard of MyInvois. In both cases the law puts the reporting obligation on you: you issue the e-invoice, your company is the buyer, and the supplier is the issuer you report on behalf of.
What BigLedger does. Self-billing is done on the ordinary purchase documents, with Self-Billed switched on, and watched in My E-Invoice Admin — not in a separate applet and not in the buyer portal. Set E-Invoice Self-Bill on a supplier you always self-bill and every new purchase invoice drafted for them carries the flag. Without it, a purchase document never enters e-invoicing at all. Use Purchase Invoice, not Purchase Invoice No Stock In, whose document type is not an e-invoice type.
What reaches LHDN, and as which document
| You raise | LHDN receives |
|---|---|
| Purchase invoice, Self-Billed | 11 Self-billed Invoice |
| Purchase debit note — the one you raise when the bill was too high — or a purchase return | 12 Self-billed Credit Note |
| Purchase credit note — the bill was too low | 13 Self-billed Debit Note |
| Purchase refund note | 14 Self-billed Refund Note |
The names swap sides because LHDN names the document from the issuer’s view, and on a self-billed document the issuer is your supplier. A purchase debit note that reaches MyInvois as a credit note is correct, not a mistake to chase.
The agent with an identity card, and the vendor with no tax number
For a local individual who gives an identity-card number and no tax number, BigLedger sends LHDN’s general
number EI00000000010 in the supplier’s place. That is the only substitution it makes. A foreign vendor with
no Malaysian tax number gets none: the supplier’s tax number is blank, the mandatory check fails, and the bill
is parked. BigLedger knows the foreign-supplier general number EI00000000030, but it does not write it for
you — key it on the vendor’s supplier record, once your tax adviser has agreed it is the right number for
that vendor.
Where a self-billed bill waits, and why nobody notices
A new purchase invoice starts with no submission type. If its supplier details are incomplete, the bill is parked in the Batch Pool at any amount — the RM 10,000 divert covers sales invoices and cash bills only. The month’s scheduled consolidation takes sales rows only, so a self-billed row sits in the Batch Pool untouched, and the purchase it should report stays unreported.
That filter is a reasonable design: a consolidated self-billed e-invoice reports your purchases under a General Public supplier, which is not something to do without a person deciding to. But it is not the whole story. Select that row and press Consolidate, or run on a tenant whose consolidation is by branch, and BigLedger does build a consolidated self-billed e-invoice from it, with your company as buyer. Whether that is what you should file for a given supplier is your tax adviser’s call; the usual intent is an individual self-billed e-invoice in the supplier’s name — Move to Individual, complete the supplier, and Save and Resubmit. Whether the scheduled run’s sales-only rule is meant as the policy is a question BigLedger has been asked.
022
Others without a warning. Self-billed expense lines often have no item behind them, so set the
classification on the items you self-bill against, and check the lines of the first record you submit.Correcting one. BigLedger refuses VOID on a self-billed purchase invoice, debit, credit or refund note, whatever the company’s e-invoice status. Inside 72 hours of validation the route is a cancellation in My E-Invoice Admin; after that, a note that references the original. Which of the two to prefer inside the window is the same choice a sales invoice faces (Cancelling and correcting).
One number, two documents. Sales invoices and self-billed purchase invoices draw their numbers from two sequences that start at the same value, so the same number can appear twice in the submission listing. Check the document type on both rows before you decide anything is a duplicate.
Whose job, and how they know. Your tax adviser decides which suppliers you self-bill, because which transactions oblige you is LHDN’s rule, not BigLedger’s. The accounts-payable clerk switches Self-Billed on (or sets it once on the supplier) and completes the supplier’s identity before FINAL. Whoever owns e-invoicing filters the Batch Pool by document type every week and moves any purchase row out. They know it went right when each self-billed bill’s E-Invoice tab shows a Valid e-invoice, and the Batch Pool holds sales documents only.
4. Exchanging documents over PEPPOL
The shape. Two of GSD’s larger corporate clients want invoices delivered straight into their own
systems rather than e-mailed as PDFs.
What BigLedger does. The same finalised document feeds the Peppol pipeline beside the LHDN one, not after it. The Peppol row is written at FINAL, before LHDN has said anything, so a delivery can succeed while the LHDN e-invoice is still Invalid, and the other way round. Neither tells you anything about the other.
Four things to know before the first one goes.
- Only invoices and credit notes travel, plain and self-billed. A sales debit note, a sales refund note, or a self-billed purchase credit or refund note reaches the point where the Peppol document would be built and produces nothing, with no message. Deliver those the way you did before.
- Two switches put a document in the Peppol queue: the company’s Peppol status (at FINAL) and the peppol box in Notification Config (when LHDN accepts the submission). With both on, the partner receives every invoice twice. Pick one moment. Which one BigLedger recommends is still open, so this page names neither.
- Nothing sends on a clock unless one is set up. No Peppol run is among the default clocks; ask BigLedger to schedule the sweep for your tenant before you promise a client delivery.
- Register in the Organisation applet, under the company’s Peppol Config. The registration form in My Peppol Admin saves nothing.
The thing to plan around. A participant registration for a Sabah or Sarawak registration number is checked by hand at the state registry, and MDEC puts that at 2 to 10 working days. Start those first.
Whose job, and how they know. Whoever owns e-invoicing records each partner’s participant ID on the customer and checks the transmission queue each morning: a failed row stays there until somebody presses Submit on it again. They know a document arrived when it appears in History — the receiving access point’s receipt, and the only proof of arrival BigLedger holds (Peppol configuration).
5. The shopper who comes back for their own e-invoice
The shape. A walk-in at GS-KV-02 buys a laptop on the cash customer’s account and leaves. Three days
later he is back: his employer will reimburse him, and he needs an e-invoice in the company’s name. The cash
bill has posted its journal and stock, and its customer is fixed — rightly, because the record has
reached the ledger.
What BigLedger lets you do. The e-invoice buyer is kept separately from the account you billed, so the tax document can name his employer while the books still say cash customer — which is true, because the money came in as cash. Which route you take depends on when he asks:
| He asks… | The cheap route | The other route |
|---|---|---|
| In the same calendar month | He keys his employer’s details himself in the MY E-Invoice Portal, searching by invoice number, amount and date. Or you complete the buyer on the Batch Pool row and Save and Resubmit | — |
| After month-end, before the run reaches his receipt | You complete the buyer on the Batch Pool row while it reads UNPROCESSED. The portal no longer finds it: it searches receipts dated from the first of the current month | — |
| After the receipt is inside a consolidated e-invoice | — | Sales return against the bill, a new invoice under a proper account, and a contra between them — the only route that changes the accounting party, the expensive one, and a decision to make with your accountant |
At RM 10,000 or more, a receipt with an incomplete buyer waits in the Individual Pool instead of the Batch Pool, and the same Save and Resubmit sends it with his employer as buyer.
Whose job, and how they know. The cashier takes the money and tells the shopper the e-invoice will follow; the queue does not wait. Branch staff tell shoppers ask before the end of the month and it costs nothing. Whoever owns e-invoicing handles the late ones before the consolidation run takes them. They know it went right when the shopper’s e-invoice reads Valid with his employer as buyer, and the cash bill is unchanged.
What every shape needs first, and what it touches
- What must exist first. The company’s E-Invoice Status ENABLED and its LHDN Environment PRODUCTION in Organisation; BigLedger authorised as your intermediary on MyInvois; the pipeline’s clocks ACTIVE on the Scheduler. A document finalised while its company was not ENABLED is never picked up later, so switch the company on before anyone finalises anything.
- What becomes possible. A Valid e-invoice carries LHDN’s validation link and QR, can be e-mailed to the buyer, and is what a credit, debit or refund note references.
- The sibling choice. An individual e-invoice or a consolidated one (shapes 1 and 2); your own self-billed e-invoice or the supplier’s (shape 3); Peppol delivery or the e-mailed PDF (shape 4).
- What breaks elsewhere when it is wrong. The customer and supplier lists belong to the tenant, so Skip e-Invoice on a customer switches that customer off in all three GadgetSphere companies. One clock switched off stops that hop for every company at once. A voided cash bill reverses the books while its Valid e-invoice stays at LHDN.
- What it pairs with. The document applets where sales and purchases are raised, the My E-Invoice Admin screens where they are watched, and the Scheduler, where you confirm the clocks that move them (Related applets).
Where the numbers and statuses in these shapes come from
| What you see | Stored, or worked out when you look | From what, and when |
|---|---|---|
| The submission type on a new document | Stored on the document | Individual on a new sales invoice; blank on a new cash bill and a new purchase invoice. Whatever is on it at FINAL decides the road |
| The buyer on a B2B e-invoice (shape 1) | Copied when the posting run builds the e-invoice | The document’s e-invoice buyer block if it has one, otherwise the customer record as it stood at that moment |
| The RM 10,000 test (shapes 1, 2, 5) | Worked out at FINAL, and again when a row is moved | The document’s transaction amount, on a sales invoice or cash bill only |
| Validation Error on a pool row | Stored | Written when the row was made. Correcting the customer does not change it; Save and Resubmit runs the check again |
| The consolidated e-invoice’s date (shape 2) | Stored at the build | The last day of the receipts’ month, not the day the run fired |
| The buyer on a consolidated e-invoice (shape 2) | Constants | General Public and EI00000000010, read from no customer record |
| The LHDN type on a self-billed e-invoice (shape 3) | Worked out at the build | The purchase document’s type and its Self-Billed flag (the table in shape 3) |
| The supplier’s tax number on a self-billed e-invoice (shape 3) | Copied at the build | The document’s e-invoice supplier block, else the supplier record; EI00000000010 only for an identity card with no tax number |
| The classification on a self-billed line (shape 3) | Copied at the build | The line, else its item, else 022 |
| Valid, Invalid, Cancelled on a record | A copy | LHDN’s answer, written when BigLedger last asked — every ten minutes on the default clock, or when you press Refresh |
| The 72 hours for a cancellation | Worked out when the cancellation is sent | Whole hours since LHDN’s stored validation time, read on the Submission Detail Report — not the invoice date |
When one of these shapes goes wrong
| What you see | The usual cause | What to do |
|---|---|---|
| A finalised document is in no pool, no queue and not on To IRB E-Invoice | The company was not ENABLED, Skip E-Invoice was set on the document, branch or customer, or (a purchase) Self-Billed was off | Fix the cause for future documents; for ones already finalised, ask support to push the named documents into the Posting Queue |
| A corporate client’s invoice sits in the Individual Pool (shape 1) | A mandatory buyer field is missing; the row names it | Complete it on the row and Save and Resubmit, and fix the customer record for next time |
An invoice reads IN_QUEUE the next morning (shape 1) | LHDN refused it at the door; the reason is on its submission-queue row | Fix what the reason names and resubmit, inside the month |
| A corporate client finds its sale inside last month’s consolidated e-invoice (shape 1) | Its e-invoice was Invalid, or IN_QUEUE after LHDN refused it, at month-end and was swept in under General Public | Now a correction for your accountant (Cancelling and correcting); clear rejections inside the month in future |
Last month’s Batch Pool still UNPROCESSED on the 3rd (shape 2) | The consolidation clock is off, or slower than your volume | Read its Scheduler row; or select the rows and press Consolidate |
| A RM 10,000+ sale is missing from the consolidated e-invoice (shape 2) | It was diverted to the Individual Pool | Complete the buyer and Save and Resubmit before the 7th |
| A self-billed bill never reaches LHDN (shape 3) | Self-Billed was off at FINAL, it was raised on Purchase Invoice No Stock In, or it is parked in the Batch Pool | Raise it on Purchase Invoice with Self-Billed on; move a Batch Pool row to the Individual Pool and complete the supplier |
A self-billed line reached LHDN as 022 Others (shape 3) | Neither the line nor its item carried a classification | Set the classification on the item for future bills; a built record keeps what it was built with |
| A Peppol partner received an invoice twice (shape 4) | Both Peppol switches are on | Switch one off |
| A Peppol partner never received a debit note (shape 4) | Debit and refund notes have no Peppol shape | Send it the way you did before Peppol |
| The walk-in’s receipt is not found in the portal (shape 5) | It is dated last month; the portal searches the current month only | Complete the buyer on the Batch Pool row yourself, while it is UNPROCESSED |
What none of these shapes will do for you
Each is a job a person keeps.
- Nothing compares the buyer block with the customer’s purchase order. The billing clerk does, before FINAL (shape 1).
- Nothing warns that a pooled document is ageing. Whoever owns e-invoicing reads the Individual Pool, the IN_QUEUE and Invalid rows, and the Batch Pool’s purchase rows every week, and all of them in the last week of the month.
- Nothing tells you a customer rejected an e-invoice on MyInvois. The account manager passes on what the client says, and whoever owns e-invoicing reads the MyInvois portal (shape 1).
- Nothing decides which suppliers you self-bill, or fills in a foreign vendor’s tax number. Your tax adviser decides; the accounts-payable clerk keys it on the supplier record (shape 3).
- Nothing confirms a Peppol document arrived except History. Whoever owns e-invoicing reads it, and resends from the queue (shape 4).
- Nothing checks that the consolidated totals match the month’s sales. The accountant compares them in the Discrepancies Report (shape 2).
How you know a month of e-invoicing went right
About twenty minutes, per company, between the 1st and the 7th.
- Nothing is waiting for a person. The Individual Pool and the Single General Pool hold nothing from last month. You are done when both are empty or every row has a name against it.
- The Batch Pool is sales only, and empty for last month (shapes 2, 3). Filter by document type and by
date. You are done when no purchase row is there and no last-month row reads
UNPROCESSED. - Every record from last month has a verdict (shapes 1, 3). On To IRB E-Invoice, nothing from last
month reads
IN_QUEUE, Submitted or Invalid. You are done when each one reads Valid or Cancelled. - The consolidated e-invoices are in (shape 2). Every consolidated e-invoice dated the last day of last month reads Valid. You are done when none is still queued.
- The amounts agree. Run the Discrepancies Report for last month. You are done when every line in Exists in ERP, Missing in Einvoice is explained — a skipped document, or one you are still fixing. The report counts documents in the company’s own currency only, so check foreign-currency sales from the document listing.
- Peppol arrived (shape 4). Each partner’s invoices from last month are in History. You are done when the transmission queue is empty.
The daily version of steps 1 and 3 is the module’s five-step check.