My E-Invoice Admin Applet

This is where you watch your LHDN MyInvois e-invoices after they leave the sales and purchase applets: fix what stalls, consolidate, cancel what was validated in error, and reconcile e-invoices from your suppliers. Know this first: finalising a document never submits its e-invoice — it only queues it, and everything after that happens here.

Overview

The My E-Invoice Admin Applet is the back-office console for Malaysia’s LHDN MyInvois e-invoicing. Sales and purchase documents are created and finalised in their own applets; the moment one is set to FINAL, BigLedger routes it into the e-invoice pipeline, and this applet is where you watch that pipeline, fix what stalls, consolidate what should be consolidated, cancel what LHDN has validated in error, and reconcile incoming e-invoices from your suppliers. It is opened by the accounts team and by whoever owns month-end e-invoice compliance. Nothing here creates an accounting document or posts a journal.

Where it fits

Screens and menus

The left menu, in the order the applet shows it. The default landing screen is Posting Queue.

Configuration

Before you can use it

Almost everything that decides whether a document reaches LHDN is configured outside this applet.

Company e-invoice settings (on the company’s E-Invoice tab; read on every submission):

Client Doc 1 filled in for you: the company’s reference format and its document-type codes

A company can have BigLedger compose a reference for each of its documents and write it into Client Doc 1. That is the field the generic document page describes as the other system’s number. No screen shows or sets this. The company’s format and its list of document-type codes are both set up by BigLedger through the API. It matters here because the running-number pattern above can include Client Doc 1. When it does, this reference becomes part of the number LHDN receives.

What happens behind the scene. Suppose a document reaches the entry gate (step 1) with Client Doc 1 empty, and its company has a format. BigLedger builds the reference from up to four pieces. They always come in this order and are always joined with hyphens:

1. the branch’s Description, as typed on the branch in the Organisation applet, not its code;
2. the company’s own code for this kind of document, from a list kept per company, for example a cash bill is CS, a sales invoice is INV;
3. the year and month of the transaction date, as four digits (2609 for September 2026);
4. the document’s Doc No (Branch).

The format decides which pieces are used. It cannot change their order or the hyphen. Take a GadgetSphere cash bill at a branch whose Description is KV01, dated 14 September 2026, with branch number 000812. It becomes KV01-CS-2609-000812. The reference is saved onto the document itself, so it shows in any listing with the Client Doc 1 column switched on, and it stays there.

What to watch for:

• A missing code leaves a gap, not an error. Suppose the company’s list has no code for the document type, because sales credit notes were never added. That piece is left out, and the reference reads KV01-2609-000812. Nothing warns you.
• A branch whose Description was never filled in stops the whole reference, when the format uses the branch. Nothing is written to Client Doc 1, and nothing says why. A code in the list that holds no value can do the same.
• The Description goes in exactly as typed. A branch described as Klang Valley 01 gives Klang Valley 01-CS-…, spaces included. A Description with a hyphen in it makes the reference impossible to split back into its pieces.
• Only an empty Client Doc 1 is filled. A document that arrives with Client Doc 1 already set keeps what it had, and the format never overwrites it. An import, a marketplace connector or an integration may have set it. So one company can send LHDN two shapes of number: marketplace orders carry the marketplace’s number, and counter sales carry the composed reference.
• The reference is written whether or not the document is then e-invoiced. It is composed before the gate checks E-Invoice Status, the document type and Skip E-Invoice. A document the gate then drops still gets it.
• Two codes for one document type give an unpredictable result. If the list holds two codes for the same type in one company, the one the database returns first is used. Nothing stops the second being added.
• Changing a code or the format does not touch past documents. The reference is written once, so a change applies only to documents that reach the gate afterwards.

What it will not do. The list has a place for the company’s own submission-type code as well, and nothing reads it. It does not change how a document is submitted: the submission type on the document does (see Which level each e-invoice fact lives on). And if all you want is a document-type code in the number LHDN receives, the running-number pattern has BigLedger’s own short code built in, with no list to keep.

Your job. The person who owns the company’s e-invoice set-up decides whether the company wants this reference at all, and keeps the code list complete. When the company starts issuing a new kind of document, such as credit notes or refund notes, ask BigLedger to add its code before the first one is finalised. Check the result after each month’s documents are in. Filter a listing to the month and look down the Client Doc 1 column. A reference with fewer than four pieces means a missing code. An empty one means a branch with no Description, or a document that already carried a Client Doc 1 of its own.

Which level each e-invoice fact lives on — tenant, company, branch

A group runs three companies and twenty-odd branches inside one tenant, and the question that reaches support is “do I set this up three times, and do the branches need anything?” The answer is a level per fact.

Three consequences for a group:

• Registration is per company, the environment is per company, and nothing ties them together. Two companies in the same tenant can sit in different LHDN environments at the same moment — one filing for real, one filing with nobody — and no screen puts the two side by side. The MyInvois setup guide is run once per company, and the thirty-second check at the end of it is run once per company too.
• A customer’s e-invoice flags are the group’s, not one company’s. Skip e-Invoice on a customer record switches that customer off in every company that trades with them. A running-number override on a customer applies whichever company issues the document, and it wins over the company’s own pattern. The supplier’s self-billed flag is what every company’s purchase screens pick up. Set them with the whole group in mind.
• A branch needs nothing configured for e-invoice. The one branch control is Skip E-Invoice, for a location whose sales are reported by somebody else. Everything a branch wants to see on an e-invoice — its logo, its address — comes through a company printable format, not through the branch record.

Where the submission type comes from, since it decides the pool. It is a value on the document, not a default on a document type or a company. The sales invoice applet seeds a new invoice with Individual; the point of sale seeds a new cash bill with nothing, and only a cashier’s choice on the E-Invoice panel sets it. No screen, setting or rule supplies a per-document-type default. A blank receipt is routed through the posting queue and the mandatory-field check before it reaches the Batch Pool — which is why most Batch Pool rows are born UNPROCESSED / FAILED with a reason on them, and why a walk-in who did give their details gets an individual e-invoice without anyone choosing it. An explicit Consolidated skips the check and goes straight to the pool.

Applet settings

Settings live under Settings → Field Settings in this applet, not in the shared settings screen. Every key is tenant-wide and can be changed by anyone who can open Settings (there is no role check). Every toggle starts blank, which the applet treats as off.

Four more toggles on the To IRB E-Invoice panel only show or hide a print button there — SHOW_CUSTOM_PRINTABLE_BUTTON, SHOW_PRINTABLE_PREVIEW, SHOW_PRINTABLE_LHDN_PREVIEW and HIDE_LHDN_FORMAT_PRINTABLE_BUTTON. They decide which print buttons appear, not what the buttons print.

Rendered and saved but not used anywhere in the applet: Hide submission status (Master List Settings panel). Switching it has no effect.

Unbound toggles on the same screen (Unit Discount, SST/VAT/GST, WHT, Blanket Order, Segment, G/L Dimension, Profit Center, Project) are never saved — they are leftovers from the document-applet settings screen.

Three keys from the shared Default Selection / personal settings are read here without a control of their own, and only affect the Discrepancies Report’s document listing: DEFAULT_TRANSACTION_DATE (1_week or 1_day pre-filters the date range), FUZZY_SEARCH_COLUMNS, SORT_ORDER (defaults to last-updated).

Default Selection (under Settings) renders Default Branch and Default Location, but its SAVE button saves nothing. Treat it as not functional.

Webhook, Feature Visibility and the four permission listings are the shared screens every applet has.

Document behaviour settings

Not applicable — this applet has no document status flow or posting of its own. The behaviour of the pipeline is fixed, and driven by the company settings above and by the per-document Submission Type and Skip E-Invoice set in the originating applets.

Feature visibility / permissions

The applet seeds no client-side permission definitions and checks none on its screens. Every call the screens make is guarded server-side by permission families for the e-invoice objects — intermediary configuration, e-mail printable queue, incoming documents, reconciliation histories and so on — which you assign through Settings → Permission Set / Role Permission.

Fields

This applet edits e-invoice records, not accounting documents. The tables below cover the three forms a user actually types into.

To IRB E-Invoice / pool edit — Account tab (buyer for sales, supplier for purchase)

Rejection Request (Cancellation → Rejection Requests → row → Update)

Bulk TIN Validation (Tools → Bulk Tin Validation → Create)

Bulk TIN Validation: what the upload actually starts

It is a verification-and-request campaign, not a correction upload, and the correction — when it comes — is made by the customer, not by you.

1. Each row is matched to customer, supplier and employee records on name, customer code, phone and e-mail. The four are matched with any, not all, and no kind of record is excluded. So one row acts on every record that shares any one of the four values — a shared shop telephone number, a repeated walk-in name, a supplier who is also a customer — and it will act on a supplier or an employee record as readily as on a customer. A row matches at most 100 records; a 101st is silently ignored.
2. For a matched record that already holds an identity type, an identity value and a TIN, BigLedger asks LHDN whether the three agree. If they do, nothing happens at all — no row, no e-mail, no record on the screen that it passed. If they do not, or if any of the three is blank, a request is queued for that record.
3. A scheduled run then works through the queue (20 at a time), re-checks, drops the request if the TIN has since become valid, and otherwise e-mails the customer’s own address on the master record a “Please Update Your Tin Information” message with a link to a self-service form. A customer with no e-mail on the record is never contacted. Reminders go out at most every 2 days, and the request is dropped after 10 reminders or 30 days whether or not anyone answered.
4. When the customer fills in that form, BigLedger checks the TIN, identity type and identity value with LHDN and refuses an invalid set — but only when all three are filled in. Submit the form with any one of the three empty and the LHDN check is skipped entirely and the write goes ahead, so a customer can blank their own identity fields on your master record. On success it writes five fields: the e-invoice ID value, ID type and TIN on the record’s E-Invoice tab, and the ID number and ID type on its Main tab.

There is no back-office approve step, and no screen reports what the run found. Identity type and identity number are corrected by this route too, so they are not a separate File Import job.

The screen has two result boxes and neither is ever filled. The File Import listing shows Process Status and Error Message columns, and File Details repeats both as read-only fields; the TIN upload never writes either, so both stay blank whatever happened. The Line tab is the same story. The only evidence any of it ran is the Queue tab under a line — one row per record that failed or was incomplete, with Email Reminder Sent counting up. A line with no queue row means the record passed or the row matched nobody, and nothing on the screen separates those two.

“Invalid” also means “LHDN could not be reached”. Any answer from LHDN other than success is recorded as invalid. A run made while the intermediary access token has lapsed therefore marks every record invalid and queues the lot for a chasing e-mail. Check the token before uploading, not after.

The half that chases your customers has to be scheduled, and nothing schedules it for you. The upload half always runs — the file is read and the requests are queued the moment you submit. The e-mail half is a scheduled run, and it runs only if your tenant has it on its schedule. Without that, an upload creates requests that nothing sweeps, and not one e-mail is sent. Confirm before you plan a campaign around this — do not assume. The Scheduler applet is where you can look and, if E_INVOICE_TIN_UPDATE_REQUEST_EMAIL_PROCESSOR is in its Select Processor picker, where you can add it yourself.

Lifecycle and effects

1. Entry gate (at FINAL)

The moment a document becomes FINAL, BigLedger decides whether it belongs in the e-invoice pipeline. It proceeds only if all of these hold: the company’s E-Invoice Status is ENABLED; the document type is an e-invoice type — Sales Invoice, Cash Bill, Sales Credit Note, Sales Debit Note, Sales Refund Note, Sales Return, or a purchase document with Self-Billed switched on; Skip E-Invoice is off; and the same document number is not already waiting in the Posting Queue. If any check fails, nothing is written — no queue row, no pool row, no error (the “ghost document” failure in Troubleshooting).

When the gate looks, and how often. Not when you press Finalise. Finalising starts a chain of background jobs, and one of them runs this gate a moment later — once. It reads the company’s E-Invoice Status, the document type and the skip flag as they are at that moment and does not come back: switch a company to ENABLED on the 10th and the documents of the 1st to the 9th stay outside the pipeline, where the Discrepancies Report lists them as missing (§8). A push by support re-runs the same test on documents you name. One purchase type is not on the gate’s list. A Purchase Invoice No Stock In, the bill you key after a GRN has already taken the stock in, is a document type of its own, and the list of e-invoice purchase types leaves it out. So it never enters this pipeline as a self-billed e-invoice, and it never reaches the supplier-matching list in §7 either. Whether that is deliberate is a question we have put to BigLedger. Until it is answered, if GadgetSphere Distribution self-bills a supplier whose stock arrives on a GRN first, confirm with your BigLedger contact how that invoice is meant to reach LHDN before you rely on it.

Routing by Submission Type:

The RM 10,000 threshold is fixed (inclusive) and the enforced types are only Sales Invoice and Cash Bill.

For foreign-currency documents the document used from here on is the foreign-currency one or the base MYR one according to the company’s forex posting logic (see Configuration).

2. Posting queue → e-invoice record or a pool

A scheduled run takes each Posting Queue row and builds the e-invoice record (header and lines) from the document, the company and the customer or supplier. The buyer of a sales document is taken from the e-invoice buyer details saved on the document if there are any, otherwise from the customer record; the supplier of a self-billed purchase document likewise from the document’s e-invoice supplier details, otherwise from the supplier record. When the amount is RM 10,000 or more, the ID type is BRN and the TIN is blank, BigLedger searches LHDN for the TIN and writes it back to the customer, the document and the e-invoice record.

The record is a copy, and from here on it has a life of its own. What To IRB E-Invoice shows on its Account tab — buyer, supplier, addresses, identity — is what this run copied when it built the record, plus whatever someone has typed there since, not the customer as it reads today. That is deliberate: the buyer on an e-invoice does not have to be the account you billed, so the record keeps its own. It has a practical consequence the screens do not mention. When LHDN rejects a buyer, correcting the customer record fixes the next sale; it does not touch this e-invoice, because Save and Resubmit sends the record’s own buyer block. Fix both: the Account tab for this one, the customer for the ones to come.

It then runs the mandatory-field check:

• Header: supplier and buyer name, TIN, ID type, ID value; supplier MSIC code and business-activity description; both addresses with line 1, city and state; both contact numbers 8–20 characters; e-invoice version, type and code; e-invoice date-time; document currency; sub-total, total excluding and including tax.
• Every line: classification, item name, unit price, tax type code, tax amount.

Outcome:

A Single General sales document is no longer held for its buyer. Since 8 October 2026 the check skips the buyer fields — name, TIN, identity, address and contact number — on a sales document whose submission type is Single General. The supplier, document and line checks still apply, so a sales row that lands in the Single General Pool now names a supplier, document or line field, never a buyer one. Purchase documents and the other submission types are checked as before.

A document with more lines than the pagination threshold is split before it is queued. Since 28 September 2026 the same run splits a record whose line count exceeds the threshold — 200 lines unless the application setting EINVOICE_PAGINATION_LINE_THRESHOLD says otherwise — into numbered parts (_P1, _P2, …) that share one grouped guid, each with its own header totals; every part is submitted and validated on its own, the document carries the first part’s record, and a later resubmission re-sends only the parts that failed. A credit or debit note raised against a split invoice resolves its reference per part.

These are the 23 scenarios of the routing model; the guide E-Invoice Pools & Submission Routing walks through them.

3. Pools — what the buttons do

A Batch Pool row carries three status columns, and only one of them decides whether it is consolidated. Process Status is UNPROCESSED or PROCESSED; Queue Status is QUEUED, SUCCESS or FAILED; Status is ACTIVE or DELETED. A row is created at UNPROCESSED always, and at FAILED with the missing-field list in Validation Error whenever it reached the pool because the individual mandatory-field check failed — which is the ordinary route for a consolidated-submission receipt. The automatic consolidation run does not read Queue Status at all, so an UNPROCESSED / FAILED row is swept exactly like an UNPROCESSED / QUEUED one. UNPROCESSED / FAILED is therefore the ordinary resting state of a consolidated-submission receipt — a description of the receipt, not a fault on it.

What the automatic run selects, and the window that was added on 2026-09-18. The scheduled by-document consolidation run takes rows whose Process Status is UNPROCESSED, of a sales document type, 100 at a time — and only from the previous calendar month by transaction date. So a row dated in the current month waits for next month’s runs, which is right, and a row older than last month is never selected by the automatic run at all. A schedule row can name a different month, and a month that is not before the current one is refused with “Invalid month. For consolidated e-invoice use batch pool documents from previous month(s)” — unless support has set that on your tenant’s schedule, the window is last month and nothing else. Within the selection, documents are grouped by their own transaction month and each group’s consolidated e-invoice is dated the last day of that month. Before 2026-09-18 the run took every unprocessed row whatever its date and dated everything older than the current month to the last day of the previous month; pages and notes describing that behaviour are superseded.

Since 2 October 2026 the run also sweeps up the month’s individual e-invoices that LHDN did not take, and since 13 October that includes rejected ones. Before it consolidates, the automatic by-document run — and the by-branch run — takes every e-invoice record of the month it is working on that is under RM 10,000, of a sales document type and not consolidated, and is either Invalid or IN_QUEUE after LHDN refused the submission (it carries LHDN’s answer and no LHDN document ID). It writes a Batch Pool row for each one’s document as CONSOLIDATED / UNPROCESSED, marks the document consolidated and soft-deletes the record together with its lines, its submission-queue row and its link. A record that is IN_QUEUE because it has not been sent yet, or because the send failed before LHDN answered (a lapsed token, a time-out), is left for the individual submission run. Before 13 October the rule ran the other way for those two: a record with no LHDN document ID was swept whatever had happened to it, and an Invalid record was never swept. Pages and notes describing that are superseded. The manual Consolidate and Consolidate By Branch buttons do not run the sweep at all; they consolidate only the rows you select. The row therefore disappears from To IRB E-Invoice and the receipt is reported inside the consolidated e-invoice instead. Only a month that has fully ended is swept — the current month is refused — and a document that is still sitting in a pool, which never got a record, is not touched. A record that reached LHDN between the selection and the clean-up is left alone and its new pool row is rolled back. The same sweep also exists on its own, as a scheduler job BigLedger can set up for a tenant (registered, in no default clock, taking an optional month) and as a back-office API call; the codes are in this page’s sources.

The sweep does not ask anyone’s preference. It stamps Consolidated onto the document whatever submission type it carried, an Individual chosen for a business buyer included, and it does not read the company’s Disable Consolidated Submission switch (no server code reads that switch at all; its one effect is to trim the drop-down on the document’s E-Invoice tab). For a walk-in who gave no details that is the right call: reported inside a consolidated e-invoice beats not reported. For a business customer who asked for an e-invoice of their own it is the wrong one, because after the sweep their purchase sits inside a General Public e-invoice that does not name them. That makes the rejected list a job with a deadline. Whoever owns e-invoicing for the company works To IRB E-Invoice filtered to Invalid before the consolidation run fires for that period, fixes and resubmits every row whose buyer needs their own e-invoice, and lets the rest go into the consolidated one on purpose. Which day the run fires on your tenant is on the Scheduler applet.

The manual Consolidate button has no date window, which is what makes it, and not the automatic run, the way to clear an old month: it re-reads the selected rows, keeps the UNPROCESSED ones and consolidates whatever is left, refusing with “Cannot consolidate PROCESSED batch pools” only when none of the selection is unprocessed. A mixed selection is therefore safe — already-processed rows are dropped, not consolidated twice.

Process and Save and Resubmit set PROCESSED whether they succeed or fail, and that is what strands a row. Both write the Queue Status (SUCCESS or FAILED) and then set Process Status to PROCESSED unconditionally, and Process applies no status filter to the selection. A red row that the run was going to consolidate anyway is taken out of the run by pressing Process on it and having the individual check fail again — and the grid does not stop you selecting an already-processed row. Tell the two red states apart before you act on either: a PROCESSED / FAILED row is stranded and needs the round trip below, while an UNPROCESSED / FAILED row is only waiting for the next run and needs nothing done to it.

Nothing you can reach resets a row. No screen action, no consolidation path and no submission path sets an existing Batch Pool row back to UNPROCESSED. The one exception is a buyer’s e-invoice request — from a storefront widget (cp-commerce storefront e-invoice), the customer portal or its Customer Invitations screen, which all run the same processor; that briefly resets the row, re-homes the receipt to Individual and re-processes it, so it comes to rest at PROCESSED again — with an individual e-invoice behind it if the build succeeds, and with none if it fails, the receipt then being in neither the consolidated nor an individual e-invoice. It takes the receipt out of the monthly batch rather than back into it; a failed request is logged FAILED on Internal Submission → Portal Request. The way back from PROCESSED / FAILED is therefore the round trip: Move to Individual retires the Batch Pool row and creates an Individual Pool row, and Move To Batch Pool on the Individual Pool then builds a new Batch Pool row at UNPROCESSED / FAILED and sets the document’s submission type back to Consolidated.

Documents in the Individual or Single General pool stay there until someone acts — there is no ageing alert (open issue). The platform does contain runs that could move them automatically — from the Individual Pool to consolidated or single-general submission, from an Invalid e-invoice to the same two, and one that re-homes failed Individual Pool rows by buyer type (a business buyer to the Batch Pool as Consolidated, an individual to the Single General Pool). None of them is on any schedule unless somebody put it there, and the last of them cannot be scheduled at all — it runs only when support triggers it, per branch. So the capability exists, but until you have seen the schedule rows on your tenant, assume a pool row moves only when a person moves it, and ask support to check for your own tenant.

Two automatic runs exist, they build different documents, and nothing on a company record decides which one you get.

Two consequences a multi-branch group should know. On the by-document run a branch is invisible on the finished e-invoice — every branch’s receipts of one company and document type are mixed into the same e-invoice, and the only way back to “which e-invoice reported this branch’s sale” is the per-document link the consolidation writes (visible from the Discrepancies Report drill-down). On the by-branch run a gap in a branch’s document numbers starts a new line: every receipt the branch pulled out of the batch — a sale of RM 10,000 or more, a customer who asked for their own e-invoice — splits one range into two.

Consolidating by branch runs either way — on a schedule of its own, or on demand from the Consolidate By Branch button on the pool. Which run your tenant has is a scheduler question for support, not a setting you can read off the company record — see the note on Batch Line Logic on the Organisation applet page.

4. Submission, validation and e-mail (scheduled runs)

Status vocabulary on the e-invoice record: NOT_SUBMITTED → IN_QUEUE (queued or failed before reaching LHDN) → Submitted (accepted by LHDN, awaiting validation) → Valid or Invalid → Cancelled; consolidated e-invoices start at IN_CONSOLIDATED_QUEUE.

4b. The PDF your customer receives, and the e-mail that carries it

The question worth answering about this family is not “how do I send it” but “my customer got an e-invoice PDF that does not look like my invoice — where did it come from and what can I change?”

Which template renders it

The e-invoice PDF and the ordinary invoice printable are two different documents from two different resolutions. Pressing Print on a sales invoice uses the print dialog’s format (pre-selected from the branch default) — see Printable Formats. The e-invoice PDF ignores all of that: it takes the company’s e-invoice format for that document type, highest priority first — except that a row with no priority outranks every numbered one, so give every row a priority (uploaded on the Organisation applet’s company record → E-Invoice tab → Printable sub-tab, one layout per document type), and when the company has none it uses a built-in layout shipped with the platform — one for sales documents, one for purchase-side ones. The e-mail attachment, the Printable button on the To IRB record, and the zip from Export → PDF all choose the layout the same way, so the PDF you download is the PDF the customer received.

What the built-in template shows, and what it cannot

The built-in layout is handed only the e-invoice’s own data. The company-and-branch set — logo, company name, branch address, branch logo, website — is supplied only when a company format is used. Three consequences you can see on the page: no logo, no branch address block, and a supplier block that is the e-invoice record’s own snapshot — what was submitted to LHDN, not the live company record. Correct the company’s address today and every already-validated PDF keeps the old one, because the PDF is rendered from the e-invoice record, not from the company.

What a company format can use

A company format receives both sets. The company logo is the company’s logo attachment, the branch logo is the branch’s, the branch address and phone come from the branch record, and the company’s registered address from the company record. On a consolidated e-invoice the company logo is deliberately blank and there is no branch. The e-invoice data carries the buyer block, the supplier block, the LHDN unique reference, the validation time, the QR, the totals, the tax type and rate, and the original-document reference on a credit or debit note. The sub-tab’s Document Type list offers ten document types; the self-billed purchase invoice is not one of them, so that document always renders on the built-in layout.

The QR

The QR is the LHDN validation link — LHDN’s own page for that document — built the moment the poller sees Valid and stored on the e-invoice record. On a record that is not yet Valid the image is empty. Scanning it opens LHDN’s page for that document, not anything of yours, and it is the same QR on the printed copy, the e-mailed copy and the exported zip.

When the e-mail goes, and to whom

Not at Finalise, not at submission: when the validation poller reads Valid from LHDN. What happens next depends on a fact about your tenant, not your company: whether the validated-PDF e-mail run has ever been on the tenant’s schedule (a schedule row that was later deleted still counts). If it has, the poller queues a row and drafts the e-mail for every e-invoice that is not consolidated, and the run sends later. If it never has, the poller sends inline, itself, before it answers — consolidated e-invoices included. The recipient is the buyer e-mail on the e-invoice record — the buyer block as it was submitted — for every sales-side document, and the supplier’s e-mail for a purchase-side one; a subscription option can replace it with the customer branch’s e-mail. A blank buyer e-mail sends nothing.

What has to exist before anything is sent

Three things, and only the first is on a screen. (1) The company’s Send Email To Buyer switch. (2) An e-mail subscription for the company, set up by BigLedger, which is where the e-mail’s subject, body, sender and attachment file-name pattern live (default file name E-INVOICE-<supplier name>-<document type>-<e-invoice date-time>-<document number>.pdf). (3) A sender address in that subscription. No screen creates any of these. They are set up by BigLedger for each company, and a company without them is not refused: the send returns quietly having done nothing — no queue update, no history row, no draft — so the row sits IN_QUEUE at retry 0 and the dashboard’s error column stays empty. The e-mail goes out through BigLedger’s mail service, from the subscription’s sender, unless the company has a mail server of its own set up for it (below).

Sending through your own mail server

BigLedger can send a company’s validated e-invoice PDFs through the company’s own mail server (SMTP) instead of its own mail service. There is no screen for it: BigLedger records the server, port, user name and password against the company, and from then on every one of that company’s e-invoice e-mails takes that route. Six things about how it behaves are worth knowing before you ask for it:

• It carries one kind of e-mail. The validated e-invoice PDF — to the buyer on a sales-side document, to the supplier on a purchase-side one — whether the scheduled run sends it, the poller sends it inline or somebody presses Resend Email. No other e-mail BigLedger sends to a customer or supplier reads this set-up.
• The From address is still the subscription’s sender. The set-up has a sender field of its own, and the e-invoice e-mail never uses it. Your mail server has to accept the subscription’s sender as an address that user may send from; if it refuses, the attempt is recorded as failed with the server’s reason (on the dashboard, while the e-invoice still has a queue row).
• The connection always logs in and then switches to encryption (STARTTLS) on the recorded port. The set-up’s TLS and SSL fields are not read, so a server that only accepts a connection encrypted from the first byte (often called SSL) cannot be used.
• Only the first address is used. If the buyer e-mail on the record holds several addresses separated by commas or semicolons, your server sends to the first and nobody else.
• The password is a copy. BigLedger keeps the mailbox password with the set-up. Change it at your mail provider and every send fails with AuthenticationFailedException until BigLedger has the new one.
• Switching it off means deleting it. A set-up marked inactive is still used — only a deleted one is not. If a company has more than one, the one used is picked by its internal identifier, not by which is newest.

How you know which route a message took. On the Email Dashboard, Email Status reads SMTP-SUCCESS or SMTP-FAILED for a message that went through your server, and SES-SUCCESS or SES-FAILED for one that went through BigLedger’s service. On a failure through your server, Email Error Code names the kind of failure — AuthenticationFailedException when the log-in was refused, SendFailedException when an address was. Resend Email is no help here: BigLedger answers Sent Success for each address even when your server refused it.

Who keeps it working. The mailbox belongs to your company, so its changes are yours to pass on: whoever looks after the company mailbox tells BigLedger about every password change and every change of server. Where your e-mails go through the queue, the check that it still works is the Email Printable Queue History — the day after any change, yesterday’s messages should read SMTP-SUCCESS. (On a tenant that sends inline there is no queue row and so no history; the To IRB record’s Email tab shows only the sends that succeeded.) A row reading SMTP-FAILED with AuthenticationFailedException is the password; SES-SUCCESS where you expected your own server means the set-up is not there.

How the queue moves, and how it stops

The run takes rows that are IN_QUEUE with retry 5 or less, oldest first, ten at a time. A successful send writes a history row and removes the queue row; a failed send writes both and adds one to the retry, so after six failures the row drops out of the selection with its error on it. The two skip paths — the switch off, and the missing subscription or sender — write nothing, so a skipped row keeps retry 0 and is selected again on every run. Once ten skipped rows are older than everything else they are the ten, and no row behind them is reached, for any company on the tenant — including companies whose switch is on. This is a genuine head-of-line block and it is visible from the Email Printable Queue: if the ten oldest rows are more than a day old and still IN_QUEUE at retry 0, nothing behind them is going anywhere.

The three screens

Email Dashboard has two tabs: Email Printable Queue — the live queue with Process Status, Email Status, Retry, Email Error Code and Message, Receiver Email, Buyer Name and the document reference — and Email Printable Queue History, the sent and failed attempts. On the To IRB record itself, the Email tab lists the e-mail threads for that e-invoice: each holds the recipient, subject, body and the stored PDF attachment as it was sent, so you can download exactly what the customer received. A DRAFT row with no send time is one that was queued and has not been sent — or, with the customer-branch address option, one whose e-mail went out in a separate thread (below). The Resend Email tab (shown only on a Valid e-invoice) sends to the record’s buyer e-mail, or to Additional Recipient Email addresses you add; BigLedger answers per address with Sent Success or Sent Failed, and the screen discards that answer and toasts Email Sent on any reply. Read the thread, not the toast.

What the Email tab keeps, and what it does not

The wording is the same on every e-invoice from the company. The subject and body are fixed text from the company’s e-mail set-up, sent exactly as stored: nothing in them is filled in per document — no invoice number, no customer name, no amount. The only per-document part of the e-mail is the PDF’s file name, which is built from the e-invoice’s own details (supplier name, document type, date-time and document number by default). So when GadgetSphere’s customer asks “which invoice is this e-mail about?”, the answer is in the attachment’s name, not the message. If you want the document number in the subject line, that is not something the set-up can do today.

What each message on the Email tab means:

A failed attempt adds nothing to the Email tab. While the e-invoice still has a row in the Email Printable Queue, the failure is written to the dashboard’s queue and history. Once that row has gone — after the first successful send — or on a tenant that sends inline, a failed send is recorded nowhere you can see, which is one more reason to read the thread rather than the Email Sent toast.

A resend to the same address adds a message to the same thread, so its Email Count goes up; a resend to an Additional Recipient Email opens a new thread, because a thread belongs to one subject and one set of addresses. With the option that sends to the customer branch’s e-mail, the draft is written to the buyer’s address and, when the branch’s address is different, the e-mail that goes out is filed under the branch address — so that e-invoice shows a draft that will never be sent beside the thread that was.

Three boxes on the message are always empty or awkward. Text Body, Cc and Bcc are never filled — BigLedger sends an HTML body only and copies nobody. HTML Body shows the message’s markup as one line of text, not as the customer saw it; read the PDF preview and Sent To to confirm what went where.

What you cannot change from a screen

The e-mail’s subject, body, sender address and attachment file name; the mail server it goes through; the choice between the queue and the inline path; and the layout of the built-in template. Each of those is a request to your BigLedger contact. What you can change: the company format (Printable sub-tab), the company logo and address (company record — future e-invoices only), the buyer’s e-mail on a record before it is Valid, and the switch.

5. Fixing an Invalid e-invoice from To IRB E-Invoice

A record that has read Submitted for days has usually been dropped by the status check. The scheduled check asks LHDN about each submission until it gets a final answer, but it deletes its own queue row once LHDN has held the document as Submitted for three days, or after ten polls that got no answer — and nothing asks again. The record keeps reading Submitted, and Save and Resubmit refuses a Submitted record. Press Refresh on it: that one call reads LHDN’s current verdict, and if the verdict is Valid, follow it with Resend Email, because only the scheduled check sends or queues the validated-PDF e-mail; Refresh never does.

6. Cancellation (Rejection Requests → Cancellation Queue)

A rejection request never advances on its own. No scheduled run and no LHDN callback moves it: a request created and left alone stays at REQUESTED / IN-PROGRESS until the 72-hour window expires and the option is gone. Every step below is a human pressing a button:

1. Create the request (from To IRB E-Invoice, or a buyer creates it in the Portal applet).
2. Approve: open the request, set System Approval Status = APPROVED and choose a Processing Logic. Approving with VOID_ORIGINAL_DOC or REGEN_NEW_EINVOICE stamps the approval date-time on the e-invoice record; un-approving clears it.
3. Process Request: builds a Cancellation Queue row and calls LHDN there and then — the answer is back before the screen is. Only requests with System Processing Status IN-PROGRESS, System Approval Status APPROVED and a processing logic are picked up, which is also why a request that has already failed is never picked up twice (below).

Before the LHDN call BigLedger checks the e-invoice: its status must be Valid (“Not Validated” otherwise), it must carry an LHDN document UUID (“e-invoice is not generated yet”), and fewer than 72 hours must have passed since its validation date-time (“Passed 72 hours from validation date time”). The clock runs from the validation date-time stored on the record, not from what the user sees on the LHDN portal, and it is counted in whole hours: 71 h 59 min passes, 72 h 0 min fails. Anything but success from LHDN puts LHDN’s own response, verbatim, into Request Error.

Three of the four logics cancel at LHDN and then act; the fourth never calls LHDN:

What each outcome writes, and who is told. On success BigLedger re-polls LHDN for the document and writes Cancelled plus the cancellation date-time onto the e-invoice record and its Submission History rows; the Cancellation Queue row is removed; the request goes System Processing Status COMPLETED, LHDN cancellation status Cancelled. On any failure the queue row stays at SUBMISSION_FAILED carrying what was sent, what came back and the Request Error, and the request goes COMPLETED / FAILED — so a queue row you can still see is a failure, and Process Request will not take that request again. The retry is Process on the Cancellation Queue row, which re-runs the row and re-reads the request’s current processing logic — change the logic on the request first. Every outcome also sends an e-mail — addressed to the buyer’s e-mail on the e-invoice record, not to the operator, “Dear User”; with no buyer e-mail the send fails quietly, after the statuses have been written. For a consolidated e-invoice that is not an edge case but the rule: consolidation writes the literal NA as the buyer e-mail on every consolidated e-invoice, so the address never parses, every cancellation e-mail on that record fails, and the failure is swallowed. Nobody is told anything, by any route. Past 72 hours there is no cancellation: the remedy is a reversing document — the NEW_REVERSAL_DOC logic above, or a credit note e-invoice raised by hand referencing the LHDN UUID of the wrong e-invoice — with accountant sign-off. Support also has a direct cancellation path without the approval workflow; it runs the same checks before calling LHDN, so the 72-hour rule holds there too.

One consequence of the 72-hour rule is worth stating on its own: the window runs from LHDN validation, not from the moment the request is raised. A request that sits waiting for approval is spending the window, and a request raised near the end of it can expire before anyone approves it.

After a consolidated cancellation: where the receipts are, and what puts them back

A consolidated e-invoice has no single source document of its own; the hundreds of receipts inside it are attached to it only by a link per receipt. That single fact explains all four rows of the table above: three of the logics, and Save and Resubmit, all reach for a source document that is not there.

Cancelling the e-invoice changes the e-invoice. It does not touch any of the three things that record the receipts as reported:

So the receipts do not return to the Batch Pool by themselves, and no scheduled run will collect them. Two support actions put them back, and their names are close enough to be dangerous:

Neither action has a button in any applet, which is why re-reporting a cancelled consolidated month is a support action rather than something you do yourself. Ask for the documents to be named — a re-run of consolidation for the period is the wrong request, because it would sweep in everything else in the range as well.

The one screen route that would rebuild it, and why you will not see it. Resubmit as New E-invoice can, for a consolidated e-invoice, do the whole job: it mints a new e-invoice, re-links every member receipt to it, rebuilds the pool links and queues it for submission, then stamps the old one Resubmitted as CONSOLIDATED with einvoice no: …. It is refused only when the old record reads Valid — a Cancelled one is eligible. The Resubmit as New E-invoice button, however, appears only when the record’s status is exactly Invalid or Submitted and the setting SHOW_RESUBMIT_AS_NEW_E_INVOICE_BUTTON is on, so a Cancelled consolidated e-invoice can never reach it from this screen. The capability exists and has no button in front of it.

Work the member list, not the header. Cancelling a consolidated e-invoice leaves its receipts with no e-invoice record of any status: they were reported once, un-reported by the cancellation, and they stay that way until the recovery above puts them back onto a later consolidated e-invoice. Nothing on this screen tells you which receipts are in that state, so after any consolidated cancellation go through the member documents yourself and confirm each one has landed on a later consolidated e-invoice.

7. Incoming e-invoices and reconciliation

At FINAL, every non-self-billed purchase document whose supplier has a TIN is placed in the PD Matching Queue, and every sales document that already has Skip E-Invoice on when it is finalised is placed in the SD Matching Queue (see note 4 for when that job runs). The incoming side of the pairing is fed from PEPPOL and, on paper, from the OCR e-mail intake — each row’s Match Source column says which — and never from LHDN. In practice only PEPPOL reaches it; see note 3 below. External Reception → Queue stages the documents MyInvois lists as received by your company, and a second run, every five minutes, copies each into From IRB E-Invoice. Nothing moves either into the matching queue. Both screens are empty in practice. The staging run is a default clock firing every minute, and installed as it is, with no settings, it asks MyInvois’s sandbox for each company’s test documents, not production. So your real supplier e-invoices do not appear there until BigLedger sets that run to production. Auto Match pairs a row only when the supplier identity number, reference number, amount and document date all agree exactly; there is no tolerance and no partial match. A pair can also be made by hand from the PD Matching Queue’s Match Incoming Doc tab. Matched pairs go to Matched History. Pushback to Queues puts a pair back on the two queues, but not as it was: it rebuilds both rows from what Matched History holds, which is the supplier document’s reference, date and amount, so your purchase row comes back carrying the supplier’s values, and after a pair made by hand with Match it comes back tied to no purchase document at all and shows as a blank line. Check a pair before you press Match. Push to Unmatched History parks a row and Pushback to PD Matching Queue restores it. Nothing here changes the purchase or sales document — no posting, no status change, no tax. See Incoming Supplier E-Invoices for the operator’s version.

Where the purchase list and its figures come from. A row on PD Matching Q. is written by one of the background jobs Finalise starts, a moment after the document becomes FINAL, and the four conditions — company ENABLED, a purchase type, not self-billed, a supplier with a TIN — are tested once, then. Add a missing TIN to a supplier in June and the earlier purchases do not appear later. The reference, date and amount on the row are a copy taken at that moment, and Auto Match compares the copy, not the document as it reads now. A Purchase Invoice No Stock In never gets a row at all (see §1). Auto Match looks at ten incoming documents each time, the same first ten in the queue’s own internal order, so ten supplier documents that will never match keep every one behind them from being tried; park those with Push to Unmatched History and press Auto Match again. The guide walks through both: which purchases get a row and what Pushback gives back.

Four things about these ten screens that the screens themselves will not tell you:

1. Export does nothing on any reconciliation listing. The button is wired to nothing on all ten screens, while the Pushback and Auto Match buttons beside it work, and Export works elsewhere in the same applet (the Master List). To get a listing out, use the grid’s own tool panel. The superseded MY E-Invoice For Customer And Supplier applet, built from the same screens, has the same defect.
2. Auto Match on SD Matching Q. runs the purchase-side matcher. The sales-side button makes the very same call the purchase-side one makes. Only Inc. Ecom Matcd. Q. uses the e-commerce matcher. So a pass started from the sales side can pair and clear purchase-side queue rows. If you are reconciling suppliers, do not press Auto Match on the sales screens.
3. PEPPOL is the only live feed into the purchase-side incoming queue. The OCR e-mail intake is wired to feed it too, but every OCR document is skipped before it gets there, so it never does. Expect a Match Source of PEPPOL or an empty queue.
4. The sales side of the reconciliation is half a bridge, and the half that is missing is the incoming one. Its own register fills itself, where the job runs: a sales document on an e-invoice-enabled company that already has Skip E-Invoice on when it is finalised is queued by a job that runs off finalisation. That job is a subscriber your tenant has to have, and a company can be set to exclude it. A document skipped later, from a pool row, is never queued. Nothing removes a row except a successful e-commerce match, which deletes both rows, or a push to history — so the SD Matching Q. is a register of sales you deliberately did not report, and it keeps growing. Nothing in the product fetches the other side. Incoming e-commerce e-invoice rows are created only when an external system posts them in, or by a Pushback from one of the two history tabs. No scheduled run, no marketplace connector and no LHDN call creates one. The pairing, when a row does exist, matches on reference number, transaction date, amount and buyer identification number — each applied only when the incoming row carries that value. Two consequences follow. The sales-side row never carries a buyer identification number, so an incoming e-invoice that does carry one can never pair with anything. And an incoming row is not required to carry any of the four, so a row posted in with all four blank pairs with an arbitrary skipped sale. Note also that the sales-side match key is the document’s Reference field, not its document number. Put the three together: the sales side fills itself and keeps growing, the incoming side is filled by nobody in the product, and the run that would pair them does nothing until it is scheduled for your tenant. What you are looking at is a register of skipped sales that nothing ever clears. Reconcile marketplace sales against the platform’s own statement outside BigLedger, and do not expect these screens to do it.

8. Monthly Report → Discrepancies Report

The applet’s only self-service reconciliation tool, and the one screen that answers “does every document I finalised last month have an e-invoice record?” — which, as the fourth caution below explains, is a narrower question than “did it reach LHDN”. Create takes a company and a date range and stores a report whose lines are grouped totals — amount and document count per section — presented as four tabs:

Each discrepancy line drills into the documents behind it — the document listing, the e-invoice listing, and, for a consolidated e-invoice, the list of source documents inside it. The list is the one frozen on the line when the report was created; the documents’ own fields are loaded live when you open the drill-down.

Where each number comes from, and when. Nothing on the four tabs is recomputed after you press Create — and the two sides of the report are selected by different rules, which is why they can disagree for reasons that are not discrepancies.

• The report is a stored snapshot, built inside the Create call. Create writes the report as PROCESSING and builds it before the call returns, so the listing row you come back to is already PROCESSED (or FAILED) with its lines written. Nothing ever refreshes a report: to see the month after you have fixed something, create it again. A row that stays at PROCESSING is dead — nothing will ever finish it; delete it and create again. A FAILED row keeps its reason, when one is kept at all, internally, where no screen shows it.
• One company, always. The company is mandatory on every create path — a report with no company, or a company that does not exist, is refused before anything is built. A group runs one report per company per period, and there is no group-wide view that adds them up.
• Whole days, by your browser’s clock. The Create screen defaults to the current month, so a report for last month is a range you choose. It sends the start day at 00:00:00 and the end day at 23:59:59.999 in the time zone of the machine you are sitting at, and every query below compares against those two instants.
• The ERP side counts a document when it is FINAL, not deleted, its document date falls inside the range, it is not marked Skip E-Invoice, and its currency is the company’s currency. Amounts are the document’s transaction amount. A skipped document is counted once more, separately, on the Skip Einvoice Documents line with the same filters. A foreign-currency document is never counted on this side at all.
• The e-invoice side counts an e-invoice record when its company is the report’s company, its e-invoice date falls inside the range, and it is not deleted — no currency filter, and no status filter in the selection. The status sort happens afterwards, per record, by the document type on the record: Cancelled goes to the Cancelled figure; Invalid is dropped; everything else — Valid, Submitted, IN_QUEUE, IN_CONSOLIDATED_QUEUE, blank — goes to Internal Submission. So Internal Submission is “an e-invoice record exists and has not been cancelled or rejected”, not “LHDN has validated it”. The amount is the record’s transaction amount; the count is one per record, except that a consolidated e-invoice counts the number of member documents linked to it.
• Which month an e-invoice falls in. An individual e-invoice carries its document’s date, so it lands in the same month on both sides. A consolidated e-invoice from the common by-document run is dated the last day of the receipts’ month at 00:00 Malaysia time — so August’s receipts, consolidated on 5 September, sit in August on both sides too. The by-branch run dates its e-invoices by the clock instead — the previous month’s last day, or the current month’s, according to which set it is consolidating — and a single-general e-invoice built from a failed submission is dated the last day of the month it was built in. If a company’s IRB total is short by exactly one consolidated e-invoice, look for it in the next month’s report before you look anywhere else.
• The gap. Exists in ERP, Missing in Einvoice takes the ERP side’s documents (with the skip filter left off) and keeps those with neither an e-invoice record pointing at them nor a consolidation link naming them. The other direction keeps e-invoice records that carry no document and no live link. The consolidated-only count is the number of consolidated e-invoices dated in the range, whatever their status.

The whole-report XLS that support can produce is a different thing again: it recomputes the four tabs from the live data at download time, so it can disagree with the stored screen. No control in the applet produces it; the per-line XLS downloads on the drill-down use the stored lists.

The monthly e-mail does not come. The platform contains a routine that would walk every e-invoice-enabled company, generate last month’s report for each and e-mail it — but it cannot be put on a timetable, and the address it would write to is not configured for you either. There is no route by which the monthly e-mail arrives on its own. Treat the report as a screen you visit, not a letter you wait for.

What it cannot see — four things, and the third and fourth are the ones that pass silently.

First, it compares your documents against BigLedger’s e-invoice records. It does not pull back what LHDN holds, so an invoice keyed straight into the MyInvois portal, or sent by another system, never appears here. A LHDN dashboard count higher than this report’s is the signature of that case.

Second, a skipped document is still listed as missing — the Skip E-Invoice filter is on the ERP Transaction Summary and not on the discrepancy tab (see the Skip E-Invoice row above). Read the Skip Einvoice Documents line first and subtract it from the missing count — not from the ERP Transaction Summary, which has already left the skipped documents out.

Third, and the one to know before you cancel anything: the Exists in ERP, Missing in Einvoice list never looks at the e-invoice’s status. A document is kept on the list only when it has neither an e-invoice record of its own nor a consolidation link. A receipt that was reported inside a consolidated e-invoice keeps its link when that e-invoice is cancelled — nothing removes it — so the receipt is matched, and it is matched to something LHDN no longer holds. A month whose consolidated e-invoice has been cancelled therefore reads clean on this tab while every receipt inside it is unreported. The Cancelled column on the IRB Audit Summary is the only place on the screen that hints at it, and it shows an amount, not a list.

Fourth, a rejected e-invoice appears nowhere on the report. An Invalid record is dropped from the IRB Audit Summary — it is neither Internal Submission nor Cancelled — and because the record exists and points at its document, the document is not listed as missing either. A company’s month can hold a dozen rejected e-invoices and both discrepancy directions still read zero. How you know: per document type, take the ERP Transaction Summary count, less the IRB Audit Summary’s Internal Submission and Cancelled counts, less the Exists in ERP, Missing in Einvoice count after taking your skipped documents out of it. Subtract the skipped documents once, from the missing count only: the ERP Transaction Summary already leaves them out, and the missing list already includes them, so subtracting the Skip Einvoice Documents count from the ERP figure as well would count them twice. The Skip Einvoice Documents line is one total across all types; its drill-down lists the documents, so count them by type there. The result should be zero. Anything left over is a rejected e-invoice; a result below zero is usually a document voided after its e-invoice went out (the ERP side counts FINAL documents only, while its e-invoice record is still counted). The work list for the first is Internal Submission → To IRB E-Invoice filtered to Invalid (§5); the report will not give it to you.

9. What this applet writes

E-invoice records and their lines, the three pools, the submission / consolidated / validation / cancellation / e-mail queues, the consolidation links, rejection requests and TIN update requests. On the source document itself only the Skip E-Invoice flag, the e-invoice reference fields (e-invoice record, e-invoice number, e-invoice status) and — through VOID_ORIGINAL_DOC — the VOID status. It writes no journal itself, but two cancellation logics reach the ledger through the document: VOID_ORIGINAL_DOC voids the source document, which reverses its postings as any void does, and NEW_REVERSAL_DOC raises and finalises a reversing document, which posts as any finalised document does.

How you know the pipeline is moving

Nothing in this applet raises an alarm, so a person has to look. Give the job to one named owner per company, and keep the person who approves a cancellation request apart from the person who raises it. Once a week, open these screens in this order. Each takes about a minute and has one sign that means fine:

1. Posting Queue — no row more than a day old. An old row means the run that builds e-invoice records is not on your tenant’s schedule (§2).
2. Individual Pool and Single General Pool — no row older than a week. These move only when a person moves them (§3).
3. Batch Pool — no row reading PROCESSED / FAILED. Those are stranded; UNPROCESSED / FAILED rows are only waiting (§3).
4. To IRB E-Invoice, filtered to Invalid — empty, or every row has someone on it, with business buyers first.
5. To IRB E-Invoice, filtered to Submitted — nothing older than three days. Press Refresh on any you find (§5).
6. Rejection Requests — nothing at REQUESTED older than a day, because the 72-hour window is already running (§6).
7. Email Dashboard → Email Printable Queue — the oldest IN_QUEUE rows are less than a day old or show a climbing retry; old rows at retry 0 are being skipped (§4b).

All seven clean is the healthy state. The Discrepancies Report (§8) is the check on the period as a whole.

Related applets

• My E-Invoice Portal Applet — the buyer-facing side: a customer searches for their receipt, requests an individual e-invoice (processed at once, and logged on Portal Request here) or raises a rejection request that appears in Cancellation → Rejection Requests.
• My Peppol Admin Applet — fills its own Waiting Queue at FINAL, independently of this applet, and again when a submission to LHDN succeeds; it never waits for a Valid result.
• Organisation Applet — company e-invoice status, TIN/BRN/SST/MSIC, address and the e-invoice settings.
• Customer Applet, Supplier Applet — the buyer/supplier fields that decide whether a document passes the mandatory check.
• Sales Invoice (Internal), POS General, Sales Credit Note, Sales Debit Note, Sales Refund Note, Sales Return — where the submission type, skip flag and e-invoice tab live; credit/debit/refund notes and returns carry the original e-invoice reference.
• Purchase Invoice (Internal) — self-billed purchase e-invoices enter the same pipeline when Self-Billed is on.
• Doc Item Maintenance, Tax Configuration — item classification codes and tax types on the lines.

Troubleshooting

Related documentation

• E-Invoice Pools & Submission Routing — the 23 routing scenarios and what to do in each pool
• E-Invoice Validation Rules & Troubleshooting — mandatory fields, general TINs, currency and reference errors
• MyInvois Setup Guide — company registration, intermediary authorisation and first submission
• The Month-End E-Invoice Cycle — the 1st-to-7th routine: pools, exports, the Invalid list and the monthly tally
• Cancelling and Correcting a Validated E-Invoice — the 72-hour window, the rejection-request workflow and the credit-note path
• E-Invoice module — module overview and related applets