“The universe is change; our life is what our thoughts make it” ~ Marcus Aurelius
The nature of a statutory consolidation model must be one that inherently is designed to allow change and indeed automate it. This must be done not only in a controlled manner, but one that allows for easy analysis of those changes.
The most logical form to allow these changes to be made is in the form of an accounting journal at both Company (and so Company currency) or Group (ergo Group currency) level. This forces the user to conform to the controls that would always be required such as balanced entry, required analysis codes etc. This requirement to create journals is why, traditionally consolidation platforms have been built in relational environments. Relational environments generally can be considered OLTP or transactional processing environments. This makes them very stable for the creation and referencing of journals, similar to within a ledger environment. These though, tend to be slow, requiring data to move through and across data, with transformations and calculations occurring from one table to another. Hundreds of tables can result, creating a minefield for the analytical user.
The last few years has seen a tendency for the creation of full statutory consolidation models to be built in OLAP (On-Line Analytical Processing). This gives the computational abilities of in memory calculation combined with the free aggregation along a dimension to provide a simpler model to navigate. Gone though is the robust transaction engine needed for journaling, that oh so important function in any consolidation platform.
As I mentioned in my last piece, I long ago settled on Infor d/EPM as my tool of choice (and I’m qualified on two others, was involved in the development of a third and have consultant level knowledge on three more). A factor in making this decision was Infor d/EPM being a hybrid tool. Whilst the user may not know (or care) d/EPM leverages both OLTP and OLAP technologies, blending them seamlessly together. Journals are stored in a relational table and the summary positions loaded to the OLAP cubes. It makes the whole model incredibly stable, quick and easy to process.
The other winning feature is the lack of need for an adjustment company. For a long time the improvised solution of choice for Finance Consultants, the adjustment company allows for the posting of consolidation journals into the ledger system, which can then just be aggregated with the other companies to give a group total. This method has a lot of flaws; what do you do if not all companies are on the same ledger platform? What do you do with or indeed calculate group currency adjustments? If the company is in group currency what do you do with an adjustment to make in local currency? Manage complex ownership issues such a direct and indirect MI? The list goes on…
The OLAP component of a good consolidation platform will include a dimension for adjustments. This dimension will have elements representing the classification of journal being posted such as reclassification, GAAP Adjustment, Capital Elimination or something as esoteric as fair value adjustments. What this means in reality is that for any account in any company a full audit trail can be provided showing how this balance from the ledger system was changed to reach the final contribution for the group position. No more chasing around to find out which intercompany debtor in which company wasn’t taken into account when you posted that two line journal in a dummy company that removed interco debtor and creditors in one fell swoop. No more having to prove your adjustments to auditors.
Embracing a platform that allows change shouldn’t be about losing control. It should be about empowering users to make the changes they need to bring clarity, simplicity and auditability to the consolidation process. The consolidation universe is definitely about change.