Getting You To The Top: Part I. Exposure Collection
Part I. Exposure Collection
Whether you’re using software, tapping into your ERP, having subsidiaries capture and submit exposures or all of the above, exposure collection is a critical piece of the hedge program startup puzzle. The hardest part of an effective hedging program is creating a process for quality data collection; doing this right will provide a solid foundation for your program.
The first step in an effective balance sheet hedge program for currency risk is a deep understanding of what creates exposures for the company and collection of those exposures. In an interesting paradox, people think they understand exactly what creates gains and losses in their FX Gain/Loss line – yet don’t actually understand their company’s FX Gain/Loss. That reflects the difference between what should be happening and what is happening, especially for companies relying on the automated revaluation features of common ERP software. Before you make certain that the system is capturing the correct exposures, you need to collect what you believe is the exposure information.
For the few companies where all entities are on a single instance of an ERP software, this may be as easy as running a trial balance by entity, by currency of denomination report. This report would have account names in the first column followed by the foreign currency units by currency (necessary) reflecting the denomination of the documented transaction. Having the foreign currency units is useful, but if the report prints out the values in USD that isn’t a problem, as the balances you needed can easily be converted to foreign currency units using the balance sheet rate used in translation.
From this report you will extract the balance sheet values associated with Monetary Accounts. The list of monetary accounts is so extensive that the FASB has chosen to highlight non-monetary accounts. The monetary balances in all currencies that are not the functional currency represent the exposures the company has on the books at the point in time the report is run. Unless you are hedging, this represents the source of 100 percent of the source of FX Gains/Losses from that point forward.
Each day, the exposures change with each non-functional currency related transaction (revenues that create receivables, inventory purchases or expenses that create payables, conversions into or out of cash). The FX Gain/Loss is the change in value of a non-functional currency transaction from the rate at which it comes onto the financial statements until it is settled/converted. Capturing the balance information through the collection of trial balance information provides a snapshot of all non-functional currency assets/liabilities that are not yet settled.
If your entities are not all on the same ERP instance or there are subsidiaries not using the automated revaluation functionality, there are automated and manual processes to collect the data. Some software products crawl your various ERP systems and collect the exposure information at a balance level, and other products allow each entity to upload or input their exposures to facilitate the centralized collection. Manual data collection trumps automated collection when the revaluation functionality of the system is not being used by subsidiaries.
Capturing balances at a point in time is the first piece of the puzzle. Understanding what will create changes in the balances through time is the next piece of the puzzle. What are the new transactions that will occur to change the balance? New revenue transactions that create receivables and new expenses that create payables are obvious, but don’t forget the accruals for tax, VAT, etc. Many balance sheet hedge programs survey their subs for current non-functional balances and the “expected balances” at next period-end. Rather than asking subs for what they consider irrelevant information (future balances) ask for what they consider critical financial information: expected revenues and expenses (by currency). Now we have balances in non-functional currency and changes expected to the balances.
Catch up on any of the parts from the Getting You to the Top series you may have missed.
- Part II. Exposure Validation
- Part III. Exposure Centralization
- Part IV. Forward Contracts
- Part V. Performance Reporting & Analytics
The next piece of the puzzle is understanding what rates are used to bring the new transactions into the financial statements. Some companies will use daily rates, while others will use a rate that is in effect at the start of the month; still others will recast activity that happened during the month to the simple average rate for the month. All three rates mechanisms are appropriate, though there are pros and cons to using each approach.
The effectiveness of a balance sheet hedge program will reflect the ability to execute hedges at the rate those new transactions are recorded on the financial statements.
The last key input is conversion activity. Almost all conversion activity changes an exposure. Converting cash from functional currency to Currency B creates exposure to Currency B. Converting B to functional currency reduces exposure. At the same time, paying Currency B liabilities with Currency B cash, or receiving Currency B cash in payment for a Currency B receivable does NOT change the exposure. Those payable and receivable exposures would only be impacted if functional currency were converted to or from Currency B.
The perfect data set for great balance sheet hedging, then, is:
- Quantification of existing exposures
- Quantification of the new activity that is going to create exposures in the period
- Understanding of the rate setting mechanism for that activity
- Control of the conversion activity, or at least know that it occurred before or at latest when it occurred.
Once you can source your exposures and understand their exchange rate drivers, you are ready to move ahead in the creation of a best-in-class balance sheet hedge program.
Revaluation is frequently turned off in ERP systems because entities understand that the FX Gain/Loss that the system is generating is inconsistent with the FX Gain/Loss on the exposures they are familiar with. This largely occurs when two currencies are involved in a single transaction – e.g., an expense accrued in one currency and paid with a second currency. An example would be accruing a JPY payable and closing the accrual with USD.
|JPY cost accrued:|
|DR Expense||JPY 100|
|CR Liability||JPY 100|
|then relieved with USD cash:|
|DR Expense||USD 1|
|CR Liability||USD 1|
|Resulting in a trial balance by currency that reflects:|
This results in the general ledger system revaluing a JPY100 liability long after the payment was made.
The good news is that the receivable and payable sub-ledgers are specifically designed to not allow this to impact those sub-ledgers, but frequently the cash account will incorrectly show a currency balance.
|Resulting in a trial balance by currency that reflects:||USD||JPY|
Now the automated revaluation routine will revalue the 100 negative IPY cash balance.
If you do not have controls in place to identify and correct these “shadow balances” they will continue to calculate and record FX Gains/Losses on closed transactions: a misstatement of earnings. A common detective control to identify this problem is requiring account reconciliations to be prepared by currency in the account.