Insights · 11 min read
How to build multi-currency accounting software: the ledger model, FX rate handling, revaluation, consolidation, and the mistakes that break the books.
By GGP Editorial
If you bill clients in US dollars, pay contractors in euros, and keep your books in a third currency, you already live the problem. Month-end turns into a multi-day exercise of re-keying invoices into a spreadsheet, guessing which exchange rate to apply, and sitting through a call with your accountant about whether a December invoice produced a gain or a loss. A multi-currency accounting platform exists to end that routine.
This guide walks through what such a product has to do, which features earn their keep, and the engineering calls that decide whether it produces correct books or quietly corrupts them. It is written for founders and product teams planning a build, not for developers looking for code.
The need is more common than people assume. A few profiles come up again and again.
An e-commerce seller accepting payments in several currencies through Stripe or PayPal. A SaaS company with one product priced in USD and customers in Europe and Australia. An agency that invoices clients in their local currency but pays a distributed team in three others. An importer or exporter whose supplier invoices arrive in one currency while sales leave in another. A holding company consolidating subsidiaries in different countries.
In every case the business records real transactions in more than one currency and then needs a single set of reports. Off-the-shelf tools often handle the first part and stumble on the second.
The phrase covers two different jobs, and most confusion comes from mixing them up.
The first job is recording. You need to log an invoice in euros and a payment in dollars and keep both tied to the same customer and the same contract. That is table stakes.
The second job is translation. Accounting standards require you to report in one currency, so balances held in other currencies must be converted at a defined rate. The difference between the rate at the time of the transaction and the rate at the reporting date has to land somewhere, and that somewhere is a gain or a loss. This is where the products get complicated.
Three currencies sit in any multi-currency system. The transaction currency is what the invoice or payment actually uses. The functional currency is the currency of the primary economic environment the entity operates in, the one it keeps its books in. The presentation currency is what the final reports are shown in, which for a consolidated group may differ from each subsidiary's functional currency. IAS 21 and US GAAP (ASC 830) both govern this, and while the terminology differs slightly, the underlying model is the same.
The concept that matters most is the difference between realized and unrealized gain or loss. Say you invoice a customer for €10,000 when EUR/USD is 1.10. You record a receivable worth $11,000. The customer pays 60 days later when the rate is 1.06, so your bank receives $10,600. The $400 difference is a realized loss, and it is real cash gone.
Now imagine the customer has not paid yet and the rate is 1.06 at month-end. You still hold a €10,000 receivable, but it is only worth $10,600 on paper. That $400 is an unrealized loss. It exists in the reports even though no cash moved. A correct multi-currency system tracks both, reports them separately, and reverses the unrealized piece when the payment eventually clears.
These products accumulate scope that buyers never use. The features that decide whether the books are right form a smaller set.
| Feature | Why it matters | What to watch |
|---|---|---|
| Multi-currency ledger | Every entry carries a transaction currency and a base currency amount | Decide early whether the ledger is single-base-currency or truly multi-currency |
| FX rate management | Holds spot, historical, and user-defined rates | You need a rule for which rate applies to which transaction date |
| Dual-currency entry | Invoice and payment each record their own currency plus the converted value | The converted value must be stored, not computed on the fly |
| Revaluation | Reprices open foreign-currency balances at a cutoff date | Runs once per period and must be idempotent and reversible |
| Realized vs unrealized gain/loss | Separates cash losses from paper losses | Most reporting errors trace back to getting this wrong |
| Multi-entity consolidation | Combines subsidiaries and translates to presentation currency | Requires an elimination step for intercompany balances |
| Audit trail | Every posted entry is immutable and attributed | After posting, edits should create reversing entries rather than overwrite |
| Bank and payment integration | Pulls real settlements and their actual rates | Reconcile the payment's rate against your book rate |
Rates are a data problem as much as a software problem. You need three kinds.
Spot rates for current transactions, pulled from a provider. Historical rates for translating balances as of a past date, which most providers also offer. Manual rates for cases where the business used a specific rate on a contract or a customs declaration and needs the books to match it.
The tricky part is not fetching a rate. It is deciding which rate is authoritative for which transaction, then never silently changing it. A transaction posted in March keeps the March rate forever. If you recalculate everything against the latest rate each time a report runs, your historical numbers drift and an auditor will notice.
Most teams integrate one or two rate providers, store the daily rate series locally, and let finance override a specific rate with a note. Storing the series matters because reporting has to be reproducible: the same period end, run twice, should produce the same numbers.
A few decisions at the start have outsized consequences later.
The first is numeric precision. Never store currency amounts in floating point. IEEE 754 doubles turn 0.10 plus 0.20 into 0.30000000000000004, and over thousands of transactions the books will not tie out. Store amounts as integers in minor units, or as a decimal type end to end.
The second is whether the ledger is single-base-currency or truly multi-currency. The simple approach keeps one base currency, converts everything into it at entry time, and stores the converted amount. It is easier to build and covers most single-entity businesses. A true multi-currency ledger keeps the transaction currency amount as the source of truth and derives the base currency value. The second is more work but is what you want for consolidation and for reporting in more than one presentation currency.
The third is the entry model. This should be double-entry from day one. Single-entry accounting for a multi-currency product is a decision you regret the first time you need to prove a balance sheet balances.
The fourth is how revaluation runs work. A revaluation job picks up every open foreign-currency balance, reprices it at the cutoff rate, and writes the difference as an unrealized gain or loss. It has to be idempotent, so running it twice cannot double the effect, and reversible, so a wrong cutoff rate can be corrected. The clean way is to post a distinct revaluation journal entry that is automatically reversed at the start of the next period.
The failures are consistent enough to list plainly.
The first mistake is treating every currency like the base currency with a label. The system records €10,000, stores 10,000 with a EUR flag, then adds it to USD balances. Arithmetic across currencies without conversion is how totals become nonsense.
The second is ignoring unrealized gains and losses. Founders often build the transaction recording and skip the revaluation pass. The product looks fine for the first few months, then the first month-end close arrives and the foreign-currency receivables are wrong on the balance sheet.
The third is treating consolidation as an afterthought. Multi-entity reporting is not a report you bolt on at the end. Intercompany elimination rules affect the data model from the start. If you do not track which entity a balance belongs to and which entities it sits between, you cannot eliminate anything.
The fourth is overbuilding the rate engine on day one. You do not need exotic option pricing or forward curves for a first version. Spot, historical, and manual rates cover most businesses. Build the override path early instead.
The fifth is storing only the converted amount and losing the original. When you revalue later, you need the original transaction currency amount and its original rate to compute the gain correctly. If you only kept the converted number, you threw away the information the feature depends on.
For a business that just needs multi-currency books, buying an existing tool is usually the right move. Modern accounting products from established vendors handle multi-currency reasonably well, and integrating one is far cheaper than a build. We covered this trade-off in more detail in our guide on accounting software: build, buy, or extend.
A build makes sense when the multi-currency ledger has to sit inside a larger product you own, when you are selling the accounting capability to your own customers, or when your consolidation and reporting rules are specific enough that no off-the-shelf tool fits. The test I would apply is simple: is the multi-currency accounting your product, or a chore inside your product? If it is a chore, buy. If it is the product, build.
A first version is a multi-month effort, not a weekend project. You need a data model for the ledger, an FX rate store, the revaluation and consolidation logic, an audit trail, reporting, and integrations for at least one bank feed or payment provider. The cost is driven less by the UI and more by the correctness of the accounting logic, which is exactly the part that is expensive to get wrong and hard to verify without a domain-savvy reviewer.
If you want to understand what a custom build costs and where the money goes, we have written about that separately in our custom software development cost breakdown. The short version is that accounting logic rewards a team that has built financial systems before, because the bugs do not show up in demos. They show up at the first close, when a number refuses to tie.
What is the difference between multi-currency and multi-entity accounting?
Multi-currency handles transactions in more than one currency within a single set of books. Multi-entity handles more than one legal entity, each potentially with its own functional currency, that roll up into consolidated reports. They overlap but are separate concerns.
Do I need to follow IAS 21 or ASC 830?
That depends on your reporting jurisdiction and auditor, not on the software. The software should store enough information (transaction currency amount, rate, date, functional currency) that you can comply with either. Design the data model to record those fields, and the accounting standard is satisfied by configuration rather than by hard-coding rules.
What exchange rate should I use for a transaction?
In practice, the rate on the transaction date, or a documented override for contracts, customs, or tax filings. The important part is that the rate is stored and never silently recalculated.
How hard is it to add multi-currency to an existing accounting product?
Retro-fitting is significantly harder than building it in from the start, because a single-currency ledger usually discarded the fields the multi-currency logic needs. Most teams rebuild the ledger rather than bolt on.
Is FX gain or loss a profit or a tax event?
That is a question for your accountant in your jurisdiction. The software's job is to compute and classify the amounts correctly and report them separately, so the accountant can treat them.
Building a multi-currency accounting platform is the kind of project where the first 90 percent is straightforward and the last 10 percent is real, careful work. GlobeSoft has delivered financial management systems and multi-market trading platforms that handle several currencies and multiple entities, so we are comfortable with the part that trips most teams up: the correctness of the books. If you are planning a build, talk to us about your project and we will help you scope the ledger model, the FX handling, and a realistic timeline before you write a line of code.
Tell us what you are building and where you are today. We typically reply within 24 hours.
