Navigating Currency Translation in HFM

How to Navigate Currency Translation in HFM

Written By Jessica Benbow, Practice Lead, Consolidations & Reporting

After completing over 12 HFM 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 translation modeling.

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 HFM 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:

PVA

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

VAL

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.

Search

Case Studies

Recent Articles

Related Links