Finance teams usually lead discussions about Malaysia’s electronic invoicing requirements. Store teams, however, collect buyer information, complete sales, issue receipts and process returns. Once those transactions need to reach MyInvois, the POS becomes part of the implementation.
The practical question is whether a sale and its invoice can be followed through their entire lifecycle. A connection that sends one successful request is only the beginning. A retailer also needs to know what happens when the customer asks for an invoice later, validation fails, or part of the purchase is returned.
Start with the taxable entity and the applicable implementation date
Malaysia introduced electronic invoicing in phases. The initial phases covered taxpayers with annual turnover or revenue above RM100 million from 1 August 2024, above RM25 million up to RM100 million from 1 January 2025, and above RM5 million up to RM25 million from 1 July 2025. Later phases, exemptions and transitional arrangements require a separate check against the current LHDN guidance.
A brand’s number of stores does not by itself determine the obligation. The assessment belongs to the taxpayer: its turnover or revenue, business commencement date and applicable exemption conditions, including relevant ownership or related-entity conditions. A small store network should not assume it is exempt.
Public summaries of the rules can reflect different revision dates. Before configuration, local finance should record the applicable rule, its effective date and the entity to which it applies. Thresholds, mandatory fields and effective dates should remain configurable wherever feasible, rather than becoming fixed assumptions in the POS.
Three retail scenarios need separate workflows
1. The customer requests an e-Invoice at checkout
The store collects the required buyer details and checks the available information before submission. The POS passes the transaction to the agreed integration service, which submits it to MyInvois. The validated document identifier and result must return to the transaction record. Staff need a clear way to see whether the invoice is still processing, has been validated or needs correction.
2. The customer does not request an individual e-Invoice
The store can issue its usual receipt. Where the transaction is eligible for consolidation under the applicable rules, it can enter the consolidated e-Invoice process. The retailer needs a mapping between the consolidated submission and the underlying receipts. If the buyer subsequently requests an individual invoice, the process must prevent the same sale from being counted twice and follow the applicable timing and consolidation rules.
3. The customer returns goods or the transaction is adjusted
A refund does not automatically cancel a validated e-Invoice. The required cancellation or adjustment depends on the document status, timing and business event. The return record needs to identify the original sale and invoice so that the appropriate correction document can be created and reconciled. The financial outcome and the tax-document outcome should both remain visible.
Test three layers of integration
Transaction data
The integration needs the required supplier, buyer and line-item data, quantities, prices, discounts, tax treatment and totals. A field mapping should explain which system owns each value and how validation errors are returned to an operator. Missing buyer details should not become an untraceable invoice failure.
Status and identifiers
Keep transaction completion separate from invoice processing. Useful distinctions include request created, sent, received by the provider, processing in MyInvois, validated, rejected and awaiting correction. The final statuses should follow the actual service interface rather than an assumed workflow.
Store the MyInvois document identifier, including the UUID where returned, against the original retail record. A timeout should trigger a status check or an idempotent retry using the agreed request identifier. It should not automatically create another invoice.
Exceptions and later events
Acceptance should cover delayed invoice requests, consolidation, full and partial returns, allowances, retries and failed corrections. Each exception needs an owner, a recovery action and a route back to the original sale. A successful checkout alone does not demonstrate that these processes work.
The integration path in PEKON’s ongoing Malaysia project
PEKON’s Malaysia project is still in progress. The connection path has been tested; this should not be described as a completed nationwide or full-store rollout.
In the project, PEKON POS provides the sales, returns and adjustment records, retaining the original receipt and document references. EZInvois, the local service provider, forms and submits the relevant e-Invoice documents to MyInvois. Validation results and identifiers then return to the POS for operational follow-up and reconciliation.
This division lets the local provider handle the submission format and local interface requirements while the POS maintains reliable retail transaction records. A direct MyInvois connection is another possible architecture. The choice should depend on maintenance responsibility, local support, exception handling and the retailer’s existing systems—not only on whether an API connection is available.
Using a provider does not transfer every responsibility away from the retailer. Finance still needs to approve the tax interpretation and applicable rules; the integration teams must agree who corrects source data, investigates timeouts and updates configuration when requirements change.
Ask for a complete transaction demonstration
- Complete a store purchase and request an individual e-Invoice.
- Show the outgoing request and its link to the receipt.
- Follow the provider and MyInvois processing statuses.
- Retrieve the validated document identifier and show it on the POS-side record.
- Return all or part of the purchase.
- Retrieve the original sale and invoice and create the appropriate correction.
- Return the correction result to the POS and demonstrate how finance reconciles the full chain.
Repeat the relevant steps with a timeout, a rejected request and a duplicate delivery. The demonstration should establish whether staff can tell what happened without comparing disconnected screenshots or assuming that “sent” means “validated.”
Frequently asked questions
Do a few stores automatically qualify for an exemption?
No. Check the taxpayer’s circumstances against current LHDN requirements. Store count alone is not the eligibility test.
What happens when a customer does not ask for an invoice?
Use the applicable receipt and eligible consolidation workflow. Keep the underlying transaction mapping and check whether the transaction type may be consolidated.
Is a local provider mandatory?
The architecture may use a provider or a direct connection. Confirm who will maintain the interface, manage local changes and resolve operational exceptions.
Does a successful refund finish the invoice process?
No. The original invoice status determines the required cancellation or correction workflow. Track that outcome separately.
Does a successful submission mean the invoice is validated?
No. A provider acknowledgment and a MyInvois validation result are different events.
Who should own implementation?
Finance, store operations and IT need a shared scope. Finance approves tax rules; store operations defines workable customer and return processes; IT and the service provider implement and monitor the interfaces.
Official reference and implementation planning
Confirm the latest scope and dates with the LHDN e-Invoice implementation timeline and the LHDN e-Invoice Guideline. Project configuration should follow the rules applicable to the actual taxpayer.
For a new Malaysia store rollout, define the sale-to-invoice-to-return process before interface acceptance. That makes it possible to assign responsibilities while the design can still be changed.