When a country is approved for adoption of the Euro, a flurry of activities results as each entity in that country prepares to change its functional currency. Countries that are adopting the Euro are plentiful: Latvia did so on January 1, 2014; Lithuania has been approved to move forward with the adoption of the Euro on January 1, 2015; Poland is in preparation for adoption, with the Polish government asserting that the changeover is one of its top priorities; and the Czech Republic, Croatia, Hungary, Romania and Bulgaria are all expected to adopt within the next five years. As the Eurozone’s reach grows, so does the level of accounting implications that need to be considered.
Indeed, there are many essential tasks that need to be completed beyond Enterprise Resource Planning (ERP) system financial reporting – such as exchanging on-hand currency for the Euro, ensuring that insurances are updated to the appropriate values, etc. Yet still, ERP considerations are critical, and for entities with Oracle® E-Business Suite, one of the most significant changes to be addressed is affecting the functional currency change within all ledgers (or sets of books in 11i).
International Accounting Standards
For countries that adopt the Euro, specific changes must be made to comply with International Accounting Standards (IAS) standards. Based on IAS 21 (and related Standards Interpretation Committee SIC guidance), in the initial year of the currency change, the customer must account for the currency exchange differences prospectively – that is, the differences in the exchange rate are classified in equity within the cumulative adjustments account (CAA). Specifically, IAS states it as follows:
From International Account Standards (IAS) 21 (Consolidate version from the European Commission):
- Paragraph 35: “When there is a change in an entity’s functional currency, the entity shall apply the transaction procedures applicable to the new functional currency prospectively from the date of the change.”
- Paragraph 37 “Exchange differences arising from the translation of a foreign operation previously recognized in other comprehensive income in accordance with paragraphs 32 and 39(c) are not reclassified from equity to profit or loss until the disposal of the operation.”
- Paragraph 41: “These exchange differences are not recognized in profit or loss because the changes in exchange rates have little or no direct effect on the present and future cash flows from the operations. The cumulative amount of the exchange differences is presented in a separate component of equity until disposal of the foreign operation.”
The Cumulative Adjustments Account
In the example of the Lithuanian company below, there are other entries that hit the CAA account in the ordinary course of financial reporting, but the portion of the balance to which the functional currency change relates is permanent until such time as the respective company or company/entity is disposed of, at which time the balance is reclassified as gain or loss.
From an accounting standpoint, this means that on the day prior to the adoption, the temporary accounts (profit and loss accounts) will be closed out to retained earnings. Using Lithuania as an example, on January 1, 2015, there will only be permanent accounts (balance sheet accounts). The next step will be to restate all the permanent (balance sheet) accounts into the Euro. There will be a difference – quite possibly a sizable one – and this difference will then be booked to the CAA account. In theory, this is a remarkably easy change; but as in all things that appear simple, things will likely be more complicated than what is initially thought.
Effect on Subledgers
In reality, the complications begin when you begin to consider the effect on subledgers. Although from a general ledger view, the change only took a few top level entries, all the transactions in the respective subledgers are still denominated in the legacy currency, not the Euro. Ideally, when determining the general ledger balance, subledger related accounts should have been done “bottom up,” meaning each open transaction within the subledger should be adjusted to reflect the currency change with the total of all changes then booked to the general ledger. If there were only a handful of open transactions, this might be doable, but for most subledgers (such as accounts receivable), the sheer number of open transactions at any time can be very large.
For companies where it is just not feasible to convert each subledger transaction, an alternative approach is to convert the general ledger level balances and then make a “currency change” transaction within each subledger or a “currency change” asset in the FA book to make things match up. For the subledger transactions denominated in the legacy currency, there will be a foreign exchange (FX) gain or loss each time a transaction is settled (paid or payment received). Normally, the FX gain or loss is to reflect the difference between the entered currency and the functional currency. For example, if the entered currency in a transaction is in US dollars, but the functional currency is the Euro, then any amount of change between the date of original entry and final payment would be recognized as FX gain or loss at the time of settlement. The problem is that this is not a difference between entered currency and functional currency; instead every transaction that was entered in the legacy currency should have been restated to the Euro, with the related general ledger account being restated by the summed changes of the underlying transactions. The “currency conversion” open transaction in the subledger would equal this difference. Then for each transaction still in the legacy currency, the FX gain or loss recognized on final settlement (payment or receipt) would have to offset against the “currency conversion” open transaction. Then a settlement against the placeholder item would need to be booked to offset the incorrect gain or loss. It is important to note that no gain or loss should flow through the income statement respective of any open transactions denominated in the legacy currency. Once all transactions open at date of currency change are settled, the offsets should zero the placeholder item. Again, given the transaction volume typically in a subledger, this method will involve much accounting staff time each month.
For fixed assets, each asset and its related accumulated depreciation account must be restated. Again, a bottom up approach would be best, but depending on the number of FA book assets, the task could be daunting. A similar approach to the subledger placeholder item approach could be used for fixed assets, but because the month to month adjustments would need to be reconciled to depreciation schedules, this would likewise entail much accounting staff time each period.
A change in functional currency may appear straightforward, and it is when looking at the top-level general ledger accounts. The problems arise when dealing with subledgers and fixed asset books (ledgers), and these should be planned for. In addition to the intensive approaches discussed above, other solutions include implementing software to change functional currency, or working with consultants to set up new ledgers and migrate the open transactions and fixed assets. When comparing these options, the key piece is ensuring that solution comparisons are made using total cost, and taking into account ongoing staff time, the need for external spreadsheets, and estimated consulting hours