Foreign exchange
Revenue converts at the month's average rate, and currency-driven movements are tagged so the constant-currency view can remove them.
Also Constant currency · FX translation · Multi-currency revenue
Flows are converted at monthly-average rates for the month in which they occur. A missing rate falls back to the nearest prior month's rate and is logged as an assumption. Movements arising purely from rate changes are tagged fx_driven, sub-totalled in the bridge, and removed entirely in the constant-currency view.
- Formula
base-currency amount = native amount × the month’s average rate · constant currency = native amount × the base period’s rate- Unit
- currency
- Bounded
- n/a
- Defaults
- fx.flow_rate = monthly_average (locked) · fx.fallback = nearest_prior · base period = 12 months before the cutoff
- Biggest lever
- The base period — any other choice is a different "constant" currency
- Read with
- The movement taxonomy · Growth accounting · Revenue tie-out
- Appears in
- Board deck · Constant-currency growth · Register
- Switches
- 2 · 1 locked — see the choices
What it measures
In a multi-currency book, reported growth is two things fused: what the business did, and what the currency did. Separating them is not an accounting nicety. A company reporting 8% growth in a year when its main billing currency strengthened 10% against the base may have shrunk in operating terms, and no amount of attention to the revenue file will reveal it without an explicit FX treatment.
The standard therefore holds both readings: the reported bridge, which is what actually happened to the money, and the constant-currency bridge, which is what happened to the business.
How it is computed
Rate basis. Monthly-average rates, applied to the month a flow occurs. This is the appropriate convention for flows — revenue earned across a month is not translated at a single day’s spot rate. Balance-sheet closing rates are a different convention for a different purpose and are not used here.
Native amounts are preserved. Every customer-month row retains its original-currency amounts per measure alongside the converted figures. This is what makes constant currency a recomputation rather than an estimate: the base-currency series can be rebuilt at any chosen rate without returning to the source file.
Missing rates. Under nearest_prior (default), the most recent earlier
month’s rate is used and an assumption is logged naming the currency and month.
Under block, the computation stops until the rate is supplied. The default trades a
small, disclosed imprecision for the ability to compute; the alternative exists
for engagements where no inferred rate is acceptable.
FX-driven movements. When a customer’s native-currency amounts are unchanged
but the base-currency figure moves, the resulting expansion or contraction is
tagged fx_driven. It remains a movement — the reported bridge must tie to
reported revenue — but it is sub-totalled separately so a reader can see how
much of the period’s expansion was translation.
Constant currency. The entire MRR series is recomputed with every native amount converted at the base period’s rates, and movements are re-derived from that series. The base period is twelve months before the cutoff by default. With fewer than thirteen months of data the base period predates the data, and every year-over-year constant-currency figure is reported as not computable rather than as zero or as a ratio against an empty base.
Worked example
A customer billing 1,000 EUR per month, unchanged, while EUR/USD moves:
| Month | EUR | Rate | USD MRR | Movement |
|---|---|---|---|---|
| Jan | 1,000 | 1.10 | 1,100 | — |
| Feb | 1,000 | 1.15 | 1,150 | expansion +50 fx_driven |
| Mar | 1,000 | 1.05 | 1,050 | contraction −100 fx_driven |
The customer did nothing. The reported bridge shows expansion then contraction — correctly, because reported revenue genuinely moved. The constant-currency view at January rates shows 1,100 in all three months and no movements at all.
Both are true. Quoting only the first attributes currency to the sales team; quoting only the second describes revenue nobody received.
The choices that change the number
fx.flow_rate. Monthly average is locked. Spot-at-month-end would make every month’s revenue depend on one day’s rate.fx.fallback.nearest_priorversusblock— compute with a disclosed approximation, or refuse until the data is complete.- The constant-currency base period. Twelve months back by default. Any other choice produces a different “constant” currency, so the base period is stated on the table.
- Whether FX movements are movements at all. Here they are, tagged. Excluding them from the bridge entirely would break the tie to reported revenue.
How it is misread
Constant currency quoted without the base period. Meaningless without it — the phrase names a method, not a number.
FX-driven expansion counted as commercial expansion. Inflates NRR and the quick ratio in exactly the periods when a currency moved favourably. The sub-total exists to prevent this.
Single-rate-for-the-year conversion. Common in hand-built models and wrong in both directions: it misstates individual months and, because the growth comparison spans two different rate environments, misstates the trend too.
Assuming a single-currency file has no FX exposure. A company billing entirely in USD to European customers carries the exposure in its customers’ willingness to pay, not in its revenue file. That risk is real and invisible here.
What it cannot tell you
The standard converts recorded amounts at recorded rates. It cannot tell you whether prices were repriced in response to currency moves, whether hedges exist, or whether a customer’s local-currency price is sustainable after a large move. It measures translation, not economic exposure.
How to state it
A disclosure that travels with the number. Replace the braces; keep the parenthesis.
Growth {x}% reported · {y}% in constant currency at {base period} rates (SoF Standard v1.0: monthly-average flow rates) Before you quote it
- Base period stated?
- FX-driven movements sub-totalled in the bridge?
- Missing rates logged as assumptions?
- Native amounts preserved on every row?
Related questions
- Which exchange rate converts revenue?
- Monthly-average rates for the month the flow occurs, locked under this standard. Revenue earned across a month is not translated at a single day's spot rate; closing rates belong to the balance sheet, not to flows.
- Does a currency move count as expansion or contraction?
- In the reported bridge, yes, tagged
fx_drivenand sub-totalled separately, because reported revenue genuinely moved. In the constant-currency view it disappears. Quoting only the first credits the currency to the sales team; quoting only the second describes revenue nobody received. - How is constant currency calculated?
- Every native-currency amount is recomputed at the base period's rates — twelve months before the cutoff by default — and movements are re-derived from that series. Because native amounts are preserved on every row, this is a recomputation, not an estimate. The base period is stated, or the phrase means nothing.
- What happens when a rate is missing?
- The nearest prior month's rate is used and an assumption is logged naming the currency and month. Under the stricter
blocksetting the computation stops until the rate is supplied. - Does a business billing only in dollars have FX exposure?
- Not in its revenue file. In its customers' willingness to pay, possibly: a European customer billed in dollars absorbs the currency move, and that pressure is invisible here. The standard measures translation, not economic exposure.
Strategy of Finance. “Foreign exchange.” SoF Standard Definitions v1.0 (2026-09-18). https://www.strategyoffinance.com/standards/foreign-exchange/