Financial Aggregation vs. Straight Aggregation

Many vendors claim to handle complex consolidations, but there are several significant differences between the underlying engine that is needed to run financial data aggregation and the engine used to run straight aggregation or simple consolidations. Any vendor that uses Microsoft Analysis Services, Oracle Essbase, Cognos, TM1, SAP Hanna or a similar straight aggregation engine will face numerous challenges to address core financial consolidation requirements. Let’s examine this more closely.

Why it matters for finance success

Straight aggregation engines are not designed for the complexities of financial close, consolidation, currency translation, partial ownership, inter-company eliminations, journal adjustments, consolidation status, and cash flow algorithms. While they support some ability to manipulate data, a financial engine must provide complete flexibility down to the individual data cell with how numbers are conditionally calculated, adjusted, or audited. A financial aggregation engine also requires the ability to perform different calculations of an entity’s data based on its multiple positions within the same or alternate hierarchy. The auditing of data for each step in the process of how an entity is calculated, adjusted, translated, factored, and eliminated into each of its multiple parent entities can only be accomplished by a purpose-built financial engine. A straight aggregation engine isn’t designed for calculations that vary by parent or other complexities related to managing the financial consolidation  process. Attempting to deliver all of these requirements on top of a straight aggregation engine is unsustainable and it can cripple a large organization with any amount of financial complexity.

Why would anyone spend years writing their own engine when you could start on day one with an off-the-shelf straight aggregation engine?

In the late 1990’s, when Hyperion merged with Arbor and their Essbase product, a major objective of Hyperion’s business strategy was to use the Essbase engine for all financial products. On the surface, it seemed like Essbase could be used to replace HFM’s financial engine because they have some common multi-dimensional capabilities. However, after months of work to attempt to replicate Hyperion Enterprise’s core functionality, it was determined that the changes needed to enhance Essbase to be a financial engine would be extremely difficult to implement and they would fundamentally change the core of the Essbase product. In fact, some of the requirements such as the ability to vary adjustments and calculations by parent and the ability for custom business rules to operate at the data cell level would have required Essbase to implement interfaces that were inconsistent with the OLAP standards that Arbor was promoting.

Because Essbase is a stand-alone OLAP engine, it is unable to directly integrate multi-dimensional financial data with relational data (a.k.a., relational blending) to record transactional details, journal adjustments, attachments, calculation status, and custom solutions that require transactional data. Although some products use a relational database side-by-side with Essbase, that results in additional deployment complexities, data synchronization issues, and business rules based on Essbase that do not consider the relational data. A final conclusion was that true statutory consolidations isn’t feasible using Essbase. It was argued that Essbase should be used for financial planning instead of actuals because it’s OK for a plan to be an approximation. It was the conclusion that the purpose-built financial aggregation engine, now called HFM, was necessary to deliver on the requirements of finance that Hyperion Enterprise had served for so many years, but with a multidimensional model that was critical to enhancing management reporting capabilities that the market was demanding.  The end result was two separate products which created a whole new set of challenges. The inability to consolidate your forecast data using the same algorithms used to consolidate actuals, and the difficulty of reporting on them side by side without a multi-product integration effort is a major inconvenience to say the least.

Enterprise class customers with complex ownership, eliminations, currency translations, and cash flow require more financial intelligence than what comes out of the box in a straight aggregation engine to simultaneously meet the needs for actual and plan collection, aggregation, reporting and comparison.  For a company with any level of complexity, a true financial engine is not just a nice thing to have, it is a core requirement. The OneStream XF financial close and consolidation platform is anchored by a true financial engine with built-in data quality and integration to source systems. The same unified platform also contains user workflow, reporting, dashboards, analytics, a custom user-interface designer, and relational blending. This engine is the key to the successful deployment of multiple variations of financial solutions. There is simply no substitute for creating an engine from scratch with the financial fabric to accommodate the requirements of an enterprise caliber customer.

Don’t buy the hype

There are really only a few true financial consolidation systems on the market. Although many vendors claim financial consolidation as a core capability, most have settled on using a straight aggregation engine instead of implementing a purpose-built financial aggregation engine. Vendors that have enjoyed some initial success with planning-only solutions are now facing market pressures that are forcing them to inaccurately claim that they have true financial capabilities.

If you can’t consolidate and eliminate automatically at the first common parent in all hierarchies, without requiring any IC rules or needing to define IC relationships in each hierarchy, it is simply not true financial consolidation. In OneStream, building an alternate hierarchy for entities, accounts and other dimensions is a simple task, not a project.  Our customers can instantly view the results of partial ownership and how the business might look in a re-org, divesture or acquisition. Alternate hierarchies work in all dimensions and never require a duplication of data.

Calculation Status is another critical finance feature that isn’t built into straight aggregation engines.  A financial engine always and automatically informs the user about which entities need to be calculated, translated, or consolidated. Automatically recognizing status and where data has been impacted means you are only consolidating what is required at any point in time resulting in faster consolidations and a quicker time to insight.

Planning and more!

The benefits of the financial aggregation engine impact so much more than consolidating actuals. With OneStream XF, you don’t need a separate product with different business rules and an integration nightmare to process your planning activities. OneStream XF’s unified platform also encompasses all aspects of financial budgeting, operational budgeting, forecasting, and planning solutions.  Our customers are also leveraging the platform’s core financial intelligence, currency conversion, intercompany eliminations, allocations, spreading, and relational blending capabilities in their profitability, tax, account reconciliation, and other solutions.

Does your current solution perform true financial aggregation for all of your processes without complex integration efforts involving multiple products or multiple disparate applications? This is what truly separates enterprise class solutions from small market solutions.

Bob Powers is the CTO at OneStream Software and was the original architect of Hyperion Financial Management (HFM). This was the first product with an OLAP engine designed specifically for Finance. He was later responsible for Hyperion Strategic Finance (HSF) and assimilating the newly acquired MDM and UpStream/FDM organizations into Hyperion. After a long period working to integrate multiple incompatible products, Bob concluded that a new unified platform with a fully-featured financial engine was needed for businesses to manage their complex CPM activities. Bob is co-founder of OneStream Software and an original architect of OneStream XF.