One of the topics that I have spent time on is to understand the most efficient way to restate reported data in HFM.
On one side, there are multiple applications which either do not handle this requirement or the process to maintain and analyse the data is too complicated.
- The most usual case is to restate the P12 data. To handle this requirement, there are applications with an additional period P13 to handle the late adjustments. I think that this approach has been inherited by the design of the most ERPs.
- Another case is to restate the data from all the periods and not only the P12 data in case of a change in the reporting standards or an audit. In this case, there are applications that have a specific scenario which is called RestatementX.
- In a similar case of restatement, in order to restate the data of all periods, the application had two sets of accounts. The accounts with the reported data and the accounts with the restated data. The restated accounts had the accounts with the reported data as share members in addition to the unique restating accounts.
- Finally, there are applications that do not maintain the reported data and before posting the adjustments, the users must run and hardcode all the values in order to keep the reported figures (bad, bad, bad)
On the other side, HFM is a really powerful and flexible tool and we should use it in order to transform the focus of our processes from data intensive to data analysis.
This means that we should be able to restate our numbers without much effort, without having to copy data from one scenario to another or one period to another and at the same time allow us to audit the numbers and trace the flow of the change. The easiest way to implement such change is to introduce a new dimension in the HFM application (HFM version 11 has unlimited number of dimensions) which will allow us to introduce versioning.
As an example, let’s say that you will use Custom5 as your version dimension. Custom5 will have 3 members: [None], Restatement and AllCustom5. The [None] member will be linked with Phase 1 and the Restatement member will be linked with Phase 2. The process is simple. The users will load all the initial data in the member [None] and you will lock Phase 1. These data are the reported data. When you will need to Restate your numbers, the users will load any adjustments in the member Restatement and you will lock the Phase 2.
In this way, when you will retrieve data from [None], you will read the reported data and when you will retrieve data from AllCustom5, you will read the restated data.
Disclaimer: The above example is really simple and will not cover all the cases. Allow your phantasy to work and adapt this mechanism in your requirements.