Multi-Currency Financial Models: How to Run Finance Across UK, US, and Europe
Running a startup across multiple currencies is not just an accounting complexity --- it creates real economic exposure that will affect your P&L, your runway calculation, and your unit economics in ways that a single-currency model cannot capture. The founders who get this right build models in a functional currency, translate reporting into a presentation currency, and apply FX assumptions that are explicit, sourced, and stress-tested. The ones who get it wrong discover the problem when an investor asks why the model does not reconcile to actual bank balances.
Author: Yanni Papoutsi · Fractional VP of Finance and Strategy for early-stage startups · Author, *Raise Ready*
Published: 2025-03-08 · Last updated: 2025-03-08
Reading time: \~8 min
What Is the Multi-Currency Problem in Startup Finance?
A startup operating across currencies earns revenue in one currency, pays costs in another, holds cash in both, and reports to investors in a third. Each translation creates FX exposure: the risk that exchange rate movements change the real value of the business's financial position. Key facts at a glance:
UK startup with US | GBP/USD movement Revenue recognised in USD, customers | costs in GBP
USD-functional company | GBP/USD movement UK team costs fluctuate in with UK ops | USD terms
EUR entity paying USD | EUR/USD movement Vendor costs fluctuate in contracts | EUR terms
Multi-entity group | All cross-entity Intercompany eliminations consolidation | currencies | required
The Functional vs. Presentation Currency Distinction
The first structural decision in a multi-currency model is distinguishing functional currency from presentation currency. Functional currency is the currency of the primary economic environment in which the entity operates. For a UK startup that earns most revenue in GBP and pays most costs in GBP, the functional currency is GBP. For a US Delaware C-corp that invoices in USD and pays its key staff in USD, the functional currency is USD, even if it has a UK subsidiary.
Presentation currency is the currency in which you report financial statements. Many international startups present in USD for investor reporting, even when the functional currency of the operating entity is GBP or EUR. This requires translating the financial statements from functional to presentation currency at period-end rates.
Key insight: The distinction matters because translation from functional to presentation currency creates exchange differences that sit in equity (not the P&L). Many founders confuse these translation differences with actual operating losses or gains, which distorts the reading of the model.
How to Build a Multi-Currency Model That Works
Step 1: Define the functional currency for each entity.
If you have a UK entity and a US entity, each has its own functional currency. Transactions within each entity are recorded in functional currency. Intercompany transactions require explicit FX translation. **Step 2: Apply a single functional currency for the model consolidation.**
For investor reporting, pick one currency --- typically USD --- and translate all entities into it. Apply average rates for P&L items, closing rates for balance sheet items. Flag this methodology in the assumptions tab.
Step 3: Build an FX assumption table.
Do not hard-code exchange rates into revenue or cost lines. Build an assumptions table with the FX rates you are using, their source, and the date of the rate. Use forward rates where available for forecasting rather than spot rates, since forward rates reflect market expectations. Step 4: Create an FX sensitivity.
A 10% movement in your main cross-currency pair is a realistic scenario over a multi-year model horizon. Show what a 10% depreciation of your revenue currency (or appreciation of your cost currency) does to gross margin and operating cash flow. This is a standard investor diligence question for any international business.
Step 5: Model intercompany charges explicitly.
If the UK entity provides services to the US entity (or vice versa), these intercompany charges need to be at arm's length for tax purposes and eliminated at consolidation for financial reporting. Build these flows explicitly rather than netting them out informally.
The Specific Challenges by Entity Structure
UK Ltd operating with USD revenue:
Revenue recorded in USD must be translated to GBP at the transaction rate or a monthly average rate. If GBP strengthens against USD, the translated GBP revenue is lower even if USD revenue grew. This is not a business problem --- it is a translation effect --- but it looks like one in the P&L if it is not clearly labelled.
US Delaware C-corp with UK subsidiary:
The UK subsidiary's costs (largely GBP) are translated into USD for consolidation. A weak GBP environment reduces the USD cost of the UK team. A strong GBP environment increases it. Model the UK subsidiary's P&L in GBP, then translate at the assumption rate for the US entity consolidation.
Multi-entity with EUR operations (e.g. France, Italy, Romania): EUR-denominated costs and any EUR revenue need their own FX assumptions. The EUR/USD rate and EUR/GBP rate both matter. Build each entity's P&L in its functional currency, then translate to the presentation currency for the consolidated view.
The FX Assumptions Most Models Get Wrong
Using spot rates for multi-year forecasts. Spot rates are
appropriate for today. For years two through five of a forecast, use forward rates or an explicitly stated assumption with a rationale. "We assume stable rates throughout the forecast period" is an acceptable assumption if stated explicitly. Implicitly assuming stable rates without flagging it is a model credibility issue.
Not separating transaction exposure from translation exposure. Transaction exposure arises when you have a contractual obligation in a foreign currency (e.g. a USD invoice outstanding in a GBP entity). Translation exposure arises when you consolidate foreign subsidiaries. These require different treatments.
Ignoring hedging costs. If the business uses FX forwards or other hedging instruments to manage currency exposure, the cost of those hedges belongs in the model. Hedging reduces volatility but is not free.
Frequently Asked Questions
Should startup financial models use actual or forecast FX rates?
Both, in different places. For the historical section of the model, use actual rates. For the forecast, use forward rates or explicitly stated assumptions based on a source. Flag all FX assumptions clearly in the assumptions tab with a note on methodology.
How do you handle payroll in multiple currencies?
The cleanest approach: model each entity's payroll in its functional currency, then translate to the presentation currency using the FX assumption for that period. Avoid blending multi-currency payroll into a single line because it obscures both the underlying cost and the FX exposure.
What is a practical FX sensitivity to include?
A +/-10% movement in the primary cross-currency pairs affecting gross margin and operating cash flow. This covers most realistic FX scenarios over a 12-18 month window. For businesses with significant USD/GBP exposure, the post-Brexit rate history shows a range of approximately 1.10 to 1.45 over recent years, which is a wide band and worth stress-testing.
Summary
Multi-currency operations require multi-currency models. The key steps are: define functional currency for each entity, use a single presentation currency for investor reporting, build an explicit FX assumption table with sourced rates, run a 10% sensitivity on major cross-currency pairs, and model intercompany charges explicitly. The most common errors are using spot rates for multi-year forecasts, conflating translation effects with operating performance, and ignoring the cost of hedging. Get the structure right and the model will reconcile to actual bank balances across currencies --- which is the final test of whether it has been built correctly.
Get the complete guide with all 16 chapters, exercises, and model templates.
Get Raise Ready - $9.99