WhatsApp us

Blog6 min read29 Oct 2026

Multi-currency operations across SG, HK, ID and MY

Set up agents for SGD, HKD, IDR and MYR: one base currency, original amounts stored, dated rates, per-country tax fields and human approval of money.

Multi-currency operations across SG, HK, ID and MY

By KYN AI Advisory Team — AI implementation specialists, Singapore

To run operations across Singapore, Hong Kong, Indonesia and Malaysia with agents, pick one reporting currency, store every transaction in its original currency with the rate and the date, and keep tax and compliance fields per country. Agents then convert, match and report from that record. They do not choose rates, post across entities or move money without a named person. This guide sets out the data model, the rate rules, the per-country differences and the controls, in the order you would build them.

What is the right base currency?

Choose the currency in which the group reports to its owners and lenders. For a Singapore-headquartered group that is usually SGD. Everything else is a transaction currency: HKD, IDR and MYR.

Two rules keep the numbers honest.

  1. Never overwrite the original amount. Store the amount, the currency, the rate used, the rate source and the date. The converted figure is derived.
  2. Never mix levels. A line stays in its transaction currency. Totals convert at one stated rate on one stated date.

If you keep only converted numbers, you cannot reproduce a figure later, and a reviewer will ask you to.

What does the transaction record need?

At minimum, per transaction:

| Field | Purpose | |---|---| | Entity | Which company in which country owns it | | Transaction currency and amount | The original figure, never changed | | Functional currency of the entity | The currency its books are kept in | | Rate, rate source, rate date | Makes the conversion reproducible | | Base currency amount | Derived, recalculated if a rate is corrected | | Tax code and country | Per-country rules, not a single global code | | Counterparty and document reference | For matching and audit | | Status | Drafted, approved, posted, matched |

An agent reads this record and writes only the fields its role allows. The conversion agent writes the rate and the derived amount. It does not write the tax code.

Which exchange rate should you use?

State the policy in writing and apply it the same way every time. Common choices:

  • Transaction date rate for each invoice and payment.
  • Month-end rate for revaluing open balances such as receivables and payables.
  • Average rate for converting a month's profit and loss when your policy allows it.

Pick a rate source per currency pair and stick with it: a central bank rate, your bank's rate or a data provider. The rate source is data, so store it. For IDR, the rate you actually received from your bank can differ from a published reference rate, so record which one you used.

We cover the SGD side of this, including how to record foreign-currency charges, in recording foreign currency expenses in Singapore. Your accountant sets the policy. The agent applies it.

How do the four countries differ?

Differences that affect the agent's design, not a full tax guide:

| Item | Singapore | Hong Kong | Indonesia | Malaysia | |---|---|---|---|---| | Currency | SGD | HKD | IDR | MYR | | Indirect tax | GST | None | VAT | SST | | Authority | IRAS | IRD | DJP | LHDN / Customs | | Invoice rules | Tax invoice particulars | Commercial invoice | Tax invoice with e-Faktur | MyInvois e-invoicing by phase | | Language of documents | English | English, Chinese | Bahasa Indonesia | Bahasa Malaysia, English |

Check each authority's current rules before you set tax codes: IRAS, Hong Kong IRD, Indonesia DJP and LHDN. Rates and deadlines change, so we state none here.

Design consequence: the tax code table has a country column and an effective date. One table, many rows, owned by a person in finance.

How do agents handle each task?

  1. Capture. An agent reads invoices and receipts from each entity's mailbox, extracts currency, amount and counterparty, and creates a draft record.
  2. Convert. It looks up the rate for the date and source in your policy and writes the derived amount.
  3. Match. It pairs bank lines to invoices. A payment in IDR against an SGD invoice differs by the rate and fees, so matching allows a stated tolerance and flags anything outside it. See bank reconciliation 101.
  4. Revalue. At month-end it computes unrealised differences on open balances and drafts the entry.
  5. Report. It produces a group view in base currency, with a drill-down to original amounts.

Everything that posts, pays or files waits for a named person.

How do you handle intercompany transactions?

Intercompany invoices produce the most confusion. A Singapore parent invoices a Malaysian subsidiary in MYR for a shared service. Each side must record the same event.

  • Give each intercompany transaction one reference shared by both entities.
  • Match the two sides in the group view and flag differences.
  • Eliminate the pair on consolidation.
  • Let a person decide transfer pricing and treatment. The agent flags and does not decide.

What controls should be in place?

  • Rate changes are logged. If someone corrects a rate, the derived amounts recalculate and the log records who changed it and why.
  • No agent moves money. Payments are prepared by the system and released by a named person in the bank's own interface.
  • Entity boundaries are enforced in the database. A Hong Kong user does not see Indonesian payroll. Row-level security does this, not the application's menu.
  • Closed periods are locked. After month-end close, edits need a person with the right to reopen.
  • Every action carries an actor. Agent or person.

What does it cost to run?

Conversion and matching are rule-based and need little model usage. The model work is reading documents and drafting. In KYN's live systems, narrow model tasks cost cents: about S$0.05 for a morning report and about S$0.03 for a benefits comparison. The larger cost is the build, and that depends on the number of entities, banks and document types. We quote it after the review.

Where KYN fits

KYN builds multi-entity finance systems in the client's own cloud account, with named accounts, row-level security between entities and a log of every action. For a manufacturer we consolidated eleven systems into three on one AWS account and reconciled a ledger of 3,309 rows with zero duplicates. See finance systems and infrastructure.

The first 14 days are a review of your stack and interviews with your team. A full build ships in under 90 days. The client owns the cloud account and, on full payment, the rights in the custom code and configuration.

Frequently asked questions

Should each country have its own ledger?

Usually yes, because each entity files in its own country and in its own functional currency. Link them through a group view in base currency and a shared intercompany reference.

Can an agent pick the exchange rate?

It can look up the rate your policy names. It should not choose the policy. A person sets the source and the date rule, and the agent applies them and logs the rate it used.

How do I handle IDR amounts with many zeros?

Store amounts as exact decimals or integers in the smallest unit, never as floating point numbers. Format for display by currency, and check totals to the last unit on every report.

Checked 30 October 2026.

Curious whether Marketing agents fits your business? Talk to KYN on WhatsApp — no forms, just a conversation.

Start Building →

Written 29 Oct 2026 · Checked 29 Oct 2026