What multi-currency accounting actually has to handle

Why does a single monthly exchange rate break everything?

Because a rate set once a month is only correct on one day of that month. Every invoice, payment and receipt booked on the other days carries an error, and those errors do not cancel out. They build up in your receivables, your payables and your reported margin until somebody has to explain the difference.

The reason companies do it is understandable. Somebody has to type the rate in, so finance picks one on the first working day and uses it until the next month. Data entry stays simple and the month looks tidy. It also bakes a fixed error into every line booked after day one.

Say your books are kept in US dollars and you sell in euros. On 1 March you set the rate at 1.08 and leave it. You raise a EUR 200,000 invoice on 22 March, and by then the market rate is 1.12. Your system records USD 216,000 of revenue when the real value on the day was USD 224,000. That is USD 8,000 of understatement on one invoice, and nothing in the accounts flags it.

It gets worse when the same wrong rate is used on both sides of a deal. A purchase booked at the monthly rate and paid at the actual rate produces a difference that has to go somewhere. If the system has nowhere to put it, the difference usually becomes a manual journal written at month end that nobody can reconstruct a year later.

An average rate is a legitimate approximation for income and expenses when volumes are high and movement is small. It is an approximation, not a substitute for recording what actually happened, and it is never acceptable for the balances themselves.

Which rate applies at which moment?

Two rates do two different jobs. The transaction-date rate records what a sale or purchase was worth on the day it happened. The closing rate at period end restates any balance still outstanding in a foreign currency. Both are needed, and using one where the other belongs is the most common mistake in a first setup.

The rule underneath this is the split between monetary and non-monetary items, and it is worth learning properly because everything else follows from it. Monetary items are amounts of money you will receive or pay: cash, bank balances, receivables, payables, loans. They get restated at every period end because what you hold is a fixed number of foreign currency units whose value in your books keeps moving.

Non-monetary items are things you own rather than amounts you are owed. Fixed assets, inventory at cost, prepayments. These stay at the rate that applied on the day you bought them and are not touched again. An accountant who retranslates inventory at the closing rate has quietly created a revaluation the standards do not allow.

Revenue and expenses sit in between in practice. Each transaction is recorded at its own date rate, and once recorded it is history. The invoice does not change. The balance that invoice created does.

What is the difference between a realised and an unrealised gain?

A realised difference happens when money actually moves and the rate has changed since the invoice was raised. An unrealised difference is the paper effect of restating a balance you are still holding. Both go through your profit and loss, but only one of them is cash, and they belong in separate accounts.

Work through one purchase and the whole thing becomes clear. On 10 April you buy goods for EUR 50,000 when the rate is 1.08, so you record USD 54,000 of stock and USD 54,000 in payables. At 30 April the rate is 1.10. The payable is still open, so it is restated to USD 55,000 and you book an unrealised loss of USD 1,000. On 15 May you pay when the rate is 1.12, so USD 56,000 leaves the bank against a payable carried at USD 55,000, and a further USD 1,000 goes through as a realised loss.

Two things in that example are worth noticing. The total effect of the currency movement was USD 2,000, split across two periods, which is correct: part of it belonged to April. And the stock stayed at USD 54,000 throughout, because inventory is non-monetary and is not restated no matter what the rate does afterwards.

Keeping the two in separate accounts is not bookkeeping fussiness. A general manager reading the profit and loss needs to know whether an exchange loss is a real cash outcome from a payment made or an accounting restatement that may reverse next month. If both sit in one account called FX difference, that question cannot be answered without going back through the ledger line by line.

Unrealised amounts do reverse. A loss booked at 31 December on an open supplier balance is not a loss you suffered. It is a statement of what that balance was worth on that date. If the rate moves back before you pay, the next restatement takes it the other way, and the only number that ever settles is the one at payment.

How should you hold bank accounts and customer balances?

Each currency needs its own balance in its own units. A euro bank account should show a euro figure with a translated value beside it, not one blended number. Customer balances work the same way. If you invoice a customer in two currencies, that customer has two balances, not one converted total.

The mistake to avoid is converting on the way in. When a system stores only the translated amount and discards the original currency and amount, you lose the ability to answer the question that matters most: how much does this customer actually owe us, in the currency they agreed to pay. You are left with a translated figure that was correct on one day.

This bites hardest in receivables. A customer who owes EUR 30,000 and USD 12,000 needs a statement showing both. Send a single converted total and they will dispute it, correctly, because their own books carry two numbers and neither one matches yours.

Bank reconciliation has the same requirement. You reconcile a euro account against a euro statement, line by line, in euros. The translated value is a reporting output, not the thing you tick off. Any system that forces your team to reconcile in the reporting currency will cost them hours every month and produce differences that are pure rounding.

Credit limits need a decision too. Settle whether a customer's limit is set in their trading currency or in your reporting currency, and check that the system enforces it the way you decided. A limit that drifts with the exchange rate will block a legitimate order one week and let through one it should have stopped the next.

• The original currency and amount

  Stored on the transaction itself, never only the converted figure.

• The rate used

  Held on the line, so the translation can be checked without guessing which rate was current.

• The date the rate came from

  Transaction date, not the date somebody keyed it in.

• Where the rate came from

  Manual entry, a bank feed or a published source. Auditors ask this early.

• A currency balance and a translated balance

  Both visible on every customer, supplier and bank account.

What happens to last year's figures when you compare them?

Comparatives are translated at the rates that applied back then, not at today's rate. So a column showing this year beside last year contains two different rate environments, and part of every movement is currency rather than trading. Unless somebody separates the two, the comparison is not saying what people assume.

The practical consequence is that growth can be a currency statement. If a meaningful share of your revenue is in another currency and that currency moved, some of your reported increase was not sold by anybody.

A quick illustration. Last year you sold EUR 1,000,000 at an average rate of 1.05, which is USD 1,050,000. This year you sold EUR 1,000,000 at an average of 1.15, which is USD 1,150,000. Reported growth is 9.5 percent. Volume growth is zero. Both numbers are true and only one of them should change how you plan next quarter.

The fix is to report the movement twice: once as reported, and once with the prior period recalculated at the current period's rates. The second view tells you whether the business actually grew. Large groups call it constant currency reporting and there is no reason a company with fifty staff cannot do the same thing.

Whether that is a report or a project depends entirely on what your system kept. If every transaction still carries its original currency amount, the second view is a filter someone runs in a minute. If only translated figures were stored, recalculating a prior year means rebuilding it by hand, which is why most companies do it once and never again.

Why do spreadsheets fail at this specifically?

A spreadsheet can convert. What it cannot do is remember. Multi-currency accounting needs every transaction to keep its original amount, its rate and its date so the balance can be restated later. Spreadsheets flatten all of that into one number, and once it is flattened the trail is gone.

Watch how it degrades over a year. Somebody builds a tab with a rate in a cell at the top. A second rate is needed for a different month, so the cell becomes a column. Then a formula points at the wrong row. Nobody notices, because a spreadsheet has nothing that reconciles a translated balance back to a currency balance and shouts when the two disagree.

Period-end revaluation is the part that breaks first. Doing it properly means walking every open receivable, payable and bank balance, restating each at the closing rate, and posting the difference to the right account. By hand that is most of a day and one wrong cell reference away from a wrong set of accounts, and it has to happen every single period, forever.

The quieter failure is worse. Because the manual process is painful, people start converting at entry and keeping only the translated number. The books look clean, month end gets faster, and the information needed to answer a customer query or restate a balance has been thrown away.

None of this says spreadsheets are bad. They are the wrong tool for a ledger that has to be restated on a schedule and defended afterwards.

What should you check in any system that claims multi-currency?

Ask to see a full cycle rather than a settings screen. Raise an invoice in a foreign currency, part-pay it at a different rate, run the period-end revaluation, and show me the journal the system posted by itself. Plenty of software supports the first step and quietly leaves the rest to a person.

Almost every accounting product has a currency field. The field is not the feature. What separates a real multi-currency ledger from a converted one is whether it can restate balances on demand, produce the journal, keep realised and unrealised apart, and still show you the original amounts afterwards.

One question is unusually revealing, so ask it in the demo: what happens if a rate is entered wrong and discovered three weeks later. A system with a proper rate table lets you correct the rate and reprocess the affected transactions. A system where the rate was typed onto each document individually means somebody now has to find them all.

• A rate table held by date

  Not one rate per month typed by hand. The system should pick the right rate for the document date on its own.

• Automatic period-end revaluation

  It should generate the journal, show you what it did, and let you reverse it.

• Realised and unrealised posted separately

  If both land in one account, somebody spends a day a month splitting them again.

• Balances viewable in their trading currency

  Customer, supplier and bank balances in the currency they were traded in, not only the reporting one.

• Partial payments across different rates

  Paying half an invoice in March and half in May is normal. Watch it happen before you buy.

• Reporting currency independent of trading currency

  Run the same report in either without re-entering anything.

• Non-monetary items left alone

  Check that inventory and fixed assets are not being retranslated at the closing rate.

Where does Wizard fit into this?

Wizard Cloud ERP handles currency in the core ledger rather than as a layer on top, which is why companies trading in several currencies daily look at it. If your currency work amounts to one foreign supplier a year, that is not a reason to change systems, and we would rather say so here than in a demo.

The honest boundary is group consolidation. If you have several legal entities in different countries with different functional currencies, an auditor expecting a specific platform, and a parent that dictates the chart of accounts, that is a different class of problem and a larger international platform is usually the right answer.

Where it does fit is a company holding balances in more than one currency, settling at rates that differ from the invoice, and wanting period end to be a review rather than a rebuild. If that describes you, the checklist in the section above is exactly what to put to us, using your own transactions rather than ours.