Runway math for a company that hires in three currencies

Most runway models are built the same way: take cash on hand, divide by average monthly burn, get a number of months. It's a fine model for a company with one payroll, one office, and one currency. It quietly breaks for almost everyone else — and "everyone else" now includes most startups past their first ten hires, because remote and distributed teams have made multi-currency payroll the default, not the exception.

The problem isn't the math. It's the assumption underneath the math: that burn is a stable, predictable line you can divide cleanly into a calendar. Once you're paying salaries in USD, EUR, and a local currency that moves 8% against the dollar in a bad quarter, "months of runway" stops being a fixed number and starts being a range — and treating it as fixed is how boards get surprised.

Where calendar-based budgeting breaks first

The failure shows up in three places, usually in this order:

• FX drift on payroll. A team hired at a favorable exchange rate can see its USD-equivalent cost rise meaningfully over a year with zero change in headcount or local salaries.
• Hiring plans built in headcount, not cash. "We're hiring five more engineers this quarter" means something different in three different currencies, but the budget spreadsheet usually treats it as one number.
• Runway reviews that lag reality by a full cycle. A monthly or quarterly runway check is already stale by the time a currency move or a hiring surge shows up in the actuals.

The value-based trigger model

The fix isn't a more complicated spreadsheet. It's a different unit of analysis: instead of budgeting against a calendar (spend X by month Y), budget against triggers — specific, observable events that release or pause spend, regardless of what month it happens to be.

In practice this means three shifts:

1. Convert headcount plans to a cash band, not a cash point

Instead of "five hires this quarter," model a low and high case based on realistic FX movement for the currencies involved. You're not trying to predict the exchange rate — you're sizing how much your plan can absorb before it needs a second look.

2. Set re-forecast triggers, not calendar check-ins

Rather than "review runway every month," define specific thresholds that force an off-cycle review: a currency moving more than a set percentage against your primary reporting currency, actual burn exceeding plan by a set margin, or a hiring plan changing materially. The calendar review still happens, but it's no longer the only trigger.

3. Report runway as a range to the board, not a single number

A single "14 months of runway" figure invites false precision. A range — "12 to 15 months, depending on EUR/USD movement and Q3 hiring pace" — is more honest, and it pre-empts the awkward conversation where the number moves and nobody explained why it could.

Runway isn't a number you calculate once a month. It's a decision you re-check every time one of a small number of specific things changes.

What this looks like in a real forecast

Take a company paying roughly 40% of payroll in USD, 35% in EUR, and 25% in a local currency for an offshore team. Instead of one blended burn rate, the model tracks three currency-denominated burn lines against three sets of local assumptions, then rolls up to a single reporting currency with an explicit FX sensitivity band — typically built from a recent realistic volatility range for the currency pairs involved, not a worst-case stress scenario.

The board still sees one runway number in the headline. The CFO also has the range underneath it, and — critically — knows in advance exactly what would need to move for that headline number to change materially. That's the actual goal: not a more precise forecast, but one that tells you which variables to watch instead of asking you to be surprised by all of them equally.