Reporting Revenue Across Multiple Currencies Without Breaking the Numbers

Multi-currency revenue reporting is one of those problems nobody budgets time for until the numbers stop adding up. You start selling in the UK and Europe, a few customers pay in Canadian or Australian dollars, your Stripe account settles everything in USD, your ad accounts bill in a different currency again, and one day the dashboard shows a month that was 20% better than the bank account says. Nobody did anything wrong. The tools just added pounds, euros and dollars together as if they were the same thing.

This post is a practical guide to reporting revenue across multiple currencies without breaking ROAS, LTV, refunds or the trust of whoever reads the report. It covers the common failure modes, which exchange rate to use and when, how to handle refunds and payment plans, and what to check in your stack.

How multi-currency reporting goes wrong

There are a handful of distinct failure modes, and most businesses hit more than one.

1. Adding raw amounts across currencies. The classic. A sale of 2,000 GBP and a sale of 2,000 USD get summed as 4,000. Most dashboards that pull “amount” from a payment processor and sum it do exactly this unless someone told them otherwise.

2. Mixing presentment and settlement currency. A customer in Germany pays 1,800 EUR. Your Stripe account settles in USD and receives, say, 1,950 USD after conversion. Some reports use the 1,800, some use the 1,950, and some pull one figure for revenue and the other for refunds.

3. Converting at today’s rate. Converting a sale from March at October’s exchange rate means last quarter’s revenue changes every time you open the dashboard. Historical reports should not move.

4. Comparing spend and revenue in different currencies. Your Meta account bills in GBP, revenue is reported in USD, and ROAS is computed by dividing one by the other with no conversion. The result is off by the exchange rate, roughly 25 to 35% for GBP and USD in recent years.

5. Sending the wrong currency to ad platforms. A purchase conversion sent to Meta as “value: 2000” with the wrong currency code, or with none, teaches value-based bidding that a sale was worth more or less than it was.

Pick one reporting currency and stick to it

Every multi-currency business needs a single reporting currency: the one all money values are shown in for comparison. Usually it’s the currency the business keeps its books in, or the one leadership thinks in. If you’re a UK company, it’s probably GBP even if most customers pay in USD.

The rules:

• All totals, averages and ratios are computed in the reporting currency. Revenue, cash collected, refunds, LTV, AOV, cost per acquisition, ROAS.
• Individual transactions can still show their original currency. On a sales list, show “1,800 EUR” with the converted amount alongside. People reconciling with a customer or the processor need the original.
• Ad spend is converted into the same reporting currency before you compute anything with it.

In Callix, the display currency is set under Settings → Account settings → Currency (USD, EUR, GBP, CAD or AUD), and every money value on the dashboard is shown in it. On the Sales list, the value column shows each amount in the payment’s own currency, with the customer’s currency underneath when it differs, so individual transactions stay recognizable while totals are comparable.

Which exchange rate to use

There are three reasonable choices, and the important thing is to choose one deliberately.

Rate approach	How it works	Good for	Watch out for
Daily rate on the transaction date	Each payment converted at that day’s rate	Marketing and revenue reporting; historical numbers stay fixed	Needs a rate source with history
Monthly average rate	All transactions in a month use one rate	Finance and management accounts	Can diverge from daily figures in volatile months
Actual settled amount	Use what the processor actually paid out in your currency	Cash reconciliation	Includes processor FX fees, so it’s lower than gross revenue; not available for every source

For marketing reporting, the daily rate on the date the payment was made is the right default. It’s what the sale was worth that day, it doesn’t move later, and it lines up with how ad platforms report daily spend. Use a reputable published reference rate (central bank reference rates such as the ECB’s are a common choice) rather than whatever rate a single processor applied with its fees baked in.

Finance may use a monthly average for its own books. That’s fine. Expect small differences between the marketing dashboard and the management accounts, and write down why, so nobody spends a week reconciling a 0.8% gap.

Converting through a base currency

When you have many currencies, a clean method is to convert every payment to one base currency at the rate on the day it was paid, store that, and then convert into whatever display currency the viewer chose. This keeps a single stored number per payment and means switching the display currency doesn’t require re-reading every transaction.

That’s what Callix does: revenue, cash collected, LTV, refunds and CRM totals convert every payment to US dollars at the rate on the day it was paid, then into your display currency. An account paid in more than one currency, or whose Stripe settles in a different currency from what customers pay, no longer sees those amounts added together as if they were one. Conversion values sent to ad platforms are converted the same way, so the value Meta or Google sees matches the dashboard.

Refunds, chargebacks and payment plans

Currency makes the awkward cases harder.

Refunds. A refund should reverse the original sale at the original sale’s converted amount, not at the rate on the refund date. Otherwise a customer who bought in March for 1,000 GBP and was refunded in September can leave a small residual profit or loss in your revenue purely from currency movement. Your bank account will show the actual difference; your marketing report shouldn’t pretend the campaign earned or lost it.

Chargebacks. Same principle. Tie the reversal to the original payment.

Payment plans. Each installment is its own payment on its own date, so each converts at its own day’s rate. A 12-month plan in EUR will produce slightly different USD amounts each month. That’s correct. If you report “contract value” up front, convert it once at the date of sale and note that collected cash will differ slightly.

Ad spend and ROAS across currencies

Ad accounts often bill in a different currency from your revenue, especially for agencies and international businesses running several accounts.

1. Convert spend at the daily rate too. Use the same rate source as revenue, so both sides of ROAS move together.
2. Don’t mix ad accounts in different currencies without conversion. A rollup that sums a GBP account and a USD account raw is wrong in the same way as summing raw revenue.
3. Check what the ad platform reports as conversion value. Meta and Google report purchase value in the ad account’s currency, converted from whatever currency you sent. If you sent values in the wrong currency, the platform’s reported ROAS will be off even if your own dashboard is right.

A worked example

Say a coaching business sells one program at three price points by region: $5,000 USD, 4,000 GBP and 4,600 EUR. In one month it closes 10 USD sales, 6 GBP sales and 4 EUR sales. It spends 30,000 GBP on Meta from a UK ad account.

Summing raw amounts gives 50,000 + 24,000 + 18,400 = 92,400 “money” and a ROAS of 3.08 if you divide by the 30,000 spend. Both numbers are meaningless.

Converting at illustrative rates of 1 GBP = 1.30 USD and 1 EUR = 1.10 USD gives revenue of 50,000 + 31,200 + 20,240 = $101,440. Spend is 30,000 × 1.30 = $39,000. ROAS is 2.60. Shown in GBP, the same figures are about 78,030 GBP of revenue on 30,000 GBP of spend, still 2.60. The ratio is the same in any currency once both sides are converted. That’s the test that tells you the math is right.

Sending conversion values to ad platforms

When you send purchase or qualified-lead conversions to Meta, Google Ads or other platforms with a value, send it with an explicit currency code and make sure the value matches that code. Two consistent approaches:

• Send the original amount with the original currency code. The platform converts it.
• Send everything in one currency. Simpler to audit, and avoids surprises if a payment’s currency is ever missing.

Either works if it’s consistent. What breaks value-based bidding is sending “4,000” with a USD code for a sale that was actually 4,000 GBP.

A checklist for your stack

Run through these once, then again whenever you add a payment processor or a new market:

1. Does each payment record store its original currency and amount? If a processor only gives you a number, you can’t fix anything downstream.
2. Do you know each processor’s settlement currency? Especially if you run more than one payment platform or more than one Stripe account.
3. Is there one reporting currency, set in every tool that shows totals?
4. Are conversions done at the transaction-date rate, from one rate source?
5. Do refunds reverse at the original amount?
6. Is ad spend converted before ROAS is computed?
7. Do conversion events carry the right currency code?
8. Does the dashboard total reconcile to finance within a known, explained tolerance?

Explaining it to leadership

Executives don’t want an FX lecture. Put one line in the report footer: “All amounts in GBP, converted at the daily reference rate on the date of each payment. Refunds reverse at the original amount. Finance figures use monthly average rates and may differ by up to about 1%.” That sentence prevents most of the questions. For how to build the rest of the report so it’s read, see building an attribution dashboard your CEO will actually read, and for keeping LTV honest across currencies, CAC and LTV explained.

The short version

Choose one reporting currency. Store every payment’s original amount and currency. Convert each payment at the rate on the day it was paid, using one reference source, and never re-convert history at today’s rate. Reverse refunds at the original amount. Convert ad spend the same way before calculating ROAS, and send ad platforms values with the right currency code. Do those things and your multi-currency numbers will add up, which is the minimum anyone should expect from a revenue report.