Hot to Navigate Currency Translation in HFM
Written By Jessica Benbow, Practice Lead, Consolidations & Reporting
After completing over 12
implementations, one area where I continue to see customers struggle is currency translation. While some customers have very basic translations needs, many require more functionality then is available
natively within HFM. I feel that it would be worthwhile to explore this topic deeper, beginning with the functional basics of translation and configuration within HFM and building up to complex currency
The Basics of Currency Translation
There are three primary Currency Types that multi-currency customers use: Local Currency, Functional Currency, and Reporting Currency. For illustration, let's consider Entity Company in England. At Entity
Company, the following may apply:
Local Currency is the currency where Entity is located (i.e., Local Currency: GBP).
Functional Currency is the currency of the primary economic environment in which Entity operates (i.e., Functional Currency: EUR).
Reporting Currency is the currency in which the consolidated Entity is reported externally (i.e., Reporting Currency: USD).
To translate these balances, two standard Translation Methods may be utilized, Remeasurement (Temporal Rate) or Current Rate.
Remeasurement is the translation from Local Currency (GBP) to Functional Currency (EUR). The translation gain/loss is reported as part of Net Income.
Current Rate is the translation from Functional Currency (EUR) to Reporting Currency (USD). The translation gain/loss is reported in the Equity portion of the Balance Sheet.
Remeasurement is not a translation type that most customers require as part of their business process. Therefore, I will start with the more commonly used Current Rate method.
The most common configuration of the Current Rate Method of Translation that I see within HFM is to have one monthly Currency Rate (FX Rate) for Income Statement Accounts and another FX Rate for Balance
Sheet Accounts. Some customers may configure their application with a frequency greater than one month, but this is not common. Income Statement Accounts are typically translated using the Average Rate
(AVG) for the period, while Balance Sheet Accounts are translated using the End of Month/Spot (EOM) rate.
Translation of a specific Account within
is based on the Account Type associated with the Account within metadata. Revenue/Expense Account Types are typically associated with the Income Statement Accounts. Income Statement Accounts are typically
translated based on the PVA method. This means that the Periodic Activity is identified, then multiplied/divided by the AVG Rate. This balance is then added to any previous Year-to-Date USD balances. On
the other hand, Asset/Liability Account Types are typically associated with the Balance Sheet Accounts. Balance Sheet translation occurs by taking the Ending Balance for the Period and multiplying/dividing
by the EOM Rate. This is referred to as the VAL method.
The following is an illustration of the PVA and VAL methods:
Jan Feb Mar
AVERAGE RATE.MXN 1.5 2.0 3.0
INCOME ACCT (MXN) 100 300 600 (YTD amounts)
INCOME ACCT (USD) 150 550 1450 (TRANSLATED amount after consol)
The PVA method takes the periodic value in the Revenue/Expense and multiplies/divides the balance by the exchange rate for that period. It then adds this result to the translated value from the prior
period. It does not change the exchange rate amount or look to the prior period for the exchange rate.
In the example above the calculations are as follows:
JAN 100 * 1.5 = 150
FEB (300 - 100) = 200 * 2.0 = 400 + 150 (JAN YTD) = 550
MAR (600 - 300) = 300 * 3.0 = 900 + 550 (FEB YTD)= 1450
Jan Feb Mar
End Of Month RATE.MXN 1.5 2.0 3.0
FIXED ASSETS (MXN) 100 300 600 (YTD amounts)
FIXED ASSETS (USD) 150 600 1800 (TRANSLATED amount after consol)
The VAL method takes the Ending balance in the Asset/Liability Accounts and multiplies/divides the by the End of Month exchange rate for that period.
JAN 100 * 1.5 = 150
FEB 300 * 2.0 = 600
MAR 600 * 3.0 = 1800
Issues & Limitations
One of the first issues we will deal with regarding translation begins at this stage. As noted above, there are Asset and Liability Account Types native to HFM. There is not an Equity Account type. Equity
Account balance is composed of multiple transactions that occurred life-to-date within the business. Each one of these transactions may require a different FX Rate to be applied. For instance, when a company
invests money in another organization, that investment is typically translated based on the rate at the time of the transaction or the rate agreed upon within the contract. As you can imagine, over the
life of the organization, many different transactions can make up the End of Month balance within HFM. The historical transactions should not be re-translated at the current EOM Rate; instead, they should
maintain the original translated balance.
There are a variety of approaches for overcoming this limitation within HFM. Watch out for my next post, where we will focus on a frequently-used approach.
Contact MindStream Analytics
Want to know more about Navigating Currency Translation in HFM? Fill out the form below.