by Jim Shepard
In today’s world of technology, the Enterprise Resource Management (ERP) system is the key to quicker, faster accounting results required by an ever more demanding list of stakeholders. Frequently, these systems require some if not substantial customization to meet a company’s specific accounting requirements. While customization is a good thing when executed properly it can also create risks when future upgrades (from versions 1.X to 2.Y) require similar customizations. This past month a client notified us of an issue that arose in the foreign currency translation process related to their migration to version 2.0 of their ERP software. This flaw may have been in the software upgrade, the local configuration, or both but if it had not been uncovered and rectified it would have improperly stated the Company’s earnings and EPS.
Here’s what happened: A USD denominated transaction was entered on a GBP local currency functional set of books. Under ASC 830 the non-functional monetary asset ($100 A/R for our purposes) is required to be remeasured from the income statement rate at which it was booked to the month end balance sheet rate. The GBP asset value changes and an offsetting entry is recorded in foreign exchange gain/loss in GBP on the local set of books. This step went like clockwork and was recorded properly. Next the local financial statements were translated from GBP into USD to allow the Company to combine numerous foreign subsidiaries’ books into a single consolidated USD set of financial statements. This is where things went awry. The GBP exchange gain/loss (calculated on the USD remeasurement) should have been translated into USD at the income statement rate.
The result should have been a USD exchange gain/loss in the P&L reflecting the original GBP exchange gain/loss recorded on the local set of books at the company’s income statement rate. What did happen was technologically slick (and perhaps the answer to many a Treasurer’s dream) but was the wrong accounting result. The system instead looked to the original $100 A/R transaction and bypassed the required transition through GBP to USD. During the translation process, the original GBP exchange gain/loss and related CTA effect were unwound. As a result the FX gain/loss in consolidation was ZERO (nada, nothing!). The gain or loss had evaporated in processing the translation. (See exhibit A for details.) This result is convenient, but not GAAP.
Misapplication of the debits and credits associated with foreign currency transaction and translation accounting will misstate a global company’s net income/EPS. Fortunately in this case the client reviewed the FX gains and losses and CTA generated by the new system prior to going live. We strongly recommend that when migrating to new software or upgrading existing software that the migration team identify strong technical internal or external resources to assist in evaluating the currency accounting.
If you lack internal resources, Hedge Trackers is able to guide your implementation or migration teams on appropriate testing of currency functionality. ERP consultants are generally familiar with how to program the software, provided the company delivers very clear and concise requirements. Unfortunately, companies frequently assume that the programmers “know” how currency accounting should work, or they just assume the currency elements of the system will work correctly which is not always the case. We encourage our clients to participate in migration or implementation teams to spearhead the effort to validate the impact of currencies on your financial statements.
Need to refresh your understanding of currency accounting under ASC 830: Foreign Currency Matters? We offer basic through advanced classes. Find more information on currently scheduled webinars and training classes.