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.
