System Integration Consultant, Malaysia

Which system issues the e-invoice?

The most important integration decision under MyInvois is often made by accident. A business with a POS in its outlets, an online store, a marketplace presence, a billing tool for service contracts and an accounting package can end up with several systems each trying to issue e-invoices, or with none of them sure it should.

I settle this explicitly, document by document. For each type of sale I record which system creates the invoice, which system submits it, where the validation result is stored and which system the accounts team treats as the record. Typical outcomes include:

• invoices to business customers issued and submitted from the ERP or accounting package
• retail sales summarized from the POS, with individual e-invoices issued when a buyer asks for one
• marketplace sales handled according to how the platform and your advisor treat them
• credit and debit notes always issued from the same system as the original invoice

The design also covers the master data that validation depends on: buyer identification, classification codes, units of measure and tax types, kept in one owning system and copied elsewhere. Which documents must be issued, and when, is for your tax agent to confirm against current guidance, since the rollout has been refined along the way. My task is to make sure each system knows its role. The broader method sits on my ERP integration page.

Direct API, intermediary or connector for MyInvois

There are several ways to get invoices from your systems into MyInvois, and the right one depends on volumes, the systems involved and who will support the result.

• Built-in support in your accounting package or ERP. Often the simplest, provided the version you run supports every document type you issue and reports errors clearly to users.
• An intermediary or connector service that takes data from one or more systems and handles submission. Useful when several systems issue documents or when the core system lacks native support, but it adds a subscription and a dependency.
• A direct API integration built by developers. Gives full control and suits high volumes or unusual flows, but the code, certificates and credentials then need a long-term owner.

For your actual document types, I test what each route really handles, how rejections and cancellations are handled, how credentials and certificates are managed, what happens when the platform is unavailable, and how quickly each provider adapts when specifications change. I ask vendors to demonstrate the difficult cases, not only a clean invoice.

Whatever the route, the integration must store the validation result against each source document, show users a readable status and keep failed submissions in a queue rather than losing them. The tax content of each document stays with your tax agent.

Banks, gateways and e-wallets: reconciling what actually arrives

Collections in Malaysia come through more channels than many ERPs were set up to handle: bank transfers, online banking payments, cards, e-wallets and, for some businesses, cash deposits at branches. Most electronic channels reach your bank through a gateway or acquirer that settles in batches, after deducting fees.

The integration design therefore focuses on matching. I specify the settlement and statement files to be imported, how often, and the reference that links each receipt to an invoice or order. Rules then cover the awkward cases: partial payments, one transfer paying several invoices, refunds, chargebacks and fees booked to the correct account.

On the payments side, I confirm which options your bank supports for your account type, whether bulk payment files, portal uploads or an API, and agree with your directors which approvals happen in the ERP and which in the bank's own portal, so an automated file never skips a sign-off they rely on.

Payroll follows a similar pattern. Your payroll provider or HR system calculates salaries, EPF, SOCSO and PCB, and the ERP receives a summarized journal by cost center and account, mapped once with finance and checked against the payroll report before posting. Employee personal data stays in the payroll system unless a flow genuinely needs it, which keeps PDPA exposure lower.

The result to aim for is a receivables ledger and bank position that are current every morning, with only genuine exceptions left for a person to resolve.

Marketplaces, POS and the accounting package you keep

Many Malaysian retailers and brands sell through outlets, their own online store and marketplaces such as Shopee and Lazada at the same time. Each channel reports sales differently, and marketplace payouts arrive net of vouchers, shipping subsidies, commissions and fees. The mapping I specify splits each payout into its parts, gross sales, platform discounts, commissions and refunds, so your accountant can check revenue and tax lines without rebuilding marketplace reports manually.

POS integration needs equal care. Outlets may lose connectivity, so the design states how sales are queued and sent when the connection returns, how stock is updated and how cash, card and e-wallet takings reconcile with bank deposits.

Not every business replaces its accounting package when it adds new systems. AutoCount and SQL Account often remain in place, sometimes for one entity, sometimes for the whole group. Where that happens, I specify which system owns customers, items, prices and the chart of accounts, how transactions move between them and how rejected entries are corrected. When the number of connections becomes hard to maintain, that is evidence for the ERP discussion rather than a reason for one more workaround.

If the commercial side also needs attention, such as how sales records capture buyer details before an order exists, see my CRM consultant page for Malaysia.

Who builds, tests and supports the integrations

My role in a Malaysian integration project is the design, master data rules, interface specifications, method selection, a critical read of how the builder intends to work, and the test plan. The connections themselves are built by your implementer, your developers, an intermediary's team or a freelance integration developer. Some flows need no code at all, only a native connector or a simple low-code automation, and those I can often configure during the engagement.

For flows that need a layer in between, a middleware tool like Make, n8n or Zoho Flow can be a practical choice, provided someone in the business owns the account and its error log. Custom API services suit high volumes but need an owner for the code and hosting.

Testing covers normal transactions and failures: a rejected e-invoice, a resubmission, a cancellation, a duplicate webhook, an outlet that comes back online after a day, an expired credential and a marketplace refund. Where a sandbox exists, testing starts there. Your accounts team then reconciles real samples, and your tax agent can review a set of submitted documents before full cutover.

Before handover, every interface has an alert recipient by name, a brief troubleshooting guide and a support clause that assigns responsibility for repairs. Work is remote and conducted in English. Integration usually sits inside a wider system decision, which my ERP consultant service in Malaysia addresses; the Malaysia hub lists everything else.