Source: Google Gemini

Most e-Invoice projects start in the wrong place.

They start with:

  • API specs,
  • portal access,
  • middleware demos,
  • and a lot of confident talk about “automation.”

Then the first rejection happens. Or the first refund note gets delayed. Or finance discovers that seller balance does not tie back to the original validated document.

That is when everyone realises the uncomfortable truth:

e-Invoice is not only a submission project. It is a finance control project.

For marketplace-heavy businesses selling through Shopify, Shopee, TikTok Shop, and similar channels, the real challenge is not only sending a document to MyInvois. The real challenge is making sure the document matches:

  • the source order,
  • the buyer data,
  • the discount and shipping logic,
  • the later refund or return,
  • and the final settlement trail.

Malaysia’s e-Invoice system validates documents in near real time and supports B2B, B2C, and B2G transactions. The current official references are the LHDN e-Invoice Guideline Version 4.6, the Specific Guideline Version 4.6, and the MyInvois SDK and FAQs. (Hasil)

This playbook is designed for finance teams that want a practical path from marketplace order to LHDN submission without losing control halfway.

Step 1: Start with transaction truth, not payout truth

The first rule is simple:

Do not build e-Invoice logic from seller balance or bank receipts.

Build it from the original transaction population.

Marketplace settlement is useful for reconciliation, but it is already affected by:

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

LHDN’s framework is built around the transaction and validated document lifecycle, while MyInvois separately supports document submission, search, and retrieval. That tells you clearly that source transaction truth comes first, settlement truth comes later. (Hasil)

So the finance-first starting point is:

  • freeze the source order population,
  • identify which transactions belong to the period,
  • and classify them before any submission happens.

If your team waits for marketplace payout before deciding what belongs in the month, the process is already weaker than it should be.

Step 2: Classify the transaction properly

Not every order follows the same document path.

Finance should classify each transaction into one of these broad buckets:

  • identified buyer requiring individual e-Invoice,
  • general public / eligible consolidated flow,
  • adjustment case linked to an existing validated document.

LHDN’s General FAQ states that consolidated e-Invoices may be used where buyers do not require individual e-Invoices, except for excluded transactions under the Specific Guideline, and such consolidated e-Invoices must be issued within seven calendar days after month-end. The Specific Guideline also shows the general-public treatment and the underlying receipt-reference concept. (Hasil)

This step matters because if finance does not classify early, teams often make two mistakes:

  • they treat everything as individual issuance,
  • or they overuse consolidated treatment without checking whether the transaction is actually eligible.

A finance-first playbook always decides the document path before the submission step.

Step 3: Clean buyer data before you try to invoice

This is one of the most common sources of pain.

The MyInvois FAQ sets strict format rules for buyer and supplier data, including TIN, email, phone, postal code, and field lengths. It also recommends validating TIN through MyTax Portal or the Validate Taxpayer’s TIN API. The FAQ notes that individual TINs now use the IG prefix, and other TIN formats also have defined rules. (Hasil)

That means finance should not assume marketplace checkout data is automatically good enough.

Before submission, confirm:

  • buyer classification,
  • buyer TIN where relevant,
  • name quality,
  • ID / registration data where needed,
  • and whether missing fields push the transaction into a different treatment path.

A very practical finance control is a pre-submission exception list for:

  • missing TIN,
  • invalid email,
  • bad postcode,
  • and unclear buyer type.

That catches problems before they become rejections.

Step 4: Map items, discounts, shipping, and charges properly

This is where many businesses still behave as if one net order total is enough.

It is not.

LHDN’s Guideline includes separate fields for discount rate, discount amount, fee or charge rate, and fee or charge amount at both line and invoice level. The MyInvois invoice document structure also supports these values in formal document fields. (Hasil)

So finance needs a mapping rule that answers:

  • what is item value,
  • what is seller-funded discount,
  • what is shipping charged to customer,
  • what is a charge,
  • and what is only a later settlement effect.

This is especially important for marketplace sales where:

  • vouchers can be seller-funded or platform-funded,
  • free shipping can be seller-borne or platform-subsidised,
  • and the customer-facing total does not tell the whole economic story.

A finance-first team does not wait for payout to discover this. It maps the transaction at source.

Step 5: Assign a stable internal reference before submission

MyInvois uses your internal invoiceCodeNumber in the Submit Documents process, and the system later lets you retrieve full document details by unique ID, including validation results. (MyInvois SDK)

This makes internal reference design much more important than many teams realise.

For each transaction, retain:

  • source order ID,
  • internal invoice code number,
  • legal entity,
  • channel,
  • and later the validated LHDN unique identifier.

That mapping table becomes the backbone of the whole playbook.

If your business cannot connect:
order ID > invoice code number > validated UUID

then later returns, refund notes, or seller balance deductions will be much harder to manage cleanly.

Step 6: Submit, then capture validation results immediately

Once the data is ready, submission is the straightforward part.

MyInvois allows taxpayers to submit one or more signed documents through the Submit Documents API. Once validated, the document receives an IRBM Unique Identifier Number, validation date and time, and a validation link. (MyInvois SDK)

A finance-first process does not stop at “submitted.”

It should capture and store:

  • submitted status,
  • valid or invalid result,
  • validated UUID,
  • validation timestamp,
  • and any rejection reason if invalid.

This is the moment where the commercial transaction becomes a formal tax document. Finance should treat this as a controlled milestone, not as a background technical event.

Step 7: Share and archive the validated document trail

The e-Invoice Guideline says that once validated, the supplier is obliged to share the validated e-Invoice with the buyer, and until further notice the IRBM provides a concession allowing either the validated e-Invoice or a visual representation of it to be shared. The validated document also includes a QR code in the portal-generated visual representation. (Hasil)

For finance, the bigger issue is retention.

Archive together:

  • source transaction record,
  • validated document result,
  • buyer support,
  • pricing / discount support,
  • and accounting reference.

That creates one clean audit trail instead of five scattered folders and one heroic spreadsheet.

Step 8: Watch the 72-hour clock

This is one of the most important controls in the whole process.

LHDN allows cancellation or buyer rejection of a validated e-Invoice within 72 hours from the time of validation. After that, later changes must generally be handled through a new e-Invoice such as a credit note, debit note, or refund note. (Hasil)

This means finance must monitor:

  • when the original document was validated,
  • when an issue was discovered,
  • and whether the case is still a cancellation case or now an adjustment-note case.

A weak process says:

“Just cancel and redo.”

A strong process says:

“Check validation time first.”

That one difference prevents a lot of compliance mistakes.

Step 9: Treat refunds and returns as note-document events, not only ops events

This is where ecommerce teams often slip.

A marketplace refund may appear first as:

  • customer complaint,
  • return request,
  • stock receipt,
  • or later seller balance deduction.

But under LHDN, once the original invoice is validated, later changes must follow document logic.

The SDK and document-type references distinguish:

  • Invoice,
  • Credit Note,
  • Debit Note,
  • and Refund Note. The SDK also describes refund notes and explains that the original document reference must be included for adjustments. (MyInvois SDK)

So your refund workflow should capture:

  • original order ID,
  • original invoice code number,
  • original validated UUID,
  • refund amount,
  • whether money was returned,
  • stock outcome,
  • and note-document type used.

That is the difference between “customer service handled it” and “finance can prove it.”

Step 10: Reconcile seller balance separately, but link it back

This is where the finance-first playbook becomes much stronger than a tech-first one.

Marketplace payout is not the invoice.
Seller balance is not the sale.
Bank receipt is not the original transaction value.

But they all still need to connect.

Use a reconciliation bridge that links:

  • order ID,
  • invoice code number,
  • validated UUID,
  • note-document reference if any,
  • seller balance event,
  • payout batch,
  • bank receipt.

The e-Invoice framework and MyInvois APIs give you the document side; marketplace settlement gives you the cash side. Finance needs to connect both. (MyInvois SDK)

Without that bridge, businesses often end up with:

  • valid invoices,
  • correct payouts,
  • and no clean explanation of how one became the other.

Step 11: Build a rejection and exception workflow

The MyInvois SDK includes standard error responses, and the FAQ covers issues like duplicates, token expiry, file size considerations, and field-validation failures. (MyInvois SDK)

Finance should require an exception log that tracks:

  • invalid submissions,
  • top rejection reasons,
  • missing buyer data,
  • missing original invoice references,
  • duplicate risk,
  • and note-document cases still unresolved.

This turns rejections into a control process instead of repeated panic.

Step 12: Close the month with an evidence pack, not just a sales summary

A finance-first month-end close should leave behind one evidence pack with:

  • source sales population,
  • buyer exceptions resolved,
  • submitted and validated document list,
  • rejected and corrected list,
  • credit / debit / refund note register,
  • seller balance reconciliation,
  • bank matching,
  • and accounting journal support.

LHDN’s Guideline reminds taxpayers to retain sufficient records and documentation relating to transactions. The broader MyInvois lifecycle also supports retrieval of document details and validation results later. (Hasil)

That means your month-end output should not be only:

“Sales for March: RM___.”

It should also answer:

“Can we prove what we submitted, what changed later, and how it reconciles to cash?”

That is the real finance-first standard.

Final thoughts

A finance-first e-Invoice playbook is not complicated because finance likes making life difficult.

It is necessary because ecommerce transactions move through several worlds:

  • order world,
  • document world,
  • settlement world,
  • and accounting world.

The businesses that struggle most are usually the ones that focus only on the middle step:
submission.

The businesses that do better are the ones that build a controlled flow from:
marketplace order > classification > validation > adjustment > settlement reconciliation > evidence retention

That is the playbook.

And once you get that right, LHDN submission stops feeling like a separate compliance burden.

It becomes part of a cleaner finance operating model.