You’re only as strong as your weakest link, and when it comes to financial reporting, the weakest link is often offline adjustments—the forgotten piece of financial data and often the unplanned ‘gotcha’ when it comes to implementing an EPM solution.
The reconciliation process of an EPM project is usually where you discover the offline adjustments people forgot. This is because organizations inevitably approach an EPM project with the idea that their data is clean. The reality is that because the data resides in a spreadsheet, or some other free-form environment, some of it is clean and some of it isn’t. Most of the data starts off as well defined since it is sourced from your GLs and is reformatted to fit a specific presentation. But then there is invariably a need to make some type of reporting adjustment (often at the last minute), and these are usually done at the reporting line level. These reporting lines are not part of the GL metadata definition and are many times based on the aggregation of an intersection of data. As a result, what organizations expect is going to be a check-in-the-box process is often more complex because data is not what or where they expected it to be—at the true input level.
To get a realistic picture of what is involved in reconciliation, the first step in the EPM project is to acknowledge that data is not solely sourced from the GL. Next is to be aware of what happens to your data and who is involved in preparing the various financial reports used in your organization. Recognition of this and the issues/complexity this brings to your implementation will enable you to better assess the time and resources needed to perform this critical phase of the project.
Ok, I’ve done my analysis and determined where our data is and who owns it—what’s next?
In an EPM solution, the core foundation is your metadata, which is usually based on your ERP structures. Your data is loaded or input at the lowest level (sometimes referred to as the Base or Level 0 member) and consolidated/aggregated to the parent levels (ex: your report lines).
Now you need to decide where to put those reporting adjustments in your EPM Solution. There are three options most consider.
The first option is usually to load the adjustments to the report line members directly. This may appear to be the simplest method but can confuse users as they drill down since the data in the children’s level doesn’t add up to the parent level.
The second option is to load these adjustments into existing base members. This will ensure that the children add up to the parent, but depending on your application structure you may end up changing the source GL data and/or potentially lose your data trail.
The third option is to create new base members and define them as adjustment members. While these will be outside of your GL definition, it does make it clear what these adjustments are and will increase the awareness of these adjustments so that you can make the changes necessary to minimize these adjustments going forward.
By going through this process, you will be able to better prepare yourself and your project team by providing a clear picture of what to expect when entering the reconciliation phase of the project.
All to say, when undertaking an EPM project, your data is never as clean as you may think it is. So be realistic about what it is going to take to discover and account for these types of reporting adjustments in your project. The process might be painful and slow, but the effort is worth it and will ensure you have a consistent, accurate, unified view of your data.
