Source: Google Gemini

For many ecommerce businesses, LHDN e-Invoice and seller balance reconciliation are handled like two separate projects.

One sits with tax or finance.
The other sits with marketplace operations or accounting.
One is about “document submission.”
The other is about “why payout doesn’t match sales.”

That split is exactly the problem.

Because for sellers using Shopee, TikTok Shop, Lazada, and similar marketplace models, the missing link in most systems is this:

The validated e-Invoice trail and the seller balance trail are often not connected properly.

So what happens?

  • the sale is documented one way,
  • the settlement is deducted another way,
  • refunds hit later,
  • credit notes or refund notes are treated separately,
  • and finance only sees the cash effect when payout lands in the bank.

By then, the story is harder to reconstruct.

Under LHDN’s e-Invoice framework, that is a weak place to be. Once an e-Invoice is validated, it gets an official unique identifier and validation timestamp, and after 72 hours, cancellation is no longer allowed; later changes must be handled through a new e-Invoice such as a credit note, debit note, or refund note. (Hasil)

That means if your seller balance process is not tied tightly to your original invoice and later adjustment documents, your compliance trail and your reconciliation trail will drift apart.

This guide explains why seller balance reconciliation is the missing link in many e-Invoice setups, what businesses should connect first, and how Malaysian SMEs can build a process that actually works.

Why this gap exists in the first place

Most marketplace systems were built to help sellers operate, not to help finance prove document truth.

A marketplace usually gives you:

  • order data,
  • payout or settlement data,
  • fee deductions,
  • refund deductions,
  • and net seller balance movement.

That is useful for operations and cash control.

But LHDN e-Invoice is built around:

  • source transaction data,
  • validated document records,
  • original invoice references,
  • and controlled note documents for later adjustments. (sdk.myinvois.hasil.gov.my)

Those are not the same thing.

So businesses often end up with two disconnected worlds:

World 1: e-Invoice world

  • invoice issued
  • validated
  • UUID assigned
  • adjustment note required later if something changes

World 2: seller balance world

  • order settles
  • fees deducted
  • refund netted later
  • payout reaches bank

If those two worlds are not linked by design, finance gets stuck doing detective work.

First principle: seller balance is not the same as invoice value

This is the first thing every team needs to accept.

A seller balance movement is not the same as:

  • gross sales,
  • invoice value,
  • or even net sales.

It is a settlement result after:

  • fees,
  • vouchers,
  • refunds,
  • shipping deductions,
  • affiliate costs,
  • and timing differences.

That means if your business tries to use seller balance as the main source for invoice logic, you will create avoidable problems.

Why?

Because an e-Invoice documents the transaction.
Seller balance documents what the platform still owes you after other events.

Those are related, but they are not interchangeable. (Hasil)

Where the missing link usually breaks

There are five places where the connection between e-Invoice and seller balance commonly fails.

1. Original invoice is validated, but seller balance has no invoice reference

This is one of the biggest structural weaknesses.

The original sale may be validated correctly in MyInvois. But when finance later reviews the marketplace seller balance, the settlement line usually shows:

  • platform order number,
  • settlement batch,
  • deduction type,
  • payout date.

It does not naturally show the original LHDN validated invoice UUID.

But when later adjustments happen, the original validated reference matters a lot. The MyInvois document structure requires the Original e-Invoice Reference Number field to contain the LHDNM Unique Identifier Number of the original invoice or document being adjusted. (sdk.myinvois.hasil.gov.my)

The practical problem

If your refund register or settlement mapping stores only order IDs and payout IDs, later credit note or refund note handling becomes much slower and riskier.

What to do

Your internal reconciliation layer should map:

  • marketplace order ID
    to
  • internal invoice code number
    to
  • validated LHDN UUID
    to
  • later seller balance movement

That is the missing bridge.

2. Refunds appear in settlement later, but no note document is triggered

This is extremely common.

The platform deducts a refund from seller balance.
Finance sees lower payout.
The team books a refund or reduction.
But no one checks whether a refund note or credit note should be issued.

LHDN’s framework is clear that after the 72-hour cancellation window, any later amendment must be handled through a new e-Invoice document such as a credit note, debit note, or refund note. Also, where money is actually returned to the buyer, refund note logic becomes relevant. (Hasil)

The practical problem

Marketplace deduction is treated as “the adjustment,” when really it is only the cash effect of the adjustment.

What to do

Every seller balance refund deduction should trigger a check:

  • Which original validated invoice does this relate to?
  • Is money being returned?
  • Which note document is required?
  • Has it already been issued?

Seller balance deduction should never be the only record of the change.

3. Credit notes and refund notes are decided by ops, not by transaction reality

Another common issue is document type confusion.

A lot of teams still think:

  • return = credit note
    or
  • refund = refund note
    without checking what actually happened.

But the MyInvois document definitions are more precise:

  • a credit note reduces the value of the original e-Invoice where the reduction does not involve return of monies to the buyer,
  • while a refund note is used where money is returned. (sdk.myinvois.hasil.gov.my)

The practical problem

Operations may classify the case by customer outcome only. Finance needs to classify it by document logic too.

What to do

Build one adjustment decision rule:

  • inside 72 hours and valid reason = cancellation may be possible,
  • outside 72 hours + no money returned = assess credit note,
  • outside 72 hours + money returned = assess refund note. (Hasil)

Then connect that to the seller balance effect later.

4. Consolidated e-Invoice timing is managed separately from settlement timing

This is another place where systems drift.

LHDN’s FAQ states that for consolidated e-Invoices, suppliers are required to issue the consolidated e-Invoice within seven calendar days after month-end. (Hasil)

Marketplace payout timing does not change that rule.

The practical problem

Some teams wait for seller balance settlement to “finalise the month,” then try to use those net figures as the base for consolidated e-Invoice preparation.

That is risky because settlement may:

  • arrive later,
  • include prior-period refunds,
  • include platform deductions,
  • and not reflect a clean transaction-month population.

What to do

Run two separate but linked processes:

  1. transaction-month e-Invoice / consolidated e-Invoice process,
  2. seller balance / payout / bank reconciliation process.

Then connect them through a proper reconciliation schedule.

5. Invoice code number is not tied cleanly to marketplace transaction IDs

The MyInvois Submit Documents API returns accepted and rejected documents by your internal invoice code number. That means your internal invoice code is a core control point for status tracking. (sdk.myinvois.hasil.gov.my)

The practical problem

If your systems store:

  • platform order ID in one place,
  • internal invoice number in another,
  • submission UID elsewhere,
  • and LHDN UUID somewhere else again,

then tracing one seller balance line back to one document trail becomes slow.

What to do

For every marketplace-origin transaction, store at minimum:

  • marketplace order ID,
  • internal invoice code number,
  • submission UID if needed,
  • validated LHDN UUID,
  • later note-document references.

That gives you a 1-to-many audit chain that can actually be used.

What a good linked process looks like

The cleanest model is this:

Step 1: Capture and validate the original sale

For each eligible transaction:

  • issue the e-Invoice or prepare for consolidated flow,
  • validate it,
  • store the internal invoice code number and LHDN UUID.

The UUID and validation timestamp matter because they determine later cancellation and adjustment rules. (Hasil)

Step 2: Create a reconciliation bridge table

This table should map:

  • marketplace order ID
  • order date
  • gross sale amount
  • internal invoice code number
  • LHDN UUID
  • settlement batch / payout reference
  • note-document reference if adjusted

This is the missing link in most systems.

Step 3: Review seller balance events by type

For each seller balance movement:

  • normal settlement
  • fee deduction
  • refund deduction
  • adjustment / penalty
  • affiliate or shipping deduction

Classify the event and determine whether it affects:

  • only finance,
  • or both finance and e-Invoice document trail.

Step 4: Trigger note-document assessment for refund-related events

If a seller balance movement reflects a customer refund or other value reduction:

  • check the original invoice,
  • check the 72-hour rule,
  • decide whether cancellation, credit note, or refund note is relevant,
  • and store the new note reference. (Hasil)

Step 5: Reconcile payout to bank separately

Only after the document and adjustment logic are clean should you reconcile:

  • gross sales,
  • less deductions,
  • to seller balance,
  • to payout,
  • to bank.

That keeps compliance logic and cash logic aligned, but not confused.

A practical example

Let’s say:

  • a Shopee order is completed on 25 March,
  • your system includes it in March’s invoice population,
  • the document is validated and gets an LHDN UUID,
  • a refund is approved on 5 April,
  • Shopee deducts it from seller balance on 9 April,
  • the April payout to bank is lower.

A weak process would only record:

  • lower April payout.

A stronger process would show:

  • original marketplace order ID,
  • original invoice code number,
  • original validated LHDN UUID,
  • refund approval date,
  • seller balance deduction date,
  • refund note or credit note reference as applicable,
  • April bank impact.

That is the full transaction truth.

The records every finance team should keep

To make this work in real life, keep a unified register with these fields:

  • channel
  • marketplace order ID
  • internal invoice code number
  • validated e-Invoice UUID
  • validation date/time
  • buyer classification
  • gross amount
  • seller balance event type
  • settlement batch / payout ID
  • refund / adjustment amount
  • whether cash was returned
  • credit note or refund note reference
  • bank receipt reference

This may sound detailed, but it saves enormous time later.

Without it, teams spend too long answering basic questions like:

  • Which invoice did this refund hit?
  • Was a note document issued?
  • Why is this payout lower?
  • Is this deduction current month or prior month?

Common mistakes to avoid

Mistake 1: treating seller balance as the source of truth for invoices

Seller balance is a settlement view, not the original document view.

Mistake 2: storing order ID but not validated invoice UUID

That weakens later adjustment handling.

Mistake 3: no rule connecting refund deductions to note documents

Then finance books the cash effect but misses the document effect.

Mistake 4: using one generic “adjustment” bucket

That hides whether the case required:

  • no document,
  • credit note,
  • or refund note.

Mistake 5: waiting for payout before deciding month ownership

That confuses settlement timing with invoice cut-off. Consolidated e-Invoices still follow the seven-calendar-day rule after month-end where applicable. (Hasil)

Final thoughts

Most systems can either:

  • issue e-Invoices,
    or
  • reconcile seller balances.

Very few are designed to connect both properly.

That is why this is the missing link.

If your business wants a stronger process, do not ask only:
“Did we submit the invoice?”
or
“Did payout hit the bank?”

Ask the harder, better question:
“Can we trace the seller balance movement back to the original validated document and every later adjustment?”

That is what good control looks like.

And once you build that bridge, e-Invoice and seller balance stop living in separate worlds.

They become one connected finance story.