- March 30, 2015
- Posted by: platformspecialists
- Category: Financial Consolidation & Close, HFM, Hyperion EPM
This post goes out to all the Finance people that chose a life without audit and CPA requirements. For all of you who had to sit in meeting after meeting listening to people gripe about External Reporting and US GAAP and IFRS and Actuals, Actuals, Actuals!
For every decimal out of place, for every foreign exchange rate difference, for every historical override, and especially for every Intercompany Elimination. The list of insider terms and jargon goes on and on…
Well,we’re here to add a little clarity and understanding to the financial consolidation process. First off, what is a consolidation? Essentially, in corporate finance terms, consolidation is the process by which a company combines the financial data from various business units, legal entities, etc. into a broader parent company for reporting purposes.
With that said, some may think that consolidation is as simple as adding the sum of all the parts to get to a total, especially for External Reporting. While this is obviously the crux of the process, there is a bit more going on underneath the hood.
A great way to understand a financial consolidation is to break it down into 3 core processes below:
- Sum up the data by financial reporting structures (e.g. Departments rolling up to Segment, business or legal Entities rolling up by Region, Accounts rolling up by major Financial Reporting line items, etc.)
- For multi currency applications, the process of translating from local currency into any other currency, as defined by a company’s Entity structure / dimension (e.g. Needing to report a EUR entity in USD)
- Transactions between two Entities within an organization must be netted to zero, since a company cannot generate net activity from itself. (e.g. Intercompany Receivables should offset Intercompany Payables)
To accomplish the above, HFM, Oracle’s consolidation system, utilizes the Value dimension. Some say this is where all the magic happens.
If you’ve ever ventured into HFM or are familiar with its dimensionality, you may have come across the Value dimension. For those without a deep background in HFM, this dimension can be a bit of a black box. We’re here to help with that.
At first glance it appears flat and uninteresting. But as you peel away the layers, you can start to understand the transformation that this dimension allows your data to have during the consolidation process. Let’s go through that step by step.
Let’s start with Entity Currency. This is where an entity’s local currency data gets stored and it works in conjunction with the currency attribute assigned to that entity. For example, if a USD based company has sales offices in London and Tokyo, their Entity Currency data will be in GBP (British Pound) and JPY (Yen), respectively.
Entity Currency Adjustments
After Entity Currency comes Entity CurrAdjs, which represents journal adjustments, performed in local currency through the Journal module of HFM. Going back to our London sales office example, let’s say they closed the books for the month on workday 4. After careful analysis on workday 7, they find that their sales accrual was short by 100K GBP.
If timing doesn’t allow for the rebooking of the transaction to the GL, they will book the transaction topside in HFM. This 100K GBP effect is stored in Entity CurrAdjs to allow an audit trail showing what was loaded from the GL (Entity Currency), and what was journaled directly in the system (Entity CurrAdjs).
Entity Currency Total
This is nothing more than Entity Currency + Entity Curr Adjs. It is the total local currency inclusive of adjustments and loaded/submitted data.
Next up the chain is Parent Currency. This member takes total local currency (Entity Curr Total)and translates it to the currency of its immediate parent in the entity hierarchy.
Back to our good old friends across the pond in the London sales office, since they roll up to a Euro parent company, the system will translate from GBP to EUR when the consolidation goes from Entity Curr Total to Parent Currency.
The above shows a translation from GBP to EUR using a currency rate of €1.25 to £1.00
Parent Currency Adjustments
Up from Parent Currency is Parent Curr Adjs.
Parent CurrAdjs is an intersection that allows users the ability to book an adjusting journal in the currency of the entity’s parent. It is NOT the Entity CurrAdjs translated. Recall that Entity Currency and Entity CurrAdjs get added together at Entity Curr Total, which then translates to Parent Currency.
Let’s assume that the London sales office had to book a 150K EUR adjustment. Instead of figuring out what that amount is in GBP and booking in Entity CurrAdjs, the sales office has the option of booking the 150K EUR straight to Parent Curr Adjs.
Parent Currency Total
As before, the totals for Parent Currency and Parent CurrAdjs are added together to get to Parent Curr Total, which is the total post-translated amount inclusive of any parent currency adjustments.
For the purpose of simplification, we will jump ahead to the Elimination Value dimension member. Though there are other Value dimension members between Parent Curr Total and Elimination, these are not typically used other than for percent ownership, equity pickup, and blah blah, accounting speak, blah debit, blah, credit. We’ll save that for another time.
Elimination. The one word that can make anyone cringe when it comes to data tie out or passing of data between systems. Eliminations are necessary when two entities that belong to the same organization have activity with one another. Though it is important to be able to see that activity at the entity level, it has to be zeroed out at the appropriate consolidation point. After all, a company can’t make money off of itself (we’re not running a Ponzi scheme here).
Why do we need to load Elimination data if it just nets to zero? Valid question – if it doesn’t net to zero, or if it zeroes out across levels, it is important to have the detail to support all of the activity. Enter the Elimination dimension.
To keep it simple, let’s say that Company A has a receivable from Company B. Company B should have the offsetting Payable on their books.
That intercompany transactions between Company A and Company B are not eliminated (zeroed above) until the first common parent of each company is met. To keep things simple, let’s just say that both companies roll up to parent Company AB. This is where it will eliminate.
Contribution represents what ultimately gets passed from child to parent. Keeping it simple, it is equal to Parent Curr Total + Elimination. This total then gets sent up the chain to its parent’s Entity Currency member.Seen below, Entity Currency for the parent entity (Total Europe) is the sum of the Contribution amounts from each of its children (London & Zurich).
Now, putting it all together, hopefully you should be able to make some sense of Oracle’s diagram of the Value dimension, seen below.
And then the process starts all over again…
…with Total Europe at Entity Currency and continues upwards through the Value dimension and, ultimately, gets to total company consolidated financial statements.