Use of Global Accounting Hierarchies and Matrix Consolidation in Consolidation Reports

Introduction:

This blogpost delves in use of a flat organization structure with consolidation units (of a corporate group) assigned to a single consolidation group; and subsequent use of Matrix Consolidation to enable reporting at the level of various sub-groups and management reporting.

We give a brief background to the organizational setup, followed by set up of hierarchies. We then use these hierarchies in Group Reporting to demonstrate system’s ability to report at various nodes of the hierarchy, considering consolidation documents as well.

Background:

While designing the organization structure for consolidation processes within Group Reporting, all consolidation units (representing underlying group companies) are assigned to one consolidation group. Starting version on premise 1909, a flat structure with all consolidation units assigned to a consolidation group is the preferred direction of design. This design helps, among many, in ensuring no repeated processing of consolidation tasks; such as release of universal journal for companies on SAP and file upload (or data transfer) for companies outside SAP systems. This design also enables the system to perform elimination of intercompany transactions for the entire group in one go.

A common concern on a flat organization structure would be to meet all reporting requirements and sub group consolidations. For example, if reporting at a country level is required, where in consolidation units belonging to a particular country/region are to be reported separately. In the old world, this would mean setting up multiple consolidation groups and performing consolidation processes repeatedly. However, starting on premise 1909, users can meet such reporting / sub consolidation requirements by

• Having a flat organization structure
• Building custom hierarchies (consolidation unit / profit center / segment)
• Use custom hierarchies in Group Reporting apps

This blogpost describes the procedure for the same.

Key Business Drivers:

• Future proof Organization Structure design
• External Reporting / Statutory Reporting
• Management Reporting
• Fast Close

System Set Up

Organization structure:

In order to explain use of hierarchies in group reporting, we consider the below consolidation units being assigned to consolidation group HK99.

Above information is represented as a flat structure in the system as shown below. You can use ‘Manage Group Structure’ app to make the below setting.

Consolidation Unit Hierarchy:

To demonstrate the use of Hierarchy in Group Reporting, consolidation units are arranged in a hierarchy named CU99 as shown below. Fiori app ‘Manage Global Hierarchies’ is used to set up the same.

From the above, consolidation units 1010, AA99 and BB99 belong to hierarchy node CUG1 and similarly consolidation units 1013, CC99 and DD99 belong to hierarchy node CUG2. Both these nodes, CUG1 and CUG2 are assigned to the highest node CU99.

Users should be able to create multiple hierarchies, each for a different purpose and use them in Group Reporting reports. For example, in one hierarchy each node could represent a country and underneath could be consolidation units belonging to that country. And in another hierarchy, consolidation units could be arranged based on the nature of business they operate in.

Another advantage of these hierarchies is that they are time dependent. If there is a change in the hierarchy, for example one consolidation unit belonging to one node has to be moved to another node; the same hierarchy can be used in a different time frame, and the report will reflect the new change.

Profit Center Hierarchy:

Like the Consolidation Unit Hierarchy, a profit center hierarchy named PC99 is set up as shown below.

Data Monitor and Consolidation Monitor:

All tasks in Data Monitor are completed and are followed by Consolidation Monitor. Upon execution of Consolidation Monitor, elimination entries (usually with posting level 20) and consolidation of investment entries (usually with posting level 30) are posted. Once this is complete, users can proceed to reporting over the consolidation group.

Use of Global Accounting Hierarchies and Matrix Consolidation in Group Reporting:

We use the Fiori app ‘Group Data Analysis’ to demonstrate scenarios in which hierarchies are used.

Clicking upon the Group Data Analysis app, below section screen is displayed.

Update this selection screen with values pertaining to your reporting parameters. The Consolidation Unit Hierarchy and Profit Center Hierarchy created in the previous section is also updated in the hierarchy fields.

The output of the report would be something similar to the one below.

Bring in the custom created Consolidation Unit hierarchy, CU99. Right click on the Consolidation Unit Elim dimension.

System then modifies the output as shown below.

We would further narrow down the output on this report to explain functionality of using hierarchy for reporting at multiple levels. Select Filters button on the top right corner of the report to add additional filters to the report output, as shown below.

The report output is now restricted. This is done purely to enable ease of reading of the screenshot with minimal data.

Once you expand the node CU99, below is displayed.

From the report, it is understood that, under FS Item 121100, a value of EUR 914.81 is posted in cons unit AA99 with partner unit CC99; and is thus displayed under hierarchy node CUG1. [See item marked as 1]

Similarly, under FS Item 121100, a value of EUR 2744.43 is posted in cons unit CC99 with partner unit AA99; and is displayed under CUG2. [See item marked as 2]

Therefore, a report under CUG1 or CUG2 nodes provides financial information pertaining to Consolidation units assigned under them.

Moving one step higher, the report displays a virtual dimension with suffix ‘ELIM’; CU99_ELIM in our case; to show consolidated data combining information from both nodes CUG1 and CUG2. Under this virtual dimension, system displays elimination of EUR 2744.43 against partner unit AA99 and similarly elimination of EUR 914.81 against partner unit CC99. [See item marked as 3]

Overall, at the highest node CU99 the report displays, against partner unit AA99, an original entry (at posting level 00) of EUR 2744.42 and its elimination (at posting level 20). And against partner unit CC99, system displays original entry (at posting level 00) of EUR 914.81 and its elimination (at posting level 20).

We now change the filter in the report to a different FS Item to further explore reporting functionality using hierarchies. The report filter is updated with FS Item number 585000, and the report displays below information.

One immediately notices that the virtual dimension CU99_ELIM described in the previous section is no more displayed. We open hierarchy node CUG1.

We see a posting of EUR 1840.80 under cons unit BB99 against a partner unit of AA99. Since both AA99 and BB99 are assigned under the same node in the hierarchy, the system displays a virtual dimension (CUG1_ELIM) under this node to eliminate this posting. Therefore, under this dimension you will see an elimination of EUR 1840.80 with partner unit AA99. [See item marked as 1, 2]. Therefore, balances under hierarchy CUG1 includes original entries on consolidation units (posting level 00) and any elimination between consolidation units within the hierarchy node CUG1. [See item marked as 3]

On expansion of hierarchy node CUG2, you notice similar transactions between CC99 and DD99. Therefore, the system displays a virtual dimension CUG2_ELIM under node CUG2. Balances at node CUG2 includes all original postings (posting level 00) against consolidation units assigned in this node, and the elimination entries between consolidation units within this node.

The highest node CU99, displays all entries (both posting level 00 and elimination entries under posting level 20) as shown below.

The above describe some scenarios in which system uses custom consolidation unit hierarchy to present results at different nodes. The virtual elimination member (with node name ending _ELIM) is automatically generated to aid in reporting. This is commonly referred to as on the fly elimination.

On completion of Calculate Group Shares and Consolidation of Investment steps, documents are posted at level 30. Such documents too can be viewed in the above described reporting methods. System does not limit reporting abilities based on the flat organizational structure set up, and uses the consolidation unit hierarchy to report at various sub groups of consolidation units.

Profit Center Hierarchy in Group Reporting:

As described in the previous section for consolidation unit hierarchy, profit center hierarchies could also be used for reporting at various nodes of profit centers.

Below is a brief example of usage of Profit Center Hierarchy in group reporting. Bringing in Profit Center Eliminated dimension into the report selection, and selecting PC99 hierarchy (created for this blog post); system introduces the virtual elimination member (ending with _ELIM). The report is narrowed down for postings with FS Item 121000 only. Transactions against profit centers belonging to hierarchy node PCG1 and PCG2 are eliminated under the higher node PC99.

Conclusion:

Starting on premise 1909, we move in the direction of having a flat organization structure with all consolidation units assigned to the consolidation group. This does not stop us from enabling reporting at various levels or sub groups of consolidation units. Users can build any number of hierarchies and use them in group reporting to report at, say country level including all consolidation units belonging to a particular country/region. This functionality is also available for other dimensions such as Profit Centers, Segments.