What is SAP S/4HANA Group Reporting?
Group Reporting is SAP’s newest consolidation tool, which is fully integrated within the overall SAP S/4HANA platform. This tool can produce a consolidated output based on either universal journals that are released directly from SAP S/4HANA Finance and also from additional data sources that can be integrated with this tool.
What is the SAP Best Practice Content?
To activate SAP Group Reporting within S/4HANA, an additional scope item must be deployed called 1SG. The 1SG scope item contains all applications that comprise Group Reporting plus all underlying transactions that support this tool. This scope item also contains a pre-configured set of functionalities comprising data submission tasks, data validations and consolidation processes. In general, most major aspects needed for the implementation of Group Reporting. This pre-configured content is referred to as the Best Practice Content for Group Reporting.
In this article, we will do our best to describe the components of the Best Practice Contents plus the points that should be reviewed and analysed during the design phase to ensure the best outcome for the implementation of Group Reporting.
Generally speaking, the Best Practice Contents contain the majority of processes that are applicable for most implementations of a consolidation tool. As such, its contents can be used as the basis for most implementations in conjunctions with a “fit-gap” analysis that should be performed at the start of an implementation. The Best Practice Contents plus the output of this “fit-gap” analysis would then ensure that Group Reporting is fully integrated within the client’s overall financial reporting architecture. If the outcome of the “fit-gap” analysis requires too many changes, the Best Practice Contents can also be used solely as a reference point while the re-built functionality is created alongside the Best Practice Contents.
To ensure that your implementation of Group Reporting is a success, it is best to start off by understanding what SAP has already configured in its Best Practice Content and how it can be enhanced. SAP is constantly investing in Group Reporting’s functionality plus the scope of their Best Practice Content, so this article may be out of date in a year, but we will do our best to make this content as relevant as possible in the future.
What are the principal aspects of SAP's Best Practices?
The Best Practice Contents include the following major aspects.
- Chart of accounts – An example group chart of accounts is included in the Best Practice Contents. This chart of accounts will probably not be re-used by a client; however, one of the following sections of this document sets out how the various consolidation processes have been built with this in mind so that this example chart of accounts can be replaced without the need to re-build all existing consolidation processes.
- Details analysis for accounts – A pre-existing set of balance sheet movements for the balance sheet accounts plus a functional area analysis for income statement accounts.
- Document types and posting levels – The document type field is used to trace each amount that is submitted to or generated by Group Reporting. By analyzing the document types that make up a consolidated position, a user can explain how that consolidated position was generated. Document types are then logically grouped into posting levels, which are used for reporting purposes. A full set of document types and posting levels has been included in the Best Practice Content.
- Data submission tasks & milestones – Tasks and milestones are specific steps that a user performs to submit data to Group Reporting for consolidation. A full set of generic tasks and milestones have been included with the Best Practice Content.
- Data validations – Most consolidation tools contain functionality that helps a Group Finance team ensure that the data that has been submitted is consistent and logical. The Best Practice Contents contain several types of functionality that support this function.
- Currency conversion – A full set of currency conversion rules; even rules for supporting historic conversion have been included.
- Consolidation processing – A full set of consolidation rules which include (but are not limited to) elimination of intercompany data, elimination of dividends, elimination of intercompany profit in stock, elimination of investments, recognition of non-controlling interest and scope changes.
- Hierarchies – Several example hierarchies have been included that can be used for reporting purposes.
- Cash flow statement – An example cash flow statement has been included that can be reused as well for reporting purposes or as an example for a client-specific cash flow statement.
That is quite a bit of functionality! There are however several points that the Best Practice Contents does not contain. Consolidation units have not been included. Consolidation units would be either legal or operational entities which will consolidate using Group Reporting. Consolidation groups have also not been included in the Best Practice Content. A consolidation group would represent a legal structure that contains one or more consolidation units. Furthermore, additional master data has not been included. When we speak about master data, we are referring to sets of lists that are used to analyse our data such as a set of profit centres or cost centres.
SAP does provide examples of consolidation units, consolidation groups and additional master data. These examples can be found on SAP Best Practice Explorer, which is a test script for Group Reporting. The following link can be used to access this content (https://rapid.sap.com/bp/).
You will need to navigate to the appropriate section for either on-premise or cloud. Once you have navigated to the appropriate section, select Advanced Account and Financial Close. There should be a section titled Group Reporting - Financial Consolidation (1SG). This Best Practice Explorer will contain files that can be uploaded to Group Reporting.
How do we proceed if just using the Best Practice Contents "as is"?
Although it is probably not likely that any client will just re-use 100% of Best Practice Contents without modification, it is interesting to note the steps involved in producing a consolidated output without any changes.
At a minimum, a client will need to upload all relevant consolidation units and consolidation groups. As per the above section, a consolidation unit is a legal or operational unit that will submit data to Group Reporting. A consolidation group is a legal structure that is comprised of one or more consolidation units. All relevant consolidation units and consolidation groups would need to be added to specific upload files. Templates for these upload files can be found in the Import Consolidation Master Data application. The contents of these uploaded files are managed in Excel. Both the consolidation units and the consolidation groups will need to have specific properties applied hence it is important to review the example master data load from the SAP Help and the Best Practice Explorer.
Once these upload files are created, they can be uploaded using the Import Consolidation Master Data application, which can be seen in the following screen.
Image 1 - Import Consolidation Master Data
You will need to first load the consolidation units and then the consolidation groups. The consolidation units can be assigned during the load of the consolidation group. The following image displays a list of consolidation units that have been applied to a consolidation group from the Manage Consolidation Group Structure – Group View application, as per the following image.
Image 2 - Consolidation Group Structure
The next step would be to create and load a mapping of general ledger accounts defined in S/4HANA Finance to the consolidated group chart of accounts. Mapping is contained in the Map FS Items with the G/L Accounts application. Again, this is another point that can be created and managed in Excel and then uploaded to Group Reporting.
This mapping is used when releasing data from SAP S/4HANA Finance to Group Reporting. Releasing data is the act of copying the data contained in the ACDOCA table of Finance to the ACDOCU table for Group Reporting. The ACDOCA contains and collects the universal journal entries for S/4HANA. The ACDOCU table is, for the most part, a copy of ACDOCA, but it is used by Group Reporting for consolidation.
Image 3 - Map FS Items with GL accounts
Finally, you will need to ensure that several parameters are set for releasing data from S/4HANA Finance to Group Reporting such as ensuring that the version (reporting cycle such as actual) is pointing to the correct ledger in Finance and the fiscal year variant is aligned to what has been defined in Finance. These parameters can be seen in the Define Versions transaction of the SAP Central Business Configuration console in the cloud or SPRO in the on-premise edition of S/4HANA.
Image 4 - Define Versions
Once these above points have been completed, you technically have a consolidation system. The submission and data validation process will have been defined. The currency conversion and consolidation processes have also been defined. It is possible to post manual journals at this point. Technically, reporting can be performed using the Data Group Analysis application as well.
So, at this point, it is technically possible to consolidate. However, the above description is only theoretical. An opening balance for the balance sheet would need to be created and loaded. Exchange rates would need to be loaded. The output of the consolidation would need to be reviewed and checked. A reporting pack would need to be built. Plus, several other aspects would need to be reviewed, adjusted and checked. Hence, a “fit-gap” analysis is always needed before starting an implementation of Group Reporting.
This section is really to illustrate that the Best Practice Contents are quite comprehensive and can be used as the basis for the implementation in most instances of Group Reporting.
Is it possible for a client to change the chart of accounts without breaking the consolidation process?
One of the most important updates to the Best Practice Contents for almost all implementations of Group Reporting is the replacement of the example chart of accounts with the client’s chart of accounts.
Quite often when the account structure is replaced in most consolidation tools, processes for the currency conversion and consolidation need to be updated or re-built. Group Reporting’s currency conversion and consolidation processes however rely on source and target attributes of the financial statement items to ensure that these processes do not require revisions when changing the group chart of accounts.
That was a pretty heavy sentence in the last paragraph, which requires some explanation. A financial statement item is the equivalent of an account in Group Reporting. It is used for a little more than that, but for our purposes, it is a group account. Each financial statement item, or FS item, has attributes. Attributes are text fields that are assigned to an FS item. The values in the attributes are read by the various business processes of Group Reporting. Attribute values are used to group, select and insert ranges of FS items. The following image displays the attributes of an FS item.
Image 5 - Target Attributes
You will notice in the above image that several attributes are used for such aspects as the cash flow statement or data collection. These types of functionality are driven by attributes.
These attributes are grouped into two types: selection attributes and target attributes. Selection attributes are used to select an individual FS item or a range of FS items. In the above image, we have highlighted the Elimination Selection. When the elimination process is executed during the consolidation process, this FS item will be selected for processing by a specific set of rules. The output of the consolidation rules is determined by the Elimination Target. By applying the correct attribute values to a custom chart of accounts, it is possible to use a client-specific chart of accounts without directly amending the consolidation process. The tricky bit is reviewing the accounts from the client and applying the correct attribute values to their chart of accounts.
It is also possible to build a full set of functionalities alongside the Best Practice Contents and then only use the Best Practice Contents as a reference. All development in Group Reporting is by Consolidation COA (chart of accounts). All of the Best Practice Contents were developed on the Consolidation COA, Y1. It is possible to create a custom Consolidation COA and then copy over what is required from Y1 Best Practice Contents. By developing a custom Consolidation COA, you will not disturb the Best Practice Contents that are contained in the standard Y1 COA.
Consequently, there are two options for development in Group Reporting; directly enhancing the Best Practice Contents or developing a client-specific Consolidation COA alongside this content.
There is one point that needs to be mentioned when directly enhancing the Y1 COA contents. Many objects that have been created by SAP for the Best Practice Contents cannot be altered. If many structures require amendments, then it would be beneficial to copy over the existing Best Practice Contents to another Consolidation COA.
How does data integration work for Group Reporting?
Data integration is a major aspect that needs to be reviewed before initiating the implementation of Group Reporting. The data submission process comes with two default tasks that are used to load data into Group Reporting. They have been highlighted in the following image from the Data Monitor application. They are Releasing Universal Journals and Data Collection.
Image 6 - Data Monitor - Detailed View
If a consolidation unit has been mapped to a company in S/4HANA Finance, then the universal journals from S/4HANA can be released to Group Reporting. The Data Collection task allows users to load flat file information into Group Reporting directly.
Various points that should be covered during the “fit-gap” analysis include how will historical data be loaded into the system. If the client is using the Asset Management module of S/4HANA, then a review of the asset movements defined in this module must be done. Data aggregation options must also be reviewed. Additionally, any late adjustment process needs to be assessed.
Furthermore, version 2021 of Group Reporting allows the creation of a consolidation data preparation ledger in S/4HANA. This ledger can be used to map data from the leading ledger in S/4HANA to something more appropriate for Group Reporting. Group Reporting then reads data from the consolidation preparation ledger as opposed to the leading ledger. By using this additional preparation ledger, it is possible to map multiple companies defined in Finance into one consolidation unit in Group Reporting or conversely one company into multiple consolidation units. It is also possible to map data based on other dimensions such as profit centres.
So, there are a lot of options for integration with S/4HANA Finance. The Best Practice Content focuses on the processes that are a part of Group Reporting and not how to get data into the system or out of it. So, the “fit-gap” analysis for this aspect is quite important for any implementation.
Regarding sources that are not in S/4HANA Finance, it is possible to load data directly from flat files using the Data Collection task. There is no extraction functionality from other tools for this task, and it does not contain data transformation functionality either (it is just the “L” from “ETL”- extract, transform, load). This task is very good for loading historical data or posting additional adjustments to released data, but for the submission of data on an ongoing basis, this tool is not sufficient.
Group Reporting can be used in conjunction with Group Reporting Data Collection (GRDC). GRDC is an additional, supporting tool for Group Reporting that provides input schedules plus a fully-fledged ETL that can be used to load data into Group Reporting. GRDC is a cloud-based tool that connects to Group Reporting or third-party tools using an OData connection.
GRDC comes with its own Best Practice Content for input schedules. It is possible to re-use the input schedules in the Best Practice Content of GRDC by using the selection attribute that has been specifically designed for applying FS items to input schedules. This attribute can be seen in the following image.
By assigning FS items to input schedules using this attribute, it is possible to repopulate all input schedules that have been pre-defined with the relevant FS items. However, many of the input schedules for balance sheet movements will need to be reviewed, as these are hard-coded values for balance sheet movements, which cannot be adjusted and may not be relevant.
Image 7 - FS Items - Data Collection Attribute
Data granularity and aggregation options
During any implementation, a principal topic that should be reviewed is the granularity of data in Group Reporting. By default, Group Reporting’s ACDOCU table contains the same level of detail as S/4HANA Finance’s ACDOCA table. Consequently, Group Reporting can consolidate at the universal journal level.
The ability to consolidate at the universal journal level can be extremely interesting in terms of visibility for the Group Finance team. By consolidating upon universal journals, it is possible to drill down to the lowest level of detail to review how an overall consolidate position is built up.
Furthermore, this level of data granularity opens the possibility of reporting on any dimension that is present in the underlying table. As such, is it possible to analyse and report on detail such as profit centres or cost centres, but it is also possible to report on details that are not normally present in a traditional CPM or consolidation tool such as plant level details, sales districts or supplier information.
The first two columns displayed in the following image are options for enabling a field in the ACDOCU table for master and enabling that master data to have hierarchies built on top of it. By using these two options, it is possible to generate reporting at a very granular level.
Image 8 - Define Consolidation Master Data
The cost of having a very low level of detail in the system is the performance. The in-memory servers that are available today can support the reporting of a very large volume of data. However, the volume of data that is generated from S/4HANA can be quite significant, which could degrade the performance of Group Reporting.
As such, a balance needs to be struck between reporting capabilities and the performance of the application. In the image above and to the right, a third parameter is highlighted, which is used to define the aggregation of data. By enabling the aggregation of data on certain fields, it is possible to reduce the number of records that are released from S/4HANA Finance, which should in turn enhance the performance of various processes in the application plus any reporting that is done on data in Group Reporting. By default, no aggregation is enabled in the SAP Best Practice Content. This point should be reviewed during the design phase for any implementation of Group Reporting.
Data submission process
The data submission process is governed by an application in Group Reporting called the Data Monitor. This application displays all of the necessary steps a consolidation unit needs to perform to submit data to the group for consolidation. The following image displays an example of the Data Monitor application.
Image 9 - Data Monitor
This application displays each step in the submission process in the columns; the rows display the individual consolidation units that have been included in the displayed consolidation group. Each consolidation unit must execute each applicable step starting from the left and moving to the right. Once the consolidation unit’s steps are completed, the overall status (displayed in the first column) is updated to complete.
Generally speaking, most of these steps cannot be changed or altered. For example, the currency conversion must be present and its ordering needs to be just before the last validation step.
Aspects related to security should be reviewed, such as allowing the user to lock steps but removing the ability to unlock steps. Furthermore, it is possible to enhance this application with custom steps in the submission process. To know more about how this is done, please view our tip on creating custom tasks and milestones.
The impact on data validations
The data validations can ensure that a specific set of data equates to a second set of data. An example of this would be that the depreciation expense on the income statement must equal the depreciation movement in the fixed asset section of the balance sheet. Validations are also used to check signages such as ensuring that a consolidation unit does not depreciate or impair more than the original cost of an asset. The Best Practice Contents contain a complete set of data validations.
Unfortunately, many of these validations have hard-coded values to specific FS items and balance sheet movements. In most cases, we expect the client to use their group chart of accounts. If this is the case, in any instance where an FS item is hard-coded, the validation will need to be rebuilt. It is not possible to alter any object such as a validation, selection, consolidation method, etc. that has been included in the Best Practice Content. In most instances, we expect that the data validations that have been included with the Best Practice Content will only be used as examples.
Intercompany matching
Two steps are needed to consolidate intercompany data. The first is to match the intercompany data that occurs between counterparties. This matching is done to ensure that the amounts equate on both sides of a transaction. The second is to eliminate that data. If we first do match our transactions in the first step, we will not be able to ensure that the values, which are eliminated, will fall to zero in total when the process is complete.
The process for intercompany matching is contained in a tool outside of Group Reporting. SAP S/4HANA contains its proper intercompany matching tool called Intercompany Matching and Reconciliation (ICMR). This tool has its proper scope item and its own Best Practice Content. ICMR can read data that is stored in Group Reporting. It can read the master data defined in Group Reporting as well. However, it can also read the data and master data from S/4HANA Finance. It is also possible to load data directly to this tool for matching purposes.
Consequently, ICMR is considered a standalone tool. It is designed to work with Group Reporting, but the implementation of Group Reporting or licensing for Group Reporting is not required for ICMR’s usage. Any implementation of Group Reporting would require a review of ICMR and how it will be used with Group Reporting.
The client would need to choose whether or not to use this tool. If they do utilize this tool, they will need to define a whole list of parameters such as the level of granularity for the matching processes. It is possible to match at only the balance level, but it is also possible to set up processes that match at the transaction level using pre-defined rules in ICMR.
Choices that need to be made for the consolidation process
SAP has included two sets of consolidation processes in the Best Practice Contents for the elimination of investments. The elimination of investments pertains to transactions made by a holding company to acquire or create a wholly or partially owned subsidiary plus the elimination of the corresponding equity positions in those subsidiaries that were generated by these intra-group investments.
This elimination process also contains postings for the recognition of non-controlling interests outside the group and entries to re-present the financial statements of a joint venture or associated affiliate using the equity method of consolidation.
Since SAP has included two processes, we must choose one of them for the implementation during the “fit-gap” analysis. The first process is called rule-based elimination of investments. The rule-based method selects amounts that have been submitted onto specific FS items. The amounts on those FS items then drive the elimination process. For example, an intercompany investment is submitted onto the investment in subsidiaries FS item. This amount is eliminated by the consolidation process and then re-used to eliminate the equity in the corresponding. The positive side of this type of elimination process is that its relative complexity is low. It is very useful for groups that have a straightforward ownership structure.
The second process is called activity-based elimination of investments. This process depends on the data that is submitted to the group, just as rule-based, but in addition to that data, different types of transactions require activity values to be applied to them. So, if there is an increase in capital for a subsidiary, a specific activity number must be supplied along with that transaction to indicate to Group Reporting that it is a capital increase.
By using activities to identify different types of transactions, Group Reporting’s consolidation can perform a much wider array of adjustments automatically. Consequently, this type of process can be used to support an organizational structure that is far more complex. Furthermore, only the activity-based processing can automatically recognize affiliates that should be consolidated under the equity method of consolidation.
Matrix consolidations
Group Reporting can also display matrix consolidation eliminations. So what does SAP mean when it states “matrix consolidation”, and what does it mean to post eliminations using this type of method? Group Reporting can display consolidated data by a hierarchy of consolidation units or by a hierarchy of another dimension such as the profit centre. By viewing a specific point on a hierarchy, it is possible to view the consolidated position for that subsection of data within the overall group.
In other words, Group Reporting is supporting segmentation reporting with matrix consolidation. Consolidation units can be organized into segments or business lines. Segmentation can also be defined by profit centres or by the segment dimension itself. By using these additional dimensions, it is possible to view a consolidation profit centre or a grouping of profit centres.
Fortunately, it is possible to generate this type of analysis without changing the consolidation process. All consolidation rules will work the same regardless of whether segmentation is used or not used. On top of that, the dimensionality that defines the segmentation will not cause adjustments to the consolidation process.
From a technical perspective, only the Enable Hierarchy Elimination option must be activated in the Define Consolidation Master Data Fields transaction, which can be seen in the following image.
Image 10 - Consolidation Master Data - Hierarchial Eliminations
Once this option is defined and the consolidation processes have produced an output, all of the reports would need an elimination field to them. There are three types of elimination fields; consolidation unit for elimination, the profit centre for elimination or the segment for elimination.
These additional fields can be seen in the image below. By combining these elimination fields along with additional dimensions, it is possible to view segmented data. This analysis is done dynamically on the face of the report in the Group Data Analysis application, Analysis for Office (AfO) or SAP Analytics Cloud (SAC).
Image 11 - Consolidation Elimination Fields
The tricky part of this type of analysis is not from a technical perspective. The data that is used to drive this analysis is the underlying cause of the complexity. If the analysis is solely driven by the consolidation unit hierarchy, only consolidation unit by trading partner level of detail must be provided. However, if the client wishes to view consolidated profit centres, for example, then each record must have consolidation unit by profit centre and then trading partner by trading partner profit centre populated. Many clients are not able to consistently supply the correct trading partner profit centre level of detail that this type of analysis requires.
What do we do about reporting?
Included in Group Reporting is an application called Group Data Analysis. This pivot table-like reporting tool is an application where users can drop and drag various dimensions into the rows and columns of the application to make a report. This application is extremely useful for building ad hoc reports to analyse the data that has been submitted to Group Reporting. However, the principal target audience for this application is a Group’s Finance team that reviews the submitted data. This application is not intended to build a reporting pack or dashboards that will be viewed by individuals who are not a part of the Finance function of an organization.
Group Reporting does not natively contain a reporting tool that can be used to support highly formatted reporting packs and dashboards that display consolidated actuals or budgets. There are several options for integrating an additional reporting tool to read data from Group Reporting, but functionality is not within Group Reporting itself.
Typically, the reporting layer is a standard function of all CPM or consolidation tools, and it may seem odd at first, not to have a reporting layer for Group Reporting. But, most reporting packs contain data from multiple sources; not just the consolidation tool. By accepting that Group Reporting will be only one source among several, the client can rely on one additional application that can incorporate multiple sources with the consolidation output being just one source for data.
SAP offers two options for reporting tools; SAP Analytics Cloud (SAC) and SAP Analysis for Office (AfO). Both of these tools can read CDS views that are available in S/4HANA. CDS view stands for Core Data Services. It is for the most part a data view that reads and presents data from the underlying tables in S/4HANA. Group Reporting is a part of S/4HANA, as such, it has its own set of standard CDS views. These CDS views are then used as the basis for reporting consolidated data from Group Reporting.
Both SAC and AfO can incorporate data from Group Reporting plus several other sources to support a client’s reporting needs. The Best Practice Content does contain several standard CDS views where the data within can be reported upon.
SAP’s tools provide advantages for reading CDS views due to their native connection to S/4HANA (and by default the CDS views of Group Reporting). However, a third-party tool could also be used as well. This point however must be reviewed before implementing Group Reporting and included in any “fit-gap” exercise to ensure that Group Reporting’s output can be displayed in whatever reporting tool the client chooses to use.
Conclusion
The SAP Best Practice Contents contains an impressive set of functionalities that should be investigated by most clients when considering to implement Group Reporting. Due to our experience with the Best Practice Content, we feel that this is a major advantage of Group Reporting. By using these contents along with the output of a “fit-gap” analysis, it is possible to decrease the implementation time plus also have a very positive outcome for the implementation of Group Reporting.
Keen to know more?
Continue reading or contact us to get started:
