I was asked a question recently about creating SaaS pricing models that include multi currency support.
I’ve attempted to answer the question in a meaningful way, but I am the first to acknowledge that there is a lot more to it than just what I talked about in this post.
But it’s a great jumping off point if you’re considering selling your SaaS offering in multiple regions where different currencies are used.
Read on…
Here’s Clint’s question…
Hey Lincoln, I’m trying to get line of sight on best practices regarding pricing/currency discussions for SaaS solutions – e.g. is it acceptable to do everything in USD – show pricing plans in USD but allow transactions in multi-currency, show plans in multi-currency. Etc. Also wondering about pricing uplift in various regions or since it is the Web do you see people sticking to one price and just account for exchange rates? – Clint
Here’s my answer for Clint (and you)…
You could do everything in USD, but if you can, you should support local currencies.
While I realize it adds overhead on the backend, it greatly simplifies things on the customer side and ultimately that’s what really matters.
Also – know your customer and their regional issues – some people can’t or won’t do business outside of their local currency… either due to personal bias, company policy, or their payment method.
Certainly the easiest way to do this in a transparent pricing model is to display a price – say $50/mo – and simply allow someone to select (or select for them based on their current location) GBP – for example – and have it translate from US$50 based on today’s or real-time exchange rates to GBP30.85.
Here’s an example from CustomerSure, based in UK, going from USD to NZD:
Stripe, Recurly, and Zuora (three recurring / subscription payment systems at varying market positions) all have multi-currency support built-in, so from a technical perspective this is easy.
So while it’s not difficult to implement multi-currency support for your SaaS app these days the key is to know WHY you’re doing it.
If you’re doing business in the US, Canada, EU, and Australia, you’re probably okay with the exchange method.
However, if you’re looking at going to India or China or another country / region where they are potentially more cost-conscious and / or where you might offer different packaging – perhaps to rapidly gain marketshare, then I suggest showing those folks – based on geo location info, region- or campaign-specific landing pages / micro sites / domains, etc. – whatever they need to see and nothing more.
There’s no reason for a potential customer in India to see that folks in London are paying GBP30.85/mo for the service when I’m selling the product in India for a one-time fee of US$10 or 625 INR via SMS rather than credit card.
And the folks in London don’t need to see what I’m selling the product for in India, either.
Of course some regions aren’t going to be price-sensitive but could find additional value in what you’re offering above and beyond what those in the US/EU might find, allowing for a premium price to be put on their region-specific packaging.
And this different packaging, plus regional IP restrictions and language barriers will keep the vast majority of people from doing an apples-to-apples comparison of your pricing across regions.
So, just like everything else, when considering multi-currency support for your SaaS app, you have to know your market, your customers, how they buy, how they value what you’re offering, why you’re going into that market, etc.
There’s a lot more to it, but that should get you going in the right direction.
Now, how you deal with Revenue Recognition, exchange rates, and all that fun stuff on the backend… man, that’s what CFOs, accountants, and lawyers are for.
About Lincoln Murphy
