Multi-Currency Financial Modelling: Convert Once, and Never in the Forecast

If you are building in Southeast Asia you are almost certainly running at least three currencies. Salaries in ringgit or pesos. Some customers paying in USD and some locally. An investor who thinks in dollars and a next round that will be denominated in them.

Most advice on this tells you to maintain an operating currency, a revenue currency and a reporting currency. That is correct and it is not the hard part.

The hard part is deciding where the conversion happens, because that single decision determines whether you can ever tell business performance apart from exchange rate movement.

The mistake that makes a model useless

Here is the failure, and it is common enough that I would guess most SEA startup models have some version of it.

You build the model in USD because that is what your investor wants. Your costs are in ringgit, so you convert them at the rate you looked up on the day you built it. Six months later the ringgit has moved four percent, you update the rate, and your entire cost base shifts.

Now look at what you have. Your USD burn went up. Did you spend more, or did the currency move? The model cannot tell you, because both effects are baked into the same number at the same point.

Do that for four quarters and you have a model where every variance conversation starts with someone unpicking FX before anyone can discuss the business. In practice nobody unpicks it. They just stop trusting the variance.

Convert once, at the transaction, at a rate you keep

The correct place for conversion is the ledger, at the moment the transaction happens, at the rate that actually applied that day, with the original amount preserved.

That is how YourBooks is built. Every transaction carries four things rather than one: the currency it actually occurred in, the amount in that currency, the business base currency, and the converted base currency amount, alongside the exchange rate that was used. The rate lives in an exchange rate table rather than being hardcoded into an amount.

This matters because it is not destructive. A supplier invoice paid in USD against a ringgit-based business is stored as a USD amount and a ringgit amount and the rate between them. You can always answer both questions: what did we actually pay, and what did it cost us in the currency we run in.

Bank reconciliation carries the same idea further. When the bank statement is in one currency and the book entry is in another, the match records the bank currency, the book currency, the rate used and the converted amount, so a reconciliation across currencies does not silently absorb an FX difference into a rounding variance.

The rule underneath all of it: never overwrite the original number. A converted amount without its source and its rate is a number nobody can audit six months later.

The forecast does not convert, on purpose

This is the part that surprises people, so it is worth being direct.

YourCFO has no FX conversion in it at all. There is no exchange rate anywhere in the forecasting engine. Your organisation sets one base currency and every amount in the product renders in that currency's symbol. That is formatting, not conversion. The numbers themselves are whatever you modelled.

That is a deliberate design decision, not a missing feature.

A forecast is an argument about what you will do. If you hire two engineers in March, that costs a specific amount of ringgit, and it costs that amount regardless of where the dollar sits. Introducing an exchange rate into a forward projection means every scenario you run is also a currency bet, and the two get tangled in exactly the place where you most need clarity.

So: model in the currency you spend in. One currency, throughout. The conversion already happened in the ledger, on real transactions, at real rates. The forecast has no business doing it again.

Then where does USD come in

Two places, and both are deliberately separate from the model.

Investor surfaces are USD. Cap table, fundraising, investor reporting. These render in dollars regardless of your operating currency, because that is the currency the audience thinks in and mixing it with your operating view would confuse both.

Shared snapshots keep their own currency. When you share a forecast by link, the page formats using the currency stored in that snapshot rather than the viewer's. A signed-in viewer from another organisation does not get their own currency applied to somebody else's numbers. That sounds like a small detail. It is the difference between a shared model that means something and one that quietly relabels every figure with the wrong symbol.

Group consolidation, if you have entities. A business group carries its own reporting currency separately from each entity's base currency, so consolidation converts at the group layer rather than distorting the underlying books. Most early-stage companies do not need this. If you have two entities in two countries, you eventually will.

What this means for how you work

Practical version, whatever tools you use.

Record the transaction currency. Every time. If your bookkeeping collapses a USD invoice into a ringgit amount and throws the USD away, you have destroyed information you will want.

Store the rate you used, next to the amount. Not in a separate file. On the row.

Pick one currency for the forecast and stay in it. The one you actually spend in, which for most SEA companies is local, not USD.

Convert for the audience, at the edge. When an investor needs dollars, convert the output at a stated rate on a separate view. Do not convert the model.

State your FX methodology once and keep it. Whether you use a period-end rate or an average, say which and do not change it midway. Changing methodology between reporting periods makes every comparison meaningless and it is very hard to unwind later.

The test

Here is how you know your setup is right.

Someone asks why burn was higher last quarter. If you can answer that question without anyone opening a currency conversion, your architecture is correct.

If the answer starts with "well, part of that is FX", the conversion is happening in the wrong place.

See how the books feed the forecast