As companies have increasingly global workforces and customers, it's worth the time for Salesforce administrators to understand how multi-currency works. It doesn't involve any obscure knowledge of finance, and is probably simpler than you think.
In this article, we'll summarise how it works, and highlight the pros and cons of the feature. By the end, you should have an understanding of how it works, and whether or not it makes sense for your organisation.
First, here's a succinct summary that we can unpack as we go:
- Multi-currency is essentially presentation logic 📊. Under the hood everything remains a number type, it's just displayed differently to different users
- There are three modes:
Single-Currency (the default)
Multi-Currency (a fixed conversion rate for each alternate currency)
Advanced Multi-Currency (conversion rates for alternate currencies that change over time)
💴💵💶💷 📅 💹
- Enabling it is a one way door!🚪 It can't be disabled once enabled. For this reason, I won't step you through enabling it - but you can find it under "Manage Currencies" in setup.
- You manage the conversion rates yourself ⌨ (it's not connected to any authoritative internet source). Alternatively you can use a third party app from the AppExchange and let them maintain it. 🏪
- Multi-Currency works pretty much how most people expect it will 👍
- Advanced Multi-Currency has some very significant caveats that should be well understood before enabling 🤔
The "Currency" data type
Salesforce has a “Currency” field type for handling numbers that represent financial amounts. As described here ,they are not a primitive data type but act as presentation logic for a number field. You can see the difference below, where the number “123” is entered into a currency field and a regular number field respectively:
Mode 1: Single Currency
This is the mode that all Salesforce orgs default to.
Mode 2: Multi-Currency
In this mode, Salesforce is aware of more than one currency:
A single currency is nominated as the “Corporate” currency, and is the only currency initially.
Other currencies are added by the Salesforce administrator from a list of standard ISO currency codes. The conversion rate must either be entered and maintained by the administrator, or via a third party app connected to a currency data service (search the AppExchange for these).
The conversion rate of every other currency is expressed relative to the corporate rate. If you ever switch the corporate rate to a different currency, all other currencies will have their rates updated to be relative to this new currency.
When in this mode, individual users can choose their local currency from their user settings, from the list of currencies recognised by their company (per above):
Also, every record automatically contains a field named “Currency”, which determines how any Currency fields for that record should be interpreted:
As an example; below are two records, and all fields had the value “123” entered. The first record had AUD selected as the currency, the second had EUR. The user viewing the record has their local currency set to AUD. So the first record is displayed as-is, the second shows the EUR amount and also the equivalent AUD amount for convenience.
What happens if the user has a different display currency set?
The same list, viewed by a user with USD set, sees this:
Notice that every user is always shown the original currency, with the converted amount in their own currency added in parenthesis if it's different.
The big caveat in this mode is that as the exchange rates are updated over time, revisiting old records will change how they are displayed, as today’s rate is always used in their presentation. Which leads us to the third and final mode!
Mode 3: Advanced Multi-currency
In this mode, Salesforce is aware of not only multiple currencies, but keeps a record of their exchange rates over time.
So when configuring the currency table, there is a date dimension:
And when drilling into an individual currency, you can see its historical values:
Now, the catch
On the surface, this appears to provide convenient universal functionality. In reality, these dated exchange rates only apply to a very limited number of Standard objects (Opportunity related) with a non-configurable effective date. For example, Opportunity objects always use the Close Date to determine the currency rate. For more information, see here.
So if you were hoping to be able to nominate any date field on your standard or custom object to act as the point in time for currency conversion, unfortunately you are out of luck. The request to enable this functionality dates back well over a decade. 🕰
There are some third party workarounds on the AppExchange, which appear to involve triggering fields to be updated to contain alternate currency values. This is not quite the same result, since each user's currency preferences won't be honoured (any of those ISVs reading this, please correct me if I've misunderstood!).
Omnata Connect and Multi-Currency
More and more companies are rolling out product driven pricing models and the revenue calculations tend to be more complex. These processes are being run in data warehouses and the output datasets tends to be large, time-sensitive and difficult to integrate into Salesforce.
Omnata Connect is perfect for these types of datasets. You can display information directly from your cloud data warehouse within Salesforce, natively in real time - no middleware required.
As part of this, we've built robust advanced multi-currency support that doesn't suffer from the same limitations described earlier in the article.
Omnata Connect leverages Salesforce Connect to provide External Objects for any data warehouse table or view.
Our native, on-platform translation layer can treat the financial figures in your data warehouse as currency, converting it in real time as it is fetched. It can incorporate both the organization's fixed or dated exchange rates, as well as the current user's preferences when rendering these currencies.
For example, below we see customer orders being displayed live from Snowflake.
The price column comes straight from Snowflake, but it's just a number. In its current form, the user must assume or know which currency it is.
So, all we need to do is open the Omnata Setup UI, and enable Multi-Currency for the "Total Price" field. We are going to state that these prices are in USD, and that the Order Date is the effective date of conversion.
After making this change, we see there is a new calculated field available in our External Object:
After tweaking our Contact layout, we now see proper currency values displaying:
Multi-Currency is a great feature in Salesforce, and not too complicated to use. However, there are different ways to approach it that each come with caveats.
Omnata Connect provides a compelling solution for Multi-Currency that our customers have leveraged to deploy data integrations quickly, at scale, for a global audience.