The Complete Malaysian SME Accounting & LHDN e-Invoicing Blueprint 2026

What is the Malaysian SME accounting blueprint for 2026?

The practical blueprint is one connected operating cycle:

Commercial event
→ source document
→ accounting classification
→ invoice, bill, payroll run or journal
→ e-Invoice or statutory evidence where applicable
→ bank settlement
→ reconciliation
→ month-end review

The order matters. An e-Invoice should not be generated from unreviewed customer and tax data. A bank deposit should not become revenue merely because it is money in. Net salary should not replace gross salary in the profit and loss statement. A new PLT should not inherit the old Sdn Bhd's history merely because the owners are the same.

A complete SME business finance guide for Malaysia therefore needs five connected control lanes:

1. Entity and master data: legal owner, taxpayer profile, financial year, bank accounts, customers, suppliers, products and chart of accounts.
2. Sales and MyInvois: commercial invoice, accounting recognition, UBL mapping, direct submission, returned UUID and document status.
3. Payroll and general ledger: gross-to-net calculation, employer cost, accrual journal, statutory remittance and bank clearing.
4. Cash and settlement: statement import, receivable or payable matching, marketplace gross-to-net decomposition and exception approval.
5. Close and compliance: bank reconciliation, trial balance, receivables, payables, SST working papers, payroll schedules and retained evidence.

This is an operational blueprint, not a promise that one dashboard removes professional judgment. LHDN, KWSP, PERKESO, HRD Corp, RMCD and SSM requirements must be checked against their current published guidance and the business's actual facts.

Which records should be the source of truth?

Use a clear owner for each fact. Duplicate fields are unavoidable, but uncontrolled competing values are not.

Business fact	Primary record	Month-end proof
Legal issuer	Entity and company profile	Invoice name, registration and taxpayer identity agree
Customer identity	Customer master plus transaction snapshot	TIN and registration used for the document are traceable
Sale	Issued invoice and line items	Subtotal, discount, tax and total foot to the ledger
LHDN filing	Submission record and returned UUID/status	Payload, hash, response and invoice remain linked
Payroll earned	Approved payroll run and payslips	Gross, deductions, employer costs and journal agree
Cash movement	Original bank statement line	Imported value, date, direction and mapped account agree
Marketplace payout	Provider settlement report	Gross less refunds, fees and adjustments equals bank credit
SST adjustment	Invoice, credit note and working schedule	Rate, taxable value, tax and original reference agree
Entity transfer	Signed agreement and cutover schedule	Both entities carry equal and opposite inter-entity balances

Adopt stable transaction identifiers early: invoice number, supplier invoice reference, payroll month, bank transaction ID, marketplace batch ID, LHDN UUID and credit-note reference. A reviewer should be able to travel from financial statement to journal to source document, and from source document forward to settlement.

Avoid using free-text notes as the only link. Notes help humans, but identifiers, dates, amounts and entity ownership make a control reproducible.

How should entity, bank and tax boundaries be set up?

Start with the legal entity, because every downstream document inherits that boundary. Record its legal name, registration, taxpayer identity, reporting currency, financial-year start, authorised bank accounts and relevant registrations. Keep credentials outside worksheets and ordinary document attachments.

If a business operates both a Sdn Bhd and a PLT, create separate accounting populations. Each needs its own:

• accounting tenant and opening trial balance;
• invoice and credit-note sequences;
• bank accounts and reconciliation;
• customer and supplier balances;
• MyInvois taxpayer profile, authority and submission history;
• payroll population where applicable; and
• closing, tax and statutory evidence.

The key cutover rule is simple: the issuing entity owns the invoice by default. A Sdn Bhd invoice issued before cutover does not become PLT revenue when paid later. If RM10,000 for that invoice lands in the PLT bank:

PLT
Dr Bank                               RM10,000
    Cr Due to Sdn Bhd                            RM10,000

Sdn Bhd
Dr Due from PLT                       RM10,000
    Cr Accounts receivable                       RM10,000

The later inter-entity remittance clears the due-to and due-from accounts. The exact legal transfer, measurement and tax treatment require supporting documents and adviser review. The detailed Sdn Bhd-to-PLT accounting migration guide explains receivable ownership, opening balances and the dual-bank cutover.

GetPay can keep entities in distinct tenants and read each tenant's configured gl_mode, but it does not decide legal ownership. In POSTED mode, reports read real journal-entry lines. In VIRTUAL mode, reports synthesize bank categories with defined invoice overlays. Operators must know which mode a tenant uses because “invoice paid” and “journal posted” are not equivalent statements.

How should sales flow into MyInvois?

Begin with accounting-complete sales data:

• legal supplier identity and registration;
• customer identity, TIN and registration where applicable;
• invoice number, issue date and currency;
• line description, quantity, unit price and tax-exclusive amount;
• discount;
• tax type, rate and amount;
• subtotal and payable total; and
• payment terms and later settlement references.

For an accrual sale, the accounting shape is:

Dr Accounts receivable
    Cr Revenue
    Cr SST payable, where applicable

Payment later debits the proven bank account and credits accounts receivable. Do not credit revenue a second time when cash arrives.

GetPay's ordinary MyInvois mapper constructs the JSON variant of a UBL 2.1 Invoice. Its current standard flow uses document type 01, list version 1.1 and MYR. The UBL object carries the invoice identity, supplier, buyer, itemised lines, tax total and legal monetary total. The MyInvois API payload guide maps source fields such as invoice.invoice_number, item.quantity, invoice.subtotal, invoice.tax_amount and invoice.total to the emitted document.

Before submission, prove three equalities:

sum of line tax-exclusive amounts = document subtotal
sum of allocated line tax = document tax
subtotal + tax − valid adjustments = payable total

GetPay allocates rounded document tax across positive lines so the line allocations add back to the document tax in sen. This matters because independently rounding each line can make the document internally inconsistent.

An LHDN-valid document is not a complete accounting close. Preserve the commercial invoice, journal effect, submission payload, UUID, returned status, payment and any later credit note as one evidence chain.

What controls make direct MyInvois submission safe?

GetPay obtains MyInvois credentials from the tenant's company record and uses the configured sandbox or production environment. The client requests an InvoicingAPI access token, respects the returned expires_in, and refreshes before the final 60 seconds.

The transmission control is implementation-specific and important:

1. Build the final UBL object.
2. Run JSON.stringify() once.
3. Calculate the SHA-256 hexadecimal hash from that string's UTF-8 bytes.
4. Base64-encode the same string.
5. Send format, document, documentHash and codeNumber.
6. Store submissionUid, accepted UUIDs and any rejection evidence returned by LHDN.

Do not alter or reformat the document between hashing and Base64 encoding. Those two fields must describe the same bytes.

Token requests and document-status reads can retry with backoff because they do not create a tax document. Document submission is timeout-bounded but is not automatically retried. If the response is lost, LHDN may already have accepted the document. Replaying the submission could create a duplicate, so the outcome must be treated as unknown and reconciled from the retained operation evidence. The MyInvois API error guide provides the evidence-first diagnostic sequence.

How should statutory payroll become a GL journal?

Payroll has two accounting moments: accrual when remuneration is earned, and settlement when employees and agencies are paid.

GetPay's posted payroll path aggregates one run into these verified account roles:

GetPay GL account	Debit	Credit
5100 Salary, Allowance & Wage	Employee gross	—
5200 EPF & Socso	Employer EPF + SOCSO + EIS	—
5210 HRDF Levy	HRDF for the run	—
2200 Directors Account	Genuine partner/director-owner drawings	—
2500 Accrued Expenses	—	Total of the debit lines

Employee EPF, SOCSO, EIS and PCB deductions are already inside gross salary. They reduce net pay but are not additional employer expense debits. Employer contributions are additional cost. This distinction prevents both understating salary by posting only net pay and overstating expense by debiting employee deductions twice.

Settlement then clears the accrual:

Dr 2500 Accrued Expenses
    Cr mapped bank account

GetPay's bank-import posting requires both a salary-related category and a payroll-related description before it automatically uses that clearing shape. This avoids treating every owner-category transaction as payroll.

Do not copy contribution rates from a static blog table into production payroll. Calculate from the employee's actual facts and reconcile against current KWSP, PERKESO, LHDN and HRD Corp guidance. The payroll double-entry manual shows the field-level gross, deduction, employer-cost and settlement mechanics.

How should net marketplace and gateway payouts be reconciled?

Never compare one Shopee order, TikTok Shop order or Stripe charge directly with one bank credit and stop there. Prove the batch:

Gross sales
− refunds and reversals
− report-backed MDR, commission and gateway fees
± report-backed adjustments
= net bank payout

Assume RM10,000 of gross sales was already recognised as accounts receivable and the provider report proves RM300 of fees. The RM9,700 deposit is:

Account	Debit (RM)	Credit (RM)
Mapped bank account	9,700.00	—
6100 Bank Charges	300.00	—
1200 Accounts Receivable	—	10,000.00

Use 6100 only when the tenant's chart and the actual report support the BANK_FEE classification. Do not invent an MDR percentage, fee or clearing account merely to balance the bank.

Keep order date, settlement date, payout date and bank value date separate. At month-end, a completed sale whose payout remains in transit stays in a receivable or supported clearing balance; it does not disappear because the bank receives cash next month.

GetPay's matcher reads credit lines and proposes matches using invoice-reference, amount and party evidence. Confirmation is a controlled action: it refuses an unresolved landing account, an inter-entity account and a locked period. A single-invoice allocation is capped at outstanding; a multi-invoice allocation requires the outstanding balances to equal the bank credit.

That final rule is an honest product boundary. If gross invoices total RM10,000 but fees reduce the deposit to RM9,700, GetPay does not automatically infer the RM300. First perform the gross-to-net reconciliation, then post the supported fee treatment. The Shopee, TikTok Shop and Stripe net-settlement guide provides the full batch schedule and exception workflow.

How should SST and credit notes fit into the blueprint?

SST classification is a transaction decision. Confirm the taxable-service group, supplier registration, effective date, exemption and current RMCD treatment before choosing a rate. Eight per cent is not a universal rate; current RMCD guidance includes other treatments.

Store the taxable value and tax separately. If an invoice is reduced, do not overwrite the original. Issue a controlled credit note that references it and reverses both the revenue and the SST component:

Dr Revenue
Dr SST payable
    Cr Accounts receivable

The rate on the credit should follow the original adjusted supply. Retain the original invoice reference, reason, taxable-value reduction and tax reduction.

The current GetPay implementation has material limits:

• its standard invoice flow maps the service preset to 6%, sales to 10% and exempt to zero;
• it does not expose a verified 8% or mixed-rate service workflow;
• getSSTReturn() sums eligible invoice values and SST_GST bank-transaction components for fixed bimonthly periods;
• that computation does not read credit_notes or produce statutory rate bands; and
• Lock snapshot records an internal working-paper snapshot but does not file SST-02 with RMCD.

Therefore, reconcile credit notes, rate bands and the business's applicable accounting basis outside the current summary before preparing the statutory return. The SST invoicing, credit-note and SST-02 guide documents the supported arithmetic and these boundaries.

What should happen during every month-end close?

Use a fixed close calendar with named owners and evidence:

1. Freeze the month's bank, marketplace and payroll source files.
2. Confirm every bank account has a complete statement population.
3. Reconcile bank balances and investigate unmatched or duplicated rows.
4. Tie issued invoices to revenue, accounts receivable, SST and MyInvois evidence.
5. Reconcile collections to invoices without crediting revenue twice.
6. Prove each marketplace batch gross-to-net and roll forward unsettled payouts.
7. Tie payroll gross, deductions, employer costs and drawings to the payroll journal.
8. Match net salary and statutory remittances against the accrued payroll balance.
9. Review credit notes, refunds, bad debts, fixed assets, prepayments and accruals.
10. Produce a trial balance, profit and loss statement, balance sheet, receivables aging and payables schedule.
11. Review SST and other statutory working papers against source values.
12. Lock the period only after exceptions have an owner, explanation and resolution date.

Do value checks, not only row-count checks. Sample a sales line from invoice to UBL payload to journal to bank. Sample a payslip from gross calculation to journal to payments. Sample a marketplace bank credit back to the native settlement report. Counts can agree while amounts or classifications are wrong.

What is a practical 90-day implementation sequence?

Days 1–30: establish control

• confirm every legal entity and taxpayer profile;
• inventory bank accounts, invoice sequences, payroll populations and filing obligations;
• define the chart of accounts and financial-year basis;
• clean customer, supplier and product masters;
• record opening balances with supporting schedules; and
• document who may create, approve, submit, pay, reconcile and lock.

Days 31–60: connect operating cycles

• standardise invoice fields and credit-note references;
• test MyInvois in the correct environment using reviewed data;
• map payroll outputs to the verified accrual and clearing accounts;
• import bank statements through preview and approval;
• create a normalized marketplace batch schedule; and
• operate separate due-to/due-from controls for any cross-entity receipt.

Days 61–90: prove the close

• run one complete month-end close;
• resolve every unexplained bank and settlement difference;
• trace selected documents end to end;
• reconcile receivables, payroll accruals and tax working papers;
• review user access, period locks and evidence retention; and
• have the accountant or relevant adviser review statutory classifications and filings.

The implementation is complete when the system can explain a transaction without relying on the memory of one employee. The durable result is not merely “submitted to LHDN” or “bank matched.” It is a defensible chain showing which entity acted, what occurred, how it was recorded, how it settled, what was filed and who reviewed it.