BLOG
Insight to All Things Currency and Treasury Management

ERP conversions, migrations, and upgrades are a necessary occurrence for all global organizations. Yet they also greatly impact the day-to-day life and operations of corporate treasury and accounting teams. Whether I am talking with our current client base, potential clients, or simply gathering market data from obliging finance organizations, at FiREapps I often hear of plans put on hold or scrapped because the new system did not include fundamental aspects necessary for accurate financial reporting.

Although concern around the timing and level of involvement required for a migration or upgrade is understandable, the primary focus of treasury and accounting should instead center on the configuration of the new system and the integrity of the data being transferred, as this is where the majority of issues arise.

When our clients contact us about a future upgrade or proposed migration, we guide them through the process to ensure they avoid these pitfalls. We begin by suggesting that they ask the following five questions:

1. Does the new ERP system support multicurrency accounting?

For most multinational companies this question sounds rhetorical. But the fact is that the team responsible for designing and supporting the ERP setup and configuration may not necessarily consider how important multicurrency accounting functionality is for the finance organization.

In the last year alone we have helped redesign a handful of upgrades where the original plan was to change the financial system of record to one that did not have multicurrency data capabilities or reporting and therefore could not support the financial reporting requirements of the global company.

2. Does the planned configuration of the new ERP system leverage the multicurrency accounting functionality?

I have seen numerous situations where the finance team assumes that because the system has the functionality, it is being utilized. Let me assure you, that is not always the case! Having visibility into transaction currency balances is essential for exposure identification. If this functionality is available but not enabled, not only is the system not being fully utilized but the transaction details and exposure data will be lost as soon as balances are posted to the new system.

3. Will all balances be migrated in the original document/transaction currency?

Once you have confirmed that the configuration of the new system supports multicurrency accounting, the next step is to begin discussing the data to be transferred over – specifically, that the balances will retain their original transaction currency detail when they are posted to the new system. Overlooking this step by converting all balances to a common value such as local or reporting currency for ease of migration has a devastating impact on exposure calculations; it essentially removes all visibility the treasury and accounting teams have to original account balances prior to the migration. We equate it to replacing valuable historical data with an impenetrable black box.

In this situation the treasury teams need to vocalize the importance of transaction currency detail for their exposure calculation and the risk of having to implement a manual work-around to accommodate the lack of information transferred to the new system.

4. Will all life-to-date historical balances be migrated?

Even if the integrity of the original document/transaction currency is maintained, if the life-to-date historical balance is not transferred properly, the treasury and accounting teams lose visibility to information that was posted in the old system. Although complete visibility may not be lost, likely there will be holes in the exposure definition going forward; over time and additional upgrades, these holes may become increasingly significant and detrimental to accurate financial reporting.

5. What is the planned phasing of the migration and anticipated testing periods for each phase?

Most migrations have several phases that last many months. With a properly phased plan, the treasury and accounting teams can participate in the migration process by testing and confirming that the new system is operating as designed, that balances are being populated and migrated correctly, and that the exposure definition does not change from one system to another. This process will naturally promote team collaboration, but should also include separate cross-reference and validation of balances by treasury and accounting.

Proper phasing also ensures there are no gaps in accessibility to balances and/or glitches in reporting from one period to the next. By investing a small amount of time to test the configuration and data integrity during each phase, the treasury and accounting teams can ensure that the transition is smooth and that the value of the new system is fully realized.