By Mike Arnoldy
September 28th, 2011
My last blog discussed the changes to a Hyperion Financial Management application with a granular chart of accounts in order to support IFRS. Now let’s take a look at the changes required for an application that has a summarized chart of accounts. If you have this type of application, adopting IFRS is going to require a substantial amount of work and will probably result in a completely new application.
Many companies have designed their Hyperion Financial Management application with a summarized chart of accounts. There are two main reasons for developing a summarized chart of accounts:
- To reduce the size of the application. A large company may have thousands of accounts in their transaction system. This level of detail may not be needed for the consolidation so a smaller chart of accounts is developed.
- In a large company, there may be multiple transaction systems each with their own unique chart of accounts. The Hyperion Financial Management application is then developed to contain one common chart of accounts so that the data from these multiple transaction systems can be combined.
In this type of application, the summarized chart of accounts was designed to support US GAAP financial statements. The base accounts in HFM represent multiple accounts from the transaction systems. Since the application does not have the base level accounts from the transaction systems, a new account hierarchy will need to be built with the new base HFM accounts representing a different set of accounts from the transaction system. This change in what a base account represents in HFM will result in changes being required to all of the data load processes. The current load processes, whether in FDQM or some other tool, utilize a map to direct transaction system accounts to the HFM accounts. These maps will need to be changed. With a new chart of accounts, the rules will need to be rewritten. In addition to this substantial amount of work, the changes to the reports that we mentioned in the last blog will also need to be done. It is the magnitude and scope of these changes that lead me to believe that a complete rebuild of the application will be required.
With any build of an application, we have to address one of my favorite topics: data validation. Generally I would view the validation of a rebuilt HFM application to the original application to not be very painful. But in this case, this validation will be difficult at best. Having to validate that mappings are correct always adds time to a data validation effort. Depending upon how IFRS is adopted, there may be a need to load more history than normal to support comparisons to prior years. In sum, it is going to be very challenging to find the common points when validating a US GAAP chart of accounts to an IFRS chart of accounts. I hope that I am wrong, but until we actually do some of these validations, we have to assume the worst. To be on the safe side, you should also assume the worst when looking at a project like this.
If your application has a summarized chart of accounts, most likely you are looking at a major project to implement IFRS. I would plan on a complete rebuild of the application and I would allow a lot more time than you expect for the data validation effort.
My next blog will look at getting ready to implement IFRS.