System Integration Consultant, Singapore

Mapping a Singapore application landscape before connecting anything

The first deliverable is a map, not a connector. Singapore companies tend to accumulate cloud subscriptions team by team: marketing picks an email tool, sales a CRM, operations a logistics portal, HR a payroll product. Some of these are already linked through automations that an enthusiastic staff member set up on a personal login, which is a risk in itself.

I build an inventory that lists each application, the records it holds, the links that exist today and every manual export or upload. For each flow, I note what triggers it, how often it runs, who depends on it and what the team does when it breaks. From that comes a data flow diagram and a short ranking:

• flows that carry tax or payment risk, such as invoices, receipts and supplier payments
• flows that consume the most staff time each week or month
• flows that depend on one person's knowledge or account
• flows that can simply be retired

The inventory usually reveals features already paid for but never switched on, and it gives a realistic basis for estimating build effort before anyone commits budget. It also identifies where personal data moves between systems, which matters for PDPA purposes and for any subsidiary or customer that asks how their data is handled. The method follows my general system integration approach.

InvoiceNow: what the integration design has to cover

InvoiceNow is Singapore's network for exchanging invoices as structured data over Peppol, and the tax authority's plans give it a growing role in how GST-registered companies report invoice data. The scope and timing that apply to your business should be confirmed with your tax advisor, but the integration questions are similar either way.

The first decision is the access point. Some accounting and ERP products include one; others need a separate provider; some implementers bundle a third-party service. I compare the options on what each actually supports, who maintains the mapping when formats change and how errors are reported back to your users.

The design then covers both directions:

• Outbound: the customer's Peppol identifier and UEN held on the customer record, invoice and credit note fields mapped to the required format, and a visible status for each document sent.
• Inbound: supplier invoices arriving electronically, matched to purchase orders and receipts, and routed for approval rather than re-keyed.
• Exceptions: rejected or undeliverable documents, corrections, and customers or suppliers not yet on the network.

Where a group runs several entities, each one may need its own registration and identifier, so the design records which entity sends which documents. How GST applies to each transaction is for your advisor to decide. The interface simply needs to reproduce those decisions on every document without manual correction.

Banks, GIRO, PayNow and gateway settlements

Payments are where small integration errors become real money. On the outgoing side, I establish which methods your banks offer for your account type: GIRO payment files, bulk uploads to a corporate portal or API connections. Then I design where approvals sit, so automation does not bypass the authorization controls your finance director relies on.

Incoming money arrives through more channels than many ERPs expect. Customers may pay by PayNow, card, bank transfer or GIRO collection, often via a gateway that settles in batches after deducting fees. Matching those settlements to invoices needs a reference that survives from checkout or invoice to the bank statement, and rules for partial payments, overpayments and refunds.

For each bank and gateway, the specification covers the statement or settlement format, how often it is imported, the matching keys, how fees are booked and what goes to an exception list for a person to resolve. Payroll is handled similarly: the payroll product calculates salaries and CPF contributions, and what the ERP needs is a cost center level summary posting, not each employee's payslip, with the account mapping signed off by finance.

The outcome finance should expect is simple: bank and receivables positions that are current each morning without a spreadsheet in the middle.

Logistics providers, marketplaces and regional subsidiaries

Trading and e-commerce businesses in Singapore often hold stock with a third-party logistics provider, sometimes in more than one country. The integration has to agree item codes, units of measure, lot or expiry details where relevant, and when stock movements are confirmed. Without that agreement, the ERP and the warehouse disagree on stock, and sales promises what cannot be shipped.

Marketplaces add their own complexity. Orders from Shopee or Lazada arrive with platform vouchers, shipping subsidies and fees, and the payout that reaches your bank is net of all of them. I design the mapping so each settlement can be broken back into sales, discounts, fees and refunds, which lets your accountant review revenue and GST without unpicking reports by hand.

Regional subsidiaries raise a different question: does each entity move onto the group ERP, or keep its local accounting tool and send structured data to head office? When local tools stay, I specify a feed that maps each subsidiary's chart of accounts to the group structure, applies agreed exchange rates and tags intercompany balances, so consolidation stops depending on emailed trial balances. Deciding which entity owns a regional deal in the first place is a sales design question, which I handle as a CRM consultant for Singapore companies.

Who builds, who tests and who owns the integrations

I am clear about roles from the first week. My part is the integration design, master data ownership, interface specifications, the choice of method for each flow, review of the builder's approach and the test plan. The build is done by your implementer, your own developers or a freelance integration developer. Where a flow only needs a native connector or simple low-code automation, I can often configure it as part of the engagement.

Method choice depends on volume, timing and who will support the result. A connector included in your subscription is usually the cheapest to run if it covers your cases. An integration platform, for instance n8n, Make or Zoho Flow, earns its place when several systems exchange the same records, as long as a named person administers it and reads its failure log. Custom APIs suit high volumes or complex rules, but the code then needs a long-term owner.

Testing covers the normal case and the failures: duplicate submissions, rejected invoices, partial shipments, refunds, expired credentials and an unavailable endpoint. Before anything is accepted, the finance team ties out a set of real transactions between the connected systems. Each interface then gets alerts to a named person, a short runbook and a line in the support agreement saying who fixes it. Credentials belong to company accounts, not individual developers.

Work is remote. See my Singapore overview or the ERP consultant page for Singapore for other support.