Multi-currency accounting without the spreadsheet

Multi-currency accounting is not conceptually hard. It is operationally unforgiving: every transaction needs the right rate on the right date, revaluation has to happen at the right points, and realised and unrealised differences have to land in the right places.

Get any of that slightly wrong and nothing obviously breaks. The books balance. There is simply a foreign exchange line nobody can explain, growing quietly.

The four places it goes wrong manually

The rate somebody used. A rate typed from memory, from a website at the wrong time of day, or carried over from last month. Each individually small; collectively a drift nobody can reconstruct because the source was never recorded.

The date of the rate. Invoice date, delivery date, payment date, period end — each has a defined use, and using the wrong one is easy and invisible. The entry still posts.

Missed revaluation. Open foreign currency balances need revaluing at period end. Skip it and the balance sheet carries positions at historical rates that have not been true for months.

Realised versus unrealised confusion. The difference on settlement is realised; the difference on an open balance is not. Mixing them makes the FX line meaningless as a measure of anything.

What automation actually fixes

Rates applied automatically from a recorded source. The material improvement is not accuracy — it is that the rate, its source and its date are recorded with the transaction. When someone asks in nine months why this invoice was translated at 4.71, there is an answer. Without that, foreign exchange differences are unauditable in practice, whatever the trail nominally says.

Consistent date rules. Configured once, applied identically. This removes the most common error entirely, because the decision is made in policy rather than repeatedly under time pressure.

Revaluation that runs. Every period, on every open balance, without depending on anyone remembering.

Correct split of realised and unrealised. Mechanical once the rules are right, and reliably wrong when done by hand across many transactions.

Settlement matching across currencies. A payment in USD settling invoices in USD, where your books are in MYR — matching on the foreign amount while accounting on the local. Straightforward in principle, tedious in practice, and where multi-currency reconciliation usually stalls.

Where the money actually hides

Two specifics worth checking in any business with foreign currency.

Bank charges buried in the received amount. You invoice USD 10,000, USD 9,972 arrives. The USD 28 is a correspondent bank charge, not a customer short payment. Coded as an exchange difference, it disappears into a line nobody examines; coded as a bank charge it appears where you can see what it costs annually. Small per transaction and material over a year.

Rate spread on conversion. The rate your bank gives you is not the rate you accounted at, and the difference is a real cost that should be visible rather than absorbed into FX gain or loss. Businesses that see this figure clearly often renegotiate; businesses that do not, do not know it exists.

What still needs judgement

Which rate policy to apply. Transaction-date rates, average rates for a period, or something else — an accounting policy decision, not a setting.

Hedging treatment. If you hedge, the accounting is genuinely complex and depends on documentation. Not an automation candidate.

Functional currency determination. Which currency the business actually operates in is a judgement with consequences throughout the accounts.

Whether the FX result is telling you something. A growing loss might mean the exposure needs managing commercially rather than accounted for more precisely. That is a business conversation.

The test of whether it is under control

One question: can you explain the foreign exchange line in your P&L, broken into realised and unrealised, and say which transactions produced the largest components?

If yes, the mechanics are working. If it is a residual figure that arrives at the end of the close and nobody examines, it is absorbing errors — and by the time it is large enough to prompt questions, reconstructing what happened across a year of transactions is a substantial piece of work.

For a store selling across a border, the first thing to establish is where the rate is actually applied, because that decides who absorbs the spread — see currency conversion at checkout and who pays for it and selling in more than one currency.

Common questions

What does AI fix in multi-currency accounting?

Mainly consistency and traceability. Rates are applied automatically from a recorded source with the source and date stored against the transaction, date rules are configured once rather than decided repeatedly, revaluation runs every period without depending on memory, and realised and unrealised differences are split mechanically. The traceability matters most, because foreign exchange differences are only auditable if the rate used and its source were recorded at the time.

Why is my foreign exchange gain or loss unexplainable?

Usually because it is acting as a residual that absorbs several unrelated errors — rates applied at the wrong date, missed revaluations, bank charges miscoded as exchange differences, and confusion between realised and unrealised amounts. Each is individually small and none breaks the ledger, so the line grows without anything obviously going wrong until it is large enough to prompt questions.

What is commonly miscoded in foreign currency transactions?

Correspondent bank charges deducted from an incoming payment. When USD 9,972 arrives against a USD 10,000 invoice, the shortfall is a bank charge rather than an exchange difference or a customer short payment, and coding it as FX hides an annual cost that is material in aggregate while being trivial per transaction.

What multi-currency decisions cannot be automated?

The rate policy itself, hedge accounting treatment, and functional currency determination are all accounting judgements rather than settings. So is the commercial question of whether a growing exchange loss indicates an exposure that should be managed rather than simply accounted for more accurately.

Related: importing and foreign currency · ai accounting when you sell in two countries · automating bank reconciliation with AI