Solving Oracle HFM Consolidation Issues


October 30th, 2015

Accounting means assigning the correct numbers to the correct accounts in the correct time period. Consolidation means combining the accounts of several entities according to accounting rules.


As the administrator of Oracle Hyperion Financial Management (“HFM”), your job is to support the application that produces the consolidated results. Key to supporting the application is debugging consolidation issues in it. Let’s talk about how to do just that.

Perceived consolidation issues will normally be communicated to you by an accountant. Often these issues will be both urgent and highly visible to management, therefore it is wise to have a clear action plan:

Action Plan

The steps in the action plan are contained in the following list:

  1. Define the problem
  2. Construct a Smart View of the POV
  3. Determine where the issue starts
  4. Look for recent system changes
  5. Apply heuristics
  6. Test the solution
  7. Implement the solution

In the entire process it is important to be a good detective: don’t make assumptions; go where the evidence leads you.

Step 1 – Define the Problem

To define the problem, you will need, at a minimum, the following information:

  • Application
  • Account
  • Entity
  • Year
  • Period
  • Amount should be
  • Does the problem cause an out of balance?

Step 2 – Construct a Smart View of the Above POV

The second step is to construct a Smart View of the POV above. This will help to determine when the problem is solved.

Step 3 – Determine Where the Issue Starts

The third step is to determine where the issue starts. Follow the amount from the ERP system, through FDM, to HFM with the objective of determining in which app the problem originates. Obtain the data load file to determine if the base data is the problem.

Step 4 – Look for Recent System Changes

The fourth step is to look for recent system changes. For HFM the system files are the rules, lists, and metadata, and security. For FDM the system files are maps, locations, scripts, and security. Having a good set of system change logs is extremely useful at this step. Often the cause of the issue will be obvious. A system change in the rules can affect number from the time the change was made. The same is true of changes in lists, or changes in attributes on metadata, to the extent that these lists or metadata attributes are referenced in the rules.

Step 5 – Apply Heuristics

The fifth step is to apply heuristics. Heuristics are rules of thumb based on past experience. One rule I have discovered is to first re-consolidate, I use consolidate all. This has solved several issues. Another rule I have discovered is that if I see an account that rises with time but causes no out of balance, I suspect an FDM mapping change. Another technique I have found useful it to consider if data is being loaded into a previously unused POV.

Step 6 – Test the Solution

The sixth step is to test the solution. I usually either copy production to dev, or just update the system files: rules, lists, metadata, and the data. I make it a rule to always test changes before going into production. This is a known IT principle, but it is sometimes ignored in the heat of battle, often with adverse consequences.

Step 7 – Implement the Solution

The seventh step is to schedule the implementation in production. This step just involves communication and coordination.


In the end, HFM is a solid, proven, consolidation tool and by following proper administration techniques, and having some key troubleshooting tips in your pocket, you can usually avoid late night calls.


About TopDown Team

The TopDown Team includes members of TopDown Consulting who want to let the community know about webcasts, conferences, and other events. The team also conducts interviews on various EPM industry topics.

Leave a Reply

Your email address will not be published. Required fields are marked *