Related Applets
“The buyer on the e-invoice is not the customer I billed. Is that wrong?” No. It is the clearest sign that e-invoicing sits beside your other applets rather than inside them. The sale belongs to the sales or point-of-sale applet. LHDN gets an e-invoice buyer that is kept separately on the document. The tax number and address come from Customer Maintenance only when that buyer block is empty, and whether anything is sent at all depends on Organisation. A walk-in can buy on the cash customer’s account and still receive an e-invoice in his employer’s name a few days later, without the journal or the stock changing.
This page is for the accounts person who answers for e-invoicing across a group. It covers which document applets send to LHDN and which do not, what each one depends on in another applet, what e-invoicing writes back into those applets, and how to catch a sale that went missing between them. The four e-invoice applets themselves, and whose screen each one is, are on the E-Invoice applets page. The pipeline and the daily check are on the module page.
Which document applets send to LHDN
A document is picked up at FINAL, by a background job. It is never picked up when you save it, and none of these applets sends anything to LHDN itself. It enters only if its company is ENABLED and it is not marked Skip E-Invoice. Everything after that is in My E-Invoice Admin.
| Document applet | Enters e-invoicing | What to know |
|---|---|---|
| Sales Invoice | Always | A new invoice starts as Individual. At RM 10,000 or more, Consolidated is overridden and the invoice goes to the Individual Pool |
| POS General (cash bills) | Always | A new bill starts with no submission type. The same RM 10,000 rule applies. With Enable high sales value validation on, the till refuses Final on a new RM 10,000+ bill until the buyer block is complete |
| Sales Credit Note, Sales Debit Note, Sales Refund Note, Sales Return | Always | They carry the original e-invoice’s reference. The RM 10,000 rule does not apply to them |
| Recurring Sales Invoice | Through the invoice it creates | Each occurrence is an ordinary sales invoice, and it is reported when somebody finalises it |
| Purchase Invoice, Purchase Credit Note, Purchase Debit Note, Purchase Refund Note, Purchase Return | Only when marked Self-Billed | You become the issuer and your company is the buyer. An ordinary supplier bill is your supplier’s e-invoice to report, not yours |
| Purchase Invoice No Stock In | No | Its document type is not an e-invoice type. If you self-bill, raise the bill on Purchase Invoice |
| Sales Invoice No Stock Out | No | Its E-Invoice tab is there, and nothing fills it |
Decide the skip before you finalise. At FINAL, BigLedger copies Skip E-Invoice onto the document from any of three places: the document itself, its branch, or its customer. If the company has Peppol on, a Peppol row is written at the same moment and reads that flag. Skipping a sale later, from a pool, takes it off the LHDN path. The Peppol row already written stays, and the Peppol sweep still builds and sends it.
What each neighbouring applet must hold first
None of these stops a document from finalising. A gap shows up later in My E-Invoice Admin, as a pool row, a failed send or a missing record.
| What must be right | Kept in | What you see when it is not |
|---|---|---|
| The company’s E-Invoice Status is ENABLED | Organisation → company → E-Invoice tab | Nothing at all. A new company starts DISABLED. Switching it on later does not pick up the documents finalised before |
| The company’s LHDN Environment is PRODUCTION | Same tab | Records come back Valid from LHDN’s sandbox, which means nobody has received them. A blank counts as sandbox. The tell is the record’s Validation URL, which starts with preprod. |
| BigLedger is authorised as your intermediary on the MyInvois portal, and configured for the company’s environment | The MyInvois portal (you), and the company’s intermediary configuration for that environment | Every send for that company fails. With no configuration for that environment the message is BigLedger’s own, No intermediary config found. A lapsed authorisation shows no BigLedger message: the records stay IN_QUEUE and each submission queue row carries LHDN’s refusal |
| The company’s own tax identity, MSIC code, address and phone | Organisation → company | The supplier half of every sales e-invoice fails the mandatory check, so whole days of documents land in a pool |
| The buyer’s tax number, identity type and value, phone, e-mail, and an address marked as the e-invoice default | Customer Maintenance | The document waits in a pool. This is the commonest reason documents end up in one. BigLedger uses the first default e-invoice address it finds, checking shipping, then billing, then main |
| For self-billing, the supplier’s identity, and E-Invoice Self-Bill on the supplier if you always self-bill them | Supplier | Without the flag the purchase document is never reported. With missing identity it waits in a pool |
| The item’s classification and e-invoice unit | Doc Item Maintenance | A blank is sent as 022 Others and piece, and LHDN accepts it. A wrong code is sent exactly as it is |
| The tax code on each line | Tax Configuration | Less than it seems: the tax type is worked out again from the line’s tax amount. Only a taxed line keeps a type of 02 to 05 |
| The background runs | Scheduler | Documents stop at whichever queue has no clock behind it (module check, step 2) |
The customer and supplier lists are the group’s, not one company’s. There is one list for the whole tenant. A customer’s tax number, e-invoice address and Skip e-Invoice flag apply in every company that sells to them. Skip a customer for one company’s convenience and that customer is skipped in all three GadgetSphere companies.
What e-invoicing writes back into other applets
E-invoicing posts no journal of its own. It does write into the documents and records that other applets own, and the person who owns those applets should know when it happens.
- On the source document: the Skip E-Invoice flag, and the e-invoice reference, number and status you see on the document’s E-Invoice tab.
- Voids and reversals. A cancellation approved with Void original document voids the sale in its own applet, which reverses its stock and journal as any void does. New reversal document raises and finalises a reversing document, which posts. Both are chosen in My E-Invoice Admin, and the effect lands in the sales or purchase module.
- The customer record. When a sale of RM 10,000 or more has a business registration number and no tax number, BigLedger looks the tax number up at LHDN and writes it onto the customer. When a buyer submits their details in the MY E-Invoice Portal, the customer’s whole address book is replaced by the one address they typed.
- The VOID button. Once a company is ENABLED, BigLedger refuses VOID on a sales invoice, credit note, debit note, refund note or sales return. The route is the document’s Cancellation tab, or a note. A self-billed purchase invoice, credit, debit or refund note is refused VOID whatever the company’s status. (What a void undoes has the full list.)
The exception that catches tills: a cash bill can still be voided after its e-invoice is Valid. The bill and its stock and journal are reversed, and the e-invoice stays Valid at LHDN. LHDN then holds a sale that your books no longer have. Whoever voids a bill tells the person who runs My E-Invoice Admin, who cancels it within 72 hours of validation or issues a credit note (Cancel and correct).
A week at one GadgetSphere branch
On Monday, a walk-in at GS-KV-02 buys four ultraportable laptops at RM 3,400 each, RM 13,600 in all, and
pays by card. The cashier finalises a cash bill on the cash customer with an empty buyer block. The company
has Enable high sales value validation switched off, so the till lets the sale through.
- At FINAL the bill posts its stock, journal and cashbook as usual. On the e-invoice side it has no submission type, and its buyer fails the mandatory check. Because it is RM 10,000 or more it goes to the Individual Pool, not the Batch Pool. It will not be folded into the month’s consolidated e-invoice.
- On Thursday the buyer returns. The laptops were for his employer, a logistics company, and he brings its tax number and registration. In My E-Invoice Admin you complete the buyer block on the pool row and press Save and Resubmit. The e-invoice goes to LHDN with the logistics company as buyer. The cash bill still belongs to the cash customer, and its journal and stock do not move. That is the E06 question answered: the buyer and the billed account are allowed to differ.
- On Friday a colleague suggests voiding the bill and keying it again on an account for the logistics company, “so the books match the e-invoice”. Don’t. The books did not need to match, and a voided cash bill reverses its stock and journal while Thursday’s e-invoice stays Valid at LHDN. LHDN would then hold a sale your books no longer have.
Had the cashier marked the bill Consolidated, the outcome on Monday would have been the same: the RM 10,000 rule overrides that choice for cash bills and sales invoices.
Choosing between neighbours
- Correct the customer, or correct the e-invoice buyer? Correct the customer record when the customer really has changed. Every later document then picks it up. Correct the buyer on the pool row when only this sale’s buyer differs. A record that has already been built keeps what it was built with, so fixing the customer afterwards does not change it. Save and Resubmit on a pool row writes your corrections to the document. Changing the customer record itself is a separate edit, in Customer Maintenance.
- Skip on the document, the branch or the customer? The document, for one sale that should never be reported (a test, a duplicate keyed by mistake). The branch, for a location whose sales somebody else reports. The customer, only for a party that never needs an e-invoice from any company in the group.
- Self-billed purchase, or the supplier’s own e-invoice? Self-bill only where the law puts the duty on you, for example an unregistered supplier or an imported service. A self-billed document in the Batch Pool is skipped by the scheduled monthly run, which takes sales documents only. Pressing Consolidate on it, or a by-branch run, which first gives any non-general supplier TIN the general one, folds it into a consolidated self-billed e-invoice under a general supplier, which is rarely what you mean. Move it to the Individual Pool.
- Two companies trading inside the group. When
GSDinvoicesGS,GSD’s sales invoice is the e-invoice, issued toGSas an identified buyer. The purchase invoice that appears inGS(scenario: one company buys for another) is an ordinary purchase and is not reported, unless it is marked Self-Billed. Check that it is not. If the supplier record that stands forGSDcarries E-Invoice Self-Bill, purchase screens set the flag from it, and the group then reports one sale twice. - A supplier’s e-invoice: which applet? Peppol arrivals: My Peppol Admin. An e-mailed or uploaded PDF: AP Automation, which matches it to what you received and posts nothing. A document that exists only on MyInvois: compare it by hand (Incoming supplier e-invoices).
Where the e-invoice figures on other screens come from
| What you see | Where | Stored or live | From what |
|---|---|---|---|
| The buyer on the e-invoice | My E-Invoice Admin, the PDF, MyInvois | Copied when the routing run builds the record | The document’s e-invoice buyer block if it has one, otherwise the customer record as it was at that moment |
| The supplier block | The same | Copied at build | The company record in Organisation. The built-in PDF prints that copy, not today’s company record |
| The e-invoice status on the sales document’s E-Invoice tab | The document applet | A copy written by the e-invoice side | LHDN’s answer when BigLedger last asked (module page) |
| Line classification and unit | The record’s lines | Copied at build | The line, else the item in Doc Item Maintenance, else 022 and piece |
| Tax type | The record’s lines | Worked out at build | The line’s tax amount, so it can differ from the tax code’s own setting |
| “Exists in ERP, missing in e-invoice” | Discrepancies Report | Built once, when you create it | FINAL documents in the company’s own currency. Foreign-currency sales are left out, so check them from the document listing |
When a sale goes missing between applets
| What you see | The usual cause | Check first | Fix |
|---|---|---|---|
| “I finalised the invoice and nothing was submitted to LHDN.” | Waiting for the next run, parked in a pool, a failed send, or the document never entered at all | The module page’s table for the first three. For the last: the company’s status, then the Skip flag on the customer and the branch | A company that was not ENABLED: switch it on, then ask BigLedger support to push the documents you already know about into the Posting Queue. Send the document numbers, the company and when they were finalised. A skip you did not intend: clear it on the customer or branch for future sales |
| One customer is never e-invoiced by any company in the group | Skip e-Invoice on the customer record, which every company reads | Customer Maintenance → the customer’s E-Invoice details | Clear the flag. Documents already finalised keep the skip they were given |
| A self-billed bill is not at LHDN | The flag was off at FINAL, or the bill is on Purchase Invoice No Stock In, or it is sitting in the Batch Pool | The document’s E-Invoice tab, then the Batch Pool | Raise self-billed bills on Purchase Invoice with Self-Billed on. Move a Batch Pool row to the Individual Pool |
| VOID is missing on a sales invoice or refund note | The company is ENABLED | Organisation → company → E-Invoice Status | Use the document’s Cancellation tab within 72 hours, or a credit note |
| A voided cash bill still shows Valid at LHDN | The void reversed the books only | The bill’s E-Invoice tab | Cancel within 72 hours of validation in My E-Invoice Admin, or issue a credit note |
| Every record reads Valid and the buyers say MyInvois shows nothing | The company’s LHDN Environment is blank or SANDBOX | Organisation → company → LHDN Environment | Set it to PRODUCTION. Anything already Valid in the sandbox was never filed: ask BigLedger how to send those documents to production |
| A customer’s delivery address has gone | They submitted their details in the Portal, which replaced their address book | The customer’s addresses | Re-enter it from the last document that used it |
| LHDN accepted the wrong classification on an item | A wrong non-blank code on the item is sent unchanged | Doc Item Maintenance → the item | Fix the item for future documents. Records already built keep the old code |
The first row is the expensive one. A document finalised while its company was not ENABLED is not picked up later, the document applet offers nothing to send it, and you find out from a reconciliation weeks on. Switch the company on before anyone finalises anything.
What the neighbours will not do for e-invoicing
Each is a job a person keeps.
- A document applet does not tell you the document was not reported. The till and the invoice screen show FINAL either way. Whoever runs sales documents checks To IRB E-Invoice and the pools each morning (module check, step 3).
- Correcting a customer does not correct an e-invoice already built from it. The person who fixes a record also resubmits, cancels or credits the documents that went out with the old details.
- A void in POS does not cancel at LHDN. The cashier’s supervisor tells the e-invoice owner the same day, because the 72 hours run from LHDN’s validation, not from the void.
- Organisation does not stop you enabling a company with no intermediary set up for its environment. Whoever enables a company sends one test document and reads its status before the till opens.
- The month’s scheduled consolidation leaves purchase documents alone. The person who self-bills clears the Batch Pool of purchase rows before the 7th, and keeps them out of any Consolidate selection.
How you know the neighbours are set up right
About ten minutes, once per company, and again after anyone changes a company, a branch or a big customer.
- The company is live. In Organisation, each company that issues documents reads ENABLED with LHDN Environment PRODUCTION. You are done when both are true for every company.
- Every document type you use arrives. Take one document of each type you finalised yesterday (an invoice, a cash bill, a note, a self-billed bill) and find each in My E-Invoice Admin → To IRB E-Invoice or a pool. You are done when every one is found.
- No purchase rows wait in the Batch Pool. Filter the Batch Pool by document type. You are done when it holds sales documents only.
- Last week’s voided cash bills are cancelled at LHDN. For each cash bill voided after its e-invoice went out, the record on To IRB E-Invoice reads Cancelled, or a credit note exists. You are done when none reads Valid.
The daily check on the pipeline itself is the module’s five steps.
Notes on the module’s own applets
- My Peppol Admin is not where you register. Its Registration screen saves nothing. Your Peppol IDs, and the registration with the KYC PDF, are on the company’s Peppol Config tab in Organisation.
- Looking for the Applet Store entry MY E-Invoice For Customer And Supplier? It is a separate applet, not the Portal under an older name. Its menu is the seller’s operator console, with the same groups as My E-Invoice Admin. Its old wiki address leads to the Portal page for now.
What it touches elsewhere
What must exist before anything is sent. Three things, and each one fails without a message when it is missing. The company must be ENABLED, or its documents are never queued at all. BigLedger must be authorised as your intermediary on the MyInvois portal, or every call to LHDN fails for that company: submission, the status check, consolidated submission and the TIN search. And the background clocks must be on the Scheduler (step 2 of the daily check). When the authorisation has lapsed, consolidation and the Discrepancies Report keep running, because they work inside BigLedger, so the screens look normal while nothing reaches LHDN.
The master data each document draws on comes from these modules:
| Module | What it supplies |
|---|---|
| Core | Organization — the company tax registration and MSIC industry code; Customer Maintenance and Supplier — tax number, identity type and value, and an address with line 1, city and state; Doc Item Maintenance — item classification codes and units; Tax Configuration |
| Sales and Point of Sale | Every document that is reported: cash bills, invoices, returns, credit, debit and refund notes |
| Purchasing | The purchase documents behind self-billed e-invoices and the incoming reconciliation |
What a Valid record makes possible. Once the status check reads Valid, LHDN’s validation link and QR code are stored on the record and appear on the LHDN-format printable. When the status check is what turned it Valid, the buyer’s e-mail goes out too. The 72-hour cancellation window opens, and after it closes the correction is a credit or debit note that names this e-invoice (Cancel and correct).
Which of two to use.
- Individual or consolidated. A walk-in sale under RM 10,000 can wait for the month’s consolidated e-invoice. At RM 10,000 or more, a sales invoice or cash bill on consolidated submission is sent to the Individual Pool instead, because it can no longer be consolidated. A buyer who wants their own e-invoice has to ask at the till, before the month’s run.
- Validation Queue → Submit, or Refresh on the record. Submit asks LHDN again about the rows you select (up to twenty) from those still on the status-check list. Refresh asks about one record, including one the list has already dropped.
- LHDN or PEPPOL. They are two separate paths from the same finalised document, not two steps of one path (see PEPPOL is a parallel pipeline).
What breaks if a setting is wrong. A company that is not ENABLED queues none of the documents it finalises: sales invoices, cash bills, notes, returns and self-billed purchases alike. You find out from a Discrepancies Report you create for that company; the automatic monthly one covers only companies that are ENABLED. A lapsed intermediary authorisation stops one company’s LHDN traffic. A single ACTIVE row on the Scheduler with a cron expression the clock cannot read stops every clock on the tenant, e-invoice included. The symptom is a frozen Last Run Date on every row (Scheduler).
What it pairs with in practice. The Scheduler, where the clocks live. Sales and POS, whose documents it reports. And The Month-End E-Invoice Cycle, the routine that the daily check feeds.