Multi-Currency Accounting in an Estonian OÜ: FX Rates, Wise Balances and the Numbers That Never Match
You invoice a client in US dollars, pay a supplier in British pounds, hold a slice of your treasury in Swedish kronor because a partner insisted, and your Estonian OÜ’s accounting report still shows numbers that match none of your Wise, Payoneer or Revolut Business balances on the day you check them. You are not bad at maths. The books are kept in euros by law, every currency gets converted at a specific rate on a specific date, and your live app balance is a snapshot of a moving target — so the mismatch is not a bug, it is how the system is designed to work.
The short answer
An Estonian OÜ’s accounting records must be kept in euros, regardless of how many currencies you invoice, pay, or hold in.
Each foreign-currency transaction is converted to euros using the European Central Bank reference rate (published via Eesti Pank) for the date the transaction occurs — not the rate your bank or EMI happened to apply that day.
An unpaid invoice creates an unrealised exchange difference at period end; a paid invoice creates a realised one when the payment lands — these are two different numbers, both correct, for two different purposes.
VAT on a foreign-currency invoice is converted at the rate on the date the tax point arises (issue of invoice or receipt of payment, per the transaction), and the VAT return (KMD) is filed in euros only.
Your EMI balance (Wise, Payoneer, Revolut Business) reflects today’s live rate; your accounting report reflects historical rates on past dates — comparing them directly is comparing two different things.
Platform payouts, card spending abroad and crypto receipts each add their own conversion step on top of the basic rule, which is why they feel like a separate mess.
Why don’t the numbers ever match?
They don’t match because euros are the only currency your books recognise, and every foreign-currency amount passing through your OÜ gets frozen into euros at the exchange rate that applied on the specific day the relevant event happened. Your dollar invoice, your pound payment and your Swedish krona balance are each converted separately, on their own date, at their own rate. A week later, the market rate has moved, so the euro figure sitting in your accounting system no longer matches what that same foreign-currency amount would convert to today. Eesti Pank publishes the reference rates your books rely on.
This is not an Estonian quirk. Any company keeping euro-denominated statutory accounts works this way, because accounting needs a fixed, auditable number for each transaction, not one that keeps changing every time you refresh a converter. The euro figure in your ledger is a historical fact, frozen on the date it was recorded, while your EMI balance is a live fact, changing every minute markets are open.
What currency are your OÜ’s books actually kept in?
Your statutory accounting records are kept in euros, full stop, even if your company never touches a euro in day-to-day trading. This follows from Estonia being a euro-area country: the euro is the functional and reporting currency for Estonian accounting purposes, and the annual report you file each year (due within six months of financial year end, so 30 June for a calendar-year OÜ) is presented in euros. If every client pays you in dollars and every supplier invoices you in pounds, your books still show euro amounts for each of those entries.
Practically, this means your accounting software (or your accountant’s ledger) needs to store two things for every foreign-currency transaction: the original amount in the original currency, so you can trace it back to the invoice or payment, and the euro-equivalent amount at the rate that applied on the relevant date. Lose either half and reconciliation against your bank or EMI statement becomes guesswork.
Which exchange rate applies, and on what date?
The rate that applies depends on which event you are recording, not on when you happen to be looking at your dashboard. Estonian accounting practice, in line with standard EU-wide treatment, uses the European Central Bank’s daily reference rate, which Eesti Pank republishes on its currency-exchange page each business day. That rate — not your bank’s retail rate, not your EMI’s spread-adjusted rate — is the reference point for converting a foreign-currency transaction into euros for your books.
Event | Which rate applies | Which date |
|---|---|---|
Foreign-currency sales invoice issued | ECB reference rate | Date of issue (the tax point for VAT purposes) |
Foreign-currency purchase invoice received | ECB reference rate | Date of the invoice / the tax point |
Payment received from a customer | ECB reference rate | Date funds are received / settled |
Payment made to a supplier | ECB reference rate | Date the payment is made |
Open invoice or foreign-currency balance at period end | ECB reference rate on the closing date | Last day of the reporting period |
Currency with no ECB reference rate published | Last available rate, or another verifiable source your accountant documents | As close as possible to the transaction date — confirm the exact fallback with your accountant |
For currencies the ECB does not quote — some frontier or thinly-traded currencies fall into this category — there is no single universal rule, and this is genuinely a point where you should confirm the exact practice with your accountant rather than guess. The safe approach is to use the last rate the ECB did publish, or a documented rate from another reputable source, and to keep a written note of which source and date you used, so the choice is defensible if EMTA ever asks.
One practical trap: your EMI or bank statement shows the rate it actually charged you, which includes its own margin on top of the interbank rate. That is the rate that tells you what really landed in your account. The ECB reference rate is the rate your books use, and the two are almost never identical — which is one more reason your accounting euro figure and your EMI euro figure diverge even for the exact same transaction.
Realised versus unrealised exchange differences, in plain language
A realised exchange difference happens when money actually changes hands: you issue an invoice at one rate, get paid weeks later at a different rate, and the gap between the two euro amounts is a real gain or loss that hits your profit and loss statement. An unrealised exchange difference happens when nothing has been paid yet: at the end of a reporting period, any invoice still open in a foreign currency gets revalued at the closing-date rate, and the difference from its original euro value is booked as an unrealised gain or loss purely because the rate moved, not because anyone paid anything.
Realised difference = triggered by an actual payment or receipt; reflects money that has genuinely moved.
Unrealised difference = triggered by the calendar (period end); reflects a paper revaluation of something still outstanding.
Both appear in your accounts, but only the realised figure corresponds to cash that has actually arrived or left.
An unrealised gain or loss can reverse or grow before the invoice is actually settled — it is a snapshot, not a final number.
This distinction is exactly why a founder staring at a P&L line called “exchange rate differences” feels confused: part of that number is real cash impact from settled invoices, and part of it is a valuation adjustment on invoices nobody has paid yet. Your accountant should be able to split the two on request, and a well-kept ledger keeps them on separate lines from the start.
A worked example: one invoice, from issue to payment to year-end
Take a concrete case: your OÜ issues a $10,000 invoice to a US client on 15 November, the client pays in full on 20 December, and your financial year closes on 31 December. Three different euro figures appear across the life of this single invoice, and all three are correct for what they measure.
Date | Event | Illustrative EUR/USD rate | Euro amount recorded | What it represents |
|---|---|---|---|---|
15 Nov | Invoice issued for $10,000 | 1.06 | €9,434 | Revenue recognised in the books at the issue-date rate |
31 Dec (if unpaid at this point) | Period-end revaluation of the open invoice | 1.09 | €9,174 | Unrealised loss of €260 booked purely because the rate moved |
20 Dec | Client pays $10,000 in full | 1.08 | €9,259 | Realised loss of €175 versus the original €9,434 booked at issue |
Note the sequence matters: because the client paid on 20 December, before the year closes, there is no unrealised revaluation for this particular invoice — the middle row only applies if the invoice were still open on 31 December. What actually lands in your books is revenue of €9,434 on 15 November and a realised exchange loss of €175 recognised when the €9,259 payment arrives on 20 December. If the client had instead paid in January, you would see an unrealised loss booked at year end, followed by a realised figure (which could differ again) once the cash actually arrives the following year.
The invoice, the payment, and the balance sitting in your EMI account are three different snapshots of the same $10,000 — each one true, each one taken on a different day, at a different rate.
Why the balance in your EMI app never matches the balance in your accounts
Your Wise, Payoneer or Revolut Business dashboard shows you a live balance at today’s rate, updated continuously. Your accounting report shows you cumulative euro amounts recorded at the historical rate on each transaction’s own date. Even if every single transaction was recorded correctly, these two numbers describe different things: one is what this foreign currency is worth right now, the other is the sum of what each individual euro-equivalent was worth on the day it happened.
This gap gets wider the more currencies you hold and the more volatile the pair. A founder holding euros, dollars, pounds and kronor simultaneously in one EMI, each moving against the euro independently, will see the total live balance swing day to day for reasons that have nothing to do with new sales or expenses — pure currency movement on money already sitting there. None of that movement gets recorded in your books until you actually convert or spend it, or until period end forces a revaluation, which is exactly why the two figures live on separate tracks.
Your EMI balance answers: “what could I withdraw or spend right now, converted at today’s market rate?”
Your accounting report answers: “what has my company legally earned, spent and owes, expressed in euros at the rates that applied when each event happened?”
Neither is wrong. They answer different questions, and a founder who expects them to reconcile line-for-line will keep being confused.
VAT on foreign-currency invoices: which rate for the return
If your OÜ is VAT-registered — mandatory once turnover in Estonia passes €40,000 in a year, voluntary below it — a foreign-currency invoice still needs a euro VAT amount, because the VAT return (KMD) is filed in euros only, monthly, due by the 20th of the following month. The euro value of the VAT charged is calculated by converting the invoice at the applicable exchange rate on the date the tax point arises, following the same ECB-reference-rate logic used for the rest of your accounting.
In practice this means the invoice itself can show the price and VAT amount in dollars or pounds for the client’s convenience, but somewhere in your records — usually your accounting software — the same VAT figure must also exist in euros, calculated at the rate for the relevant date, ready to be summed into your KMD. Because the exact fallback treatment for edge cases (invoices spanning a rate change, credit notes issued much later) is a place where practice can vary and the EMTA (1) rules interact with general accounting rules, confirm the specific handling with your accountant before you rely on it for anything unusual.
(1) EMTA is the Estonian Tax and Customs Board, at emta.ee.
The platform-payout problem: three amounts, three dates
If you sell through a marketplace or platform — an app store, a payments aggregator, an e-commerce platform — the FX headache multiplies because a single sale generates three different amounts on three different dates: the gross sale price the customer paid, the platform’s fee deducted before payout, and the net payout that actually lands in your EMI or bank account, often days or weeks later and often after the platform’s own currency conversion.
The gross sale happens on the date the customer buys, in whatever currency the platform sold in — this is usually the revenue recognition point.
The platform fee is deducted at the platform’s own rate and timing, and needs to be recorded as an expense, not just netted invisibly against revenue.
The payout arrives later, often batched with dozens of other sales, converted at the platform’s own rate on the payout date — which is neither the sale date nor a rate you controlled.
The clean way to handle this is to record the gross sale and the fee separately, at the rates and dates each actually occurred, rather than only booking the net payout you see land in your account. Booking only the payout understates your revenue and hides the fee as an expense, which distorts both your management numbers and, potentially, your VAT position if the platform relationship has VAT implications for your business model. This is one of the most common sources of unexplained variance a bookkeeper finds in an e-commerce or SaaS OÜ’s accounts.
Card spending abroad: whose rate is it anyway?
When you pay a supplier or a subscription with a company card in a foreign currency, the rate applied is your card provider’s own conversion rate at the moment of the transaction, not the ECB reference rate — and card providers routinely add a margin on top of the interbank rate, sometimes disclosed as a percentage, sometimes simply baked into the number you see on the statement. For your books, the euro amount that actually left your account (as shown on your card or EMI statement) is the figure to record as the expense, because that is the real cost to the company.
Where this gets messy is when the same expense also needs a separate ECB-rate conversion for a different purpose, for example reconciling against a foreign-currency invoice from the same supplier. The two euro figures rarely match exactly, and that small gap is itself another minor exchange difference — usually immaterial, but worth understanding rather than assuming it is an error.
Crypto and stablecoin receipts: know what you don’t know
If your OÜ receives payment in crypto or a stablecoin, treat it as its own valuation and record-keeping problem, separate from ordinary foreign-currency FX. Unlike a bank-settled dollar or pound, there is no single official reference rate, the receipt needs a documented valuation at the time it happened, and the ongoing treatment (does holding it create further gains or losses, how is it valued at period end, what happens on conversion to euros) touches accounting questions that are genuinely unsettled or fast-moving in many jurisdictions, Estonia included.
This is one area where a short, honest answer is the right one: get specific advice before you rely on crypto or stablecoin income being handled the same way as a dollar invoice, because it usually isn’t, and the gap between close enough and correct here can be a genuine compliance risk rather than a cosmetic mismatch.
A monthly routine that keeps multi-currency books clean
None of the mismatches above are a sign something is broken. What causes real problems is letting reconciliation slide for months, so unresolved rate differences pile up and nobody can tell which ones are genuine errors and which are just normal FX noise. A short, repeatable monthly routine avoids that.
Export a statement from every currency balance you hold (each EMI, each currency pocket) at the same point each month, so you have a consistent snapshot to reconcile against.
Match each invoice and payment to its recorded euro amount, checking the rate and date used against the ECB reference rate for that day.
Flag any open (unpaid) foreign-currency invoices approaching period end so your accountant can revalue them correctly rather than discovering them late.
Keep platform payouts split into gross sale, fee, and payout, never booked as a single net number.
Review card-statement conversions against invoice amounts for recurring foreign-currency expenses, so a real overcharge doesn’t hide inside normal FX variance.
Ask your accountant to show you the realised-versus-unrealised split on your P&L at least once a quarter, so you understand which part of any exchange gain or loss is cash and which is a paper adjustment.
Do this monthly, and the gap between your EMI dashboards and your accounting report stops feeling like a mystery. It becomes what it actually is: a set of numbers, each correct, each answering a slightly different question, reconciled on a schedule instead of discovered in a panic before your annual report is due.
Frequently asked questions
Does an Estonian OÜ have to keep its accounts in euros?
Yes. An Estonian company’s statutory accounting records and annual report are kept and presented in euros, regardless of how many other currencies it invoices, pays suppliers in, or holds balances in. Foreign-currency transactions are converted to euros for the books; the original currency amount is also retained for traceability.
Which exchange rate should I use to convert a foreign-currency invoice?
The standard reference point is the European Central Bank’s daily reference rate, republished by Eesti Pank, applied on the date the relevant event occurs — invoice issue, payment, or period end, depending on what you are recording. This differs from the retail or spread-adjusted rate your bank or EMI actually applies to a real transfer.
What if the ECB doesn’t publish a rate for a currency I use?
There is no single universal fallback; the practical approach is to use the last available rate or another verifiable, documented source, and keep a record of exactly which source and date you used. Confirm the specific fallback your accountant applies, since this is a case where practice can vary and guessing is not worth the risk.
What’s the difference between a realised and an unrealised exchange difference?
A realised difference comes from an actual payment or receipt settling at a different rate than when the invoice was issued — real cash impact. An unrealised difference comes from revaluing a still-open foreign-currency invoice at the closing rate on the last day of a reporting period — a paper adjustment on something nobody has paid yet.
Why doesn’t my Wise or Payoneer balance match my accounting report?
Your EMI balance shows a live value at today’s market rate; your accounting report shows historical euro amounts recorded at the rate that applied on each transaction’s own date. They measure different things by design, and the gap widens the more currencies you hold and the more those currencies move.
Which rate applies to VAT on a foreign-currency invoice?
The VAT amount is converted to euros at the applicable exchange rate for the date the tax point arises, using the same reference-rate logic as the rest of your accounting. The VAT return (KMD) itself is filed in euros only, monthly, by the 20th of the following month.
How should I record marketplace or platform payouts that arrive net of fees?
Record the gross sale and the platform fee separately, at the rate and date each occurred, rather than booking only the net payout you see land in your account. Booking only the net figure understates revenue, hides the fee as an expense, and makes reconciliation against the platform’s own reports much harder.
Does spending on a company card abroad use the ECB rate too?
No. A card transaction is recorded at the euro amount your card provider actually charged, which reflects its own conversion rate and margin, not the ECB reference rate. That real, out-of-pocket euro figure is the correct one for your expense records, even though it may differ slightly from an ECB-based conversion of the same invoice.
Is crypto or stablecoin income treated like any other foreign currency?
No, and you shouldn’t assume it is. Crypto and stablecoin receipts raise separate valuation and record-keeping questions without a single official reference rate, and the correct treatment is genuinely unsettled or fast-moving in places. Get specific advice from your accountant before relying on any assumption here.
