Source: Google Gemini

Vouchers look simple to customers.

They see:

  • RM10 off
  • free shipping
  • campaign subsidy
  • checkout total reduced

Very nice.

Finance sees something else:

  • was that a seller-funded discount?
  • was it platform-funded support?
  • was it a price reduction or a fee adjustment?
  • should it reduce the invoice value?
  • does it belong in the original e-Invoice or only in settlement analysis?

That is where confusion starts.

For Malaysian businesses preparing for LHDN e-Invoice, vouchers are one of the easiest places to get the document logic wrong. The reason is simple: a “voucher” is a commercial label, but e-Invoice treatment depends on what the voucher actually did to the transaction value and who funded it. LHDN’s e-Invoice Guideline includes formal fields for discount rate, discount amount, fee/charge rate, and fee/charge amount at both line and invoice level, while the MyInvois SDK models these through AllowanceCharge structures with different treatment for discounts versus charges.

This guide explains the practical treatment of vouchers, discounts, and subsidies under LHDN e-Invoice for sellers using Shopify, Shopee, TikTok Shop, POS, and other channels. The goal is not only to submit a valid document, but to make sure the invoice reflects the real commercial event instead of a rough guess. LHDN’s e-Invoice system is a near real-time validation model for B2B, B2C, and B2G transactions, so weak voucher logic can become both a compliance and reconciliation problem. (Hasil)

First principle: a voucher is not one thing

The word “voucher” is too broad for tax and invoice purposes.

A voucher may represent:

  • a seller-funded discount
  • a platform-funded subsidy
  • a shared campaign support amount
  • a shipping subsidy
  • or a later post-sale reduction

LHDN’s core invoice fields do not use the word “voucher” as a special standalone document category. Instead, the framework expects the economic effect to be reflected through structured discount or charge fields, and where value changes later after validation, the change is handled through note documents such as credit notes or refund notes. The SDK also defines a credit note as a document used to reduce the value of the original e-Invoice where no monies are returned to the buyer.

That means the first finance question should never be:
“Was there a voucher?”

The better question is:
“What did this voucher actually do to the transaction value, and who absorbed the cost?”

Why this matters more in Shopify, Shopee, and TikTok

These channels handle discounts differently.

Shopify gives merchants more direct control over checkout pricing and discount construction. Shopee and TikTok often combine seller-funded promos, platform campaigns, shipping support, and later settlement deductions in ways that are operationally convenient but less clean from a finance-document perspective. Meanwhile, LHDN’s e-Invoice rules still expect a structured transaction view with consistent discount, charge, buyer, and adjustment treatment. (Hasil)

So the same commercial-looking promo can behave differently underneath:

  • one voucher may reduce the invoice value directly
  • another may be economically funded by the platform
  • another may hit seller settlement later but not represent the original selling price
  • another may be linked to shipping rather than goods value

If finance does not separate those cases, the business may still issue an invoice, but the document trail and the seller balance trail will not reconcile cleanly later.

The safest starting rule: distinguish seller-funded from non-seller-funded support

This is the most practical control.

Seller-funded discount

If the seller genuinely gives up part of the selling price, that reduction should normally be reflected as a discount in the invoice value logic. LHDN’s Guideline explicitly provides discount rate and discount amount fields, and the SDK maps discounts through AllowanceCharge with ChargeIndicator = false, including a reason field to describe the line-item discount applied.

Charge or fee

If an amount is an additional charge rather than a discount, it should not be buried inside the same logic. The Guideline separately defines fee / charge rate and fee / charge amount, and the SDK maps these through AllowanceCharge with ChargeIndicator = true.

Platform-funded support

This is the trickiest area. If the customer receives a lower checkout price but the platform, not the seller, bears the support economically, then finance should be careful before treating the full amount as a seller discount. The LHDN documents do not create a special “platform voucher” field; instead, businesses need to reflect the transaction truth through the existing discount and charge framework, while keeping their own reconciliation support to prove whether the reduction truly belonged to seller revenue or to later platform settlement support.

That is why voucher treatment is really a mapping problem.

The four common voucher scenarios

1. Seller-funded product discount at checkout

This is the cleanest case. The original selling price is reduced by the seller before invoicing, so the discount belongs in the invoice amount logic itself. LHDN’s invoice structure supports both discount rate and discount amount at line and invoice level, and total values are described as payable amounts inclusive of applicable discounts and charges.

2. Seller-funded order voucher

This is also usually part of invoice discount logic, but finance needs to decide whether to allocate it at line level or invoice level in a consistent way. Since the Guideline allows discounts at both levels, the key is not “which level is allowed” but “which method is applied consistently and supportably.”

3. Platform-funded campaign voucher

This is where many businesses make mistakes. If the platform funds all or part of the reduction, the customer still sees a lower price, but the seller may not bear the whole cost. In these cases, the business should avoid assuming that the full customer-facing discount automatically equals seller-funded discount. The invoice and reconciliation treatment should be aligned with the real economic arrangement, using internal support schedules to distinguish seller-funded and platform-funded portions.

4. Free shipping or shipping subsidy marketed as a voucher

This should not automatically be treated as a product discount. LHDN’s invoice framework separates discounts from charges, and businesses should keep shipping-related support analytically separate from pure item-price markdowns where possible. Otherwise, product margin, tax logic, and settlement reconciliation become harder to explain.

What should appear on the original e-Invoice?

A good practical rule is:

The original e-Invoice should reflect the original transaction value actually attributable to the supplier at the time of issuance, using the proper discount and charge fields for reductions or additions that form part of the transaction.

LHDN’s Guidelines describe invoice totals as amounts inclusive of applicable line-item and invoice-level discounts and charges, and the SDK shows how those values are represented structurally. That means if the seller is truly reducing the transaction value through a discount, the e-Invoice should reflect that through the formal discount fields, not by hoping settlement deductions will explain it later.

Where platform support exists, the business still needs internal evidence showing:

  • gross item value
  • seller-funded discount portion
  • platform-funded support portion
  • settlement impact later

That internal bridge is not optional for good finance control, even if the final invoice can still be rendered in valid schema format. (sdk.myinvois.hasil.gov.my)

What if the subsidy is discovered only later?

This is where note-document logic matters.

If, after validation, the business later discovers that the transaction value needs to be reduced, LHDN’s framework does not allow indefinite cancellation. Cancellation is only allowed within 72 hours after validation with justification; after that, adjustments must be handled through a new e-Invoice such as a credit note, debit note, or refund note.

That means if a voucher or subsidy issue is not reflected correctly in the original document and needs to be corrected later, finance must ask:

  • is this inside the 72-hour window?
  • was money returned to the buyer?
  • or is this simply a value reduction without repayment?

The SDK defines a credit note as the correct document where the original invoice value is reduced and no monies are returned to the buyer. (sdk.myinvois.hasil.gov.my)

So if a seller later grants a post-sale discount without refunding cash, a credit note may be the relevant adjustment path. If actual cash is returned, refund-note logic should be assessed instead. (sdk.myinvois.hasil.gov.my)

The biggest practical mistake: using settlement as the source of voucher truth

Many marketplace sellers only see the final effect in seller balance:

  • order sold
  • platform deducts fees
  • voucher funding netted somehow
  • payout lower than expected

That is useful for reconciliation, but it is a weak starting point for invoice design. Seller balance is a settlement result, not the original commercial document population. If voucher logic is only understood after settlement, your business is already one step late for clean invoice handling.

A stronger process is:

  1. classify voucher type at transaction level
  2. map seller-funded discount into invoice fields where appropriate
  3. keep platform-funded subsidy support separately in a reconciliation file
  4. reconcile later settlement to that documented commercial truth

That is how the invoice and cash story stay aligned.

A practical example

Imagine a product listed at RM100.

The customer gets:

  • RM10 seller voucher
  • RM15 platform campaign support
  • RM8 free shipping subsidy borne by seller

A weak process might just look at the final payout and say:

“The platform paid less, so we will sort it out later.”

A stronger process would split it properly:

  • product gross value = RM100
  • seller-funded reduction = RM10, reflected as discount logic
  • platform-funded support = separately tracked as platform support in reconciliation
  • shipping subsidy = tracked separately from product discount for management and settlement analysis
  • later payout matched back to these components

LHDN’s discount and charge fields support documenting the commercial reduction, while your internal bridge file explains the rest of the economics.

What evidence should finance keep?

For voucher-heavy businesses, keep a monthly support file showing:

  • SKU / order reference
  • original gross value
  • seller-funded discount amount
  • platform-funded support amount
  • shipping subsidy amount
  • validated invoice code / reference
  • later settlement effect

This matters because LHDN compliance is not only about producing a valid invoice schema. It is also about being able to explain why the invoice value, seller balance movement, and accounting result all make sense together. The Guideline reminds taxpayers to retain sufficient records and documentation relating to transactions.

Common mistakes to avoid

Mistake 1: treating all vouchers as seller discounts

That overstates discount cost and can distort invoice value if platform funding exists.

Mistake 2: mixing shipping subsidy with product markdown

That makes margin analysis and later reconciliation harder. LHDN’s invoice model already distinguishes discounts from charges, so businesses should preserve that logic as much as possible.

Mistake 3: waiting for payout to figure out the voucher treatment

That is too late for clean original invoice design.

Mistake 4: correcting old voucher errors by “cancelling later”

After 72 hours, cancellation is no longer the route; the adjustment must be handled through a new note document.

Mistake 5: no internal mapping between voucher type and invoice field

Then every campaign month becomes manual interpretation work.

A practical workflow that works

Start with a simple internal classification:

  • Type A: seller-funded discount
    Map to discount field treatment on the invoice.
  • Type B: platform-funded support
    Keep separate in reconciliation support; do not automatically treat as full seller discount.
  • Type C: shipping subsidy
    Track separately from pure product discount for management and settlement control.
  • Type D: post-validation value reduction
    Assess cancellation window first, then credit note or refund note as applicable.

Then build one channel mapping table covering Shopify, Shopee, and TikTok so the same commercial event is not treated three different ways.

Final thoughts

LHDN e-Invoice does not create a magical “voucher” document type.

It gives you structured discount and charge fields, and then later note documents if something changes after validation. The hard part is not the schema. The hard part is making sure your commercial promotion logic is mapped into those fields correctly.

The safest way to think about vouchers is this:

  • identify who funded the reduction
  • separate product discount from shipping subsidy
  • keep platform support distinct from seller discount
  • use the original invoice to reflect real seller-funded transaction value
  • use credit notes or refund notes later only when the facts change after validation

Do that, and your voucher treatment will match both commercial reality and LHDN document logic.