Constant currency in FP&A: how to separate FX from real performance

To separate FX from real performance in a multi-currency business, restate actuals and budget at the same exchange rate (constant currency) and report the FX effect as its own variance line, so a currency move never reads as a cost overrun or a sales miss. In practice that means keeping every entity's numbers in local currency, converting actuals twice (at the actual rate and at the budget rate), and splitting each variance into volume, price and FX.

It sounds like a reporting detail. It isn't. When the euro drops 5% against the dollar, a European subsidiary that hit every local target shows up in the group P&L as a 5% revenue miss, and a London team that hired exactly to plan looks over budget when sterling strengthens. Without a constant-currency view, the board spends the meeting on numbers nobody in the business could have changed.

Bottom line: Lock a budget rate for each currency when the budget is approved, convert actuals at both the budget rate and the actual rate, and show the difference as a separate FX line. Performance is judged at constant currency; FX is reported, explained and, if you hedge, shown next to the hedge result.

What is constant currency?

Constant currency is a way of presenting results as if exchange rates hadn't moved between the periods you're comparing. You take the current period's local-currency amounts and convert them at a fixed rate, usually the budget rate or the prior-year rate, instead of the rate that actually applied. What's left in the comparison is volume and price; the currency effect sits in its own line.

Public companies use the same idea in their earnings releases ("revenue up 6% in constant currency"). The SEC staff treats that presentation as a non-GAAP measure, and its non-GAAP compliance and disclosure interpretations (Question 104.06) say a company can meet the reconciliation requirement by showing the historical amounts next to the constant-currency amounts and describing how it calculated them. Internal management reporting isn't bound by that rule, but it's a good standard to borrow: always show reported and constant-currency numbers side by side, and say which rate you used.

Which exchange rate should you use?

Use the budget rate for budget vs actuals and the prior-year rate for year-over-year growth. Each rate answers a different question, so pick it by the comparison you're making:

• Budget rate. Every currency gets a rate when the budget is approved, and the rate stays fixed for the year. Converting actuals at the budget rate gives you a like-for-like budget vs actuals, and the gap between actuals at the actual rate and at the budget rate is the FX variance.
• Prior-year rate. Converting this year's local-currency results at last year's average rates gives constant-currency growth. This is what most public companies report and what investors usually ask for.
• Current or forecast rate. Useful for the forecast itself: what will the rest of the year look like at today's rates? Don't use it to judge performance against a budget built at different rates.

Whatever you pick, keep monthly average rates for P&L lines and month-end rates for balance sheet lines. That mirrors how IAS 21 handles translation for statutory reporting: income and expenses at the rate on the transaction date (an average rate is the accepted practical shortcut), and assets and liabilities at the closing rate.

How do you split a variance into volume, price and FX?

Calculate volume and price at the budget rate, then calculate FX on the actual local-currency amount. The three pieces add back to the total variance exactly, so nothing gets lost or double-counted.

• Volume variance = (actual units − budget units) × budget price × budget rate
• Price variance = (actual price − budget price) × actual units × budget rate
• FX variance = actual local-currency amount × (actual rate − budget rate)

Here's a worked example. A European subsidiary budgeted 10,000 units at €50, or €500,000, at a budget rate of 1.10 USD per EUR: $550,000. It actually sold 10,400 units at €49, or €509,600, and the average rate for the month came in at 1.05: $535,080.

At reported rates, revenue missed budget by $14,920 (2.7%). At constant currency, it beat budget by $10,560 (1.9%). The whole miss was the euro.

The local team sold more units than planned and gave up a euro on price, which is a real conversation about discounting. The $25,480 FX line isn't their conversation at all. It belongs in the treasury section of the pack, next to any hedge result.

Where does FX hide in headcount cost?

In salaries paid in foreign currencies. A team in London or Toronto is planned at the budget rate and paid at the actual rate, so heads tie and cost still moves. Say a London team costs £300,000 a month, budgeted at 1.30 ($390,000). If sterling averages 1.35, the same payroll books at $405,000, and the department shows a $15,000 overspend without hiring anyone.

The fix is the same split as above. Report a rate effect (actual cost at the budget rate minus planned cost) and an FX effect (actual cost at the actual rate minus actual cost at the budget rate), and only treat the rate effect as the department's variance. Our guide to reconciling the headcount plan against actuals uses the same definitions, along with the other three reasons heads tie but people cost doesn't.

Contractors invoiced in foreign currencies and foreign-currency software contracts have the same problem on a smaller scale. If your cost base is spread across currencies, run the split on opex too, not just revenue.

Translation FX vs transaction FX

There are two different FX effects in most multi-currency P&Ls, and constant currency only handles one of them cleanly.

• Translation FX comes from converting a foreign subsidiary's results into the group's reporting currency. The subsidiary's local numbers didn't change; only the conversion did. Constant-currency reporting is built for this.
• Transaction FX comes from a single entity buying or selling in a currency other than its own, for example a US entity paying a European supplier in euros. The gain or loss is booked in that entity's ledger, usually in other income or expense. It's a real cash effect, so report it as its own line rather than restating it away.

Statutory translation also produces a balance sheet effect: differences from translating net assets go to other comprehensive income and build up in a translation reserve. That's group-accounting territory. If you need it, our comparison of multi-entity consolidation software covers which tools do full translation and which only convert for reporting.

How to set up constant-currency reporting in six steps

1. Lock a rate table when the budget is approved. One budget rate per currency per month (or one for the year), stored in a single table with an owner. Don't change it mid-year; if rates move a lot, show the reforecast at new rates as a separate view.
2. Keep every entity's numbers in local currency. Convert in the reporting layer, not in the export. Once a trial balance has been converted at one rate, you can't restate it at another.
3. Convert actuals twice. Once at the actual average rate (what the group P&L shows) and once at the budget rate (the constant-currency view). Balance sheet lines use month-end rates.
4. Split every material variance into volume, price and FX. Use the formulas above for revenue, and the rate and FX split for payroll and other foreign-currency costs.
5. Show both views in the board pack. Reported and constant currency side by side, with one line explaining the method, the way the SEC expects of public filers.
6. Decide how the forecast handles rates. Most teams forecast at the latest rates and keep a budget-rate version for comparison. Either way, keep the FX line in forecast vs budget too.

Common mistakes in constant-currency reporting

• Converting the P&L at the month-end spot rate. One day's rate applied to a month of transactions exaggerates FX swings. Use the average.
• Resetting the budget rate mid-year. It makes the FX variance disappear and the performance variance meaningless. Reforecast at new rates instead.
• Letting FX sit inside price variance. If a European price cut and a weaker euro land in one line, nobody can tell which one to act on.
• Ignoring hedges. If treasury hedges the euro exposure, the hedge gain sits somewhere else in the P&L. Show it next to the FX variance, or the pack overstates the currency hit.
• Doing it only for revenue. Foreign payroll and supplier costs carry the same distortion.

Can you do constant currency in Excel?

Yes, for a handful of entities. A rate table, local-currency actuals by entity and account, and SUMIFS formulas that convert each line at two rates will do it. It gets fragile as the group grows: every new entity, ERP or currency adds another export to convert, and the rate table drifts away from the numbers it's applied to.

The usual breaking point is entities on different accounting systems. Our guides to FP&A tools for multi-ERP companies and to consolidating multiple QuickBooks companies cover how teams bring those entities into one view before converting them.

Which FP&A tools handle constant-currency reporting?

Most FP&A tools convert currencies; the differences are in how much of the statutory translation they do and where the work happens. Based on the vendors' own documentation as of October 2026:

• Aleph: best for live budget vs actuals in Excel or Google Sheets, converted at the rates you provide.
• Cube: best for spreadsheet-native teams that also want FX conversion and eliminations in the roll-up.
• Datarails (FinanceOS): best for Excel-first groups that consolidate entity workbooks with currency translation.
• Pigment: best for multi-currency planning in one model when the close lives elsewhere.
• Planful: best for mid-market groups that want consolidation, currency translation and planning in one product.
• OneStream: best for complex groups that need translation at historical, average and current rates plus multi-GAAP reporting.

Cube and Datarails work most like Aleph: all three keep finance in spreadsheets rather than a separate planning app.

Your ERP may handle part of this already. NetSuite OneWorld and Sage Intacct both translate subsidiaries into the reporting currency, but only for entities inside that ERP, and neither gives you a budget-rate view on its own.

Where Aleph fits

Aleph connects to each entity's ERP and brings actuals into the Excel and Google Sheets models your team already uses, in local currency, with drill-down to the transaction. It converts at the rates you provide, so a budget-rate table and actual rates can sit side by side and produce both the reported and the constant-currency view on every refresh.

Two public examples: Turo's finance team, which had manual consolidation and FX processes across its international entities, cut its FX imports from hours to two minutes. Chess.com runs a multi-currency business across eight ERPs and now reports from one consistent source. For the variance commentary itself, Aleph's AI variance analysis surfaces the drivers behind each movement.

Considerations: Aleph does reporting-layer currency conversion, not full IAS 21 translation with a translation reserve, and it doesn't post consolidation entries. If you need statutory translation, keep it in the ERP or a consolidation engine and use Aleph for the management view.

Report in constant currency on live data with Aleph

Connect every entity, keep the numbers in local currency and show reported and constant-currency budget vs actuals in the same sheet, refreshed after every close. Book a demo to see it on your own entities and rates.