The problem shows up the first time you sell outside your home currency
If you run a business that only ever charges in one currency, revenue reporting is simple: add up the numbers, done. The moment you take a payment in a second currency, that simplicity disappears. Now you’ve got dollars sitting next to euros sitting next to pounds, and “total revenue” stops being a real number until you decide how those get combined.
This isn’t a rare edge case anymore. A lot of small software products, content businesses, and online stores end up with customers in multiple countries within their first year, often because a payment processor defaults to charging in the customer’s local currency to reduce checkout friction. So the multi-currency problem tends to arrive earlier than people expect, and it arrives quietly. Nobody sends you a memo. You just look at a chart one day and the trend line does something odd, and it takes a while to realize the odd thing is an exchange rate, not your business.
Why you can’t just add the numbers together
Say you sold $10,000 worth of product in USD, and €3,000 worth in EUR, in the same month. You cannot add 10,000 and 3,000 and call it 13,000 of anything. A dollar and a euro aren’t the same unit, so adding them is like adding 10,000 miles to 3,000 kilometers and calling it 13,000 of something. You have to convert everything into one currency first, which means picking a base currency and an exchange rate.
That sounds like a small technical step. It isn’t, because the exchange rate you pick changes the answer, and it changes it in ways that have nothing to do with how your business is actually doing.
Three ways to pick a rate, and why they disagree
There isn’t one “correct” exchange rate for a given day. There are a few common choices, and they produce different totals:
Transaction-date spot rate. You convert each sale using the exchange rate at the moment it happened. This is the most accurate at the individual transaction level, but it means your monthly total is really the sum of dozens or hundreds of slightly different rates, which makes the total harder to reproduce later unless you stored the rate used for each transaction.
Period average rate. You take the average exchange rate over the reporting period (a week, a month) and apply that single rate to everything in that period. This is simpler and easier to explain, but it smooths over real swings, so a currency that moved a lot during the month gets flattened into one number that no individual transaction actually used.
Fixed rate you set yourself. Some businesses lock in a rate for a quarter or a year for planning purposes, then true it up later. This is common in budgeting, less common in day-to-day reporting, because it can drift a long way from reality if the currency moves a lot.
None of these is wrong. They’re different tools for different questions. The mistake is switching between them without noticing, because then your month-over-month comparison isn’t really comparing your business to itself. It’s comparing your business under one FX method to your business under a different FX method, and the difference between the two months might be entirely method, not performance.
MRR is where this bites hardest
Monthly recurring revenue is a snapshot: it’s supposed to represent the revenue currently on the books, not what happened during the month. That makes it especially sensitive to exchange rates, because unlike a one-time sale, a subscription keeps existing across many reporting periods, and each time you calculate MRR you’re re-converting that same subscription at whatever the current rate happens to be.
Here’s the concrete version. Say you have a customer paying £50 a month, and nothing about that customer changes for six months, no upgrade, no downgrade, same plan. If the pound weakens against your reporting currency over those six months, your MRR chart will show that customer’s contribution shrinking, month after month, even though the customer has done nothing differently. If you’re not tracking FX separately, that shrinkage looks exactly like the kind of soft churn you’d want to investigate, except there’s nothing to investigate. It’s currency movement, not customer behavior.
This matters because a lot of the decisions people make off MRR trends, whether to worry about retention, whether a pricing change is working, assume the change is coming from customers. If some of the change is coming from currency instead, and you can’t tell which part is which, you’ll end up chasing a problem that isn’t there, or missing one that is because it’s hidden behind a currency move going the other way.
Separate “what happened” from “what the exchange rate did”
The practical fix isn’t a fancier formula. It’s keeping two things visible instead of collapsing them into one number too early:
Store the transaction in its original currency, always. Don’t overwrite it with the converted amount. If you ever need to recompute using a different method, or explain a number to yourself six months later, you need the original figure and the rate that was used.
Report the converted total for your dashboards, but keep a separate line, even a rough one, for FX impact versus underlying change. This doesn’t need to be sophisticated. Even something as simple as recalculating last month’s revenue using this month’s exchange rates, and comparing that to the actual reported number, tells you how much of the month-over-month move was currency and how much was customers.
Be consistent about refunds. Decide whether a refund gets converted at the rate used for the original sale or at the rate on the day of the refund, and use the same rule every time. Mixing the two inside the same report will make your net revenue slightly wrong in ways that are hard to trace later.
This is a reporting choice, not an accounting one
It’s worth being clear about what this article is and isn’t. Deciding how to present multi-currency revenue for your own dashboards, so you can understand what’s actually going on in your business, is a reporting and analysis question. How your books, your realized and unrealized FX gains and losses, and your tax filings handle currency conversion is a separate matter with its own rules, and those rules vary by jurisdiction and by how your accounting software is set up. If you need your financial statements to be correct for tax or legal purposes, that’s a conversation for an accountant, not a blog post about metrics.
A rough checklist if you’re setting this up for the first time
Pick one base currency for your reporting and write down why you picked it, usually the currency most of your costs are in.
Pick one conversion method, transaction-date rate or period average, and use it consistently. Write it down somewhere you’ll actually look at again.
Keep the original currency and the rate used stored with every transaction, not just the converted total.
When a trend moves, especially in MRR, check how much of the move is FX before you draw a conclusion about customer behavior.
Treat any of this as a starting point you’ll revise, not a settled answer. Currency exposure changes as your customer mix changes, and a method that made sense when 90% of revenue was in one currency might not make sense once that’s down to 60%.
None of this makes the exchange rate noise disappear. It just keeps it from disguising itself as something it isn’t.
If you want more of this kind of plain walkthrough on the metrics and methods behind running a business on real numbers, you can find the rest of what we’ve covered on the home page.
Get new guides and videos first — join the Telegram channel.