MRR, or Monthly Recurring Revenue, is perhaps the single most important metric a subscription business will need to calculate. To over-simplify, MRR is a calculation of a businesses normalised, monthly subscription revenue.
We started with the assumption that most businesses have a ‘primary currency’ they measure their global revenues in, usually the native currency where they’re headquartered.
We decided the most useful approach would be to allow our users to set a Primary currency and then consolidate all subscriptions into that currency.
This lead us to the question of how should we handle fluctuating exchange rates? We thought about giving users the option to set a static rate for each currency they work with, but this wouldn’t allow us to generate historically accurate graphs.
We decided we’d need to use historic exchange-rate data to give an accurate picture of MRR over time. Thanks to openexchangerates.org we could easily query rates for almost every currency going back 15 years, and can also use it to automatically fetch updates daily.
As much of ChartMogul’s calculations are based off parsing paid invoices, we settled on using the relevant ‘closing rate’ from the day on which each invoice was paid. For real-time updates we use yesterday’s closing rate, and then at midnight when there is a closing rate available for today we switch all activity generated today to using the correct closing rate.
What this means is that if you have a customer paying a subscription in Euros and your account’s Primary currency is USD then you may see a subtle fluctuation in MRR each month.
This we believe gives a more accurate picture of real MRR, taking into account the positive and negative impact that currency fluctuations will have on your MRR number.
During the implementation we made a couple of technical decisions that might be of interest. Firstly, we selected a backend base-currency (USD) so we only need to store rates relative to USD. This allows us to store less records in our DB and still be able to convert between any two currencies by first converting to USD and then from it (there is no loss in underlying value in these conversions unlike the terrible buy/sell rates you get at the bank or airport!)
Secondly, to help with handling conversions on the fly, we added another column to the database to store not only the MRR amounts in the invoiced currency, but also in USD. This pre-calculation allowed us to simplify and speed up the calculation of metrics in realtime.
ChartMogul was also configured to generate notifications for any customer upgrades or downgrades (expansions/contractions), and adding fluctuating exchange rates was going to create some false alarms. So for the purpose of generating upgrade or downgrade activity we use the original invoiced currency regardless of the Primary currency.
After everything was implemented we ended up with a simple but effective way of handling multiple currencies gracefully.
One nice surprise is that you can switch your account’s Primary currency at any time and immediately see all your metrics recalculated in a different currency.
What do you think of our approach? We’re interested to hear how others have dealt with this issue.
Uladzimir is a backend developer at ChartMogul.
