CUSTOMER

How-To Guide Integration with SAP S/4HANA

Accounting using Group Reporting Preparation
Ledger

SAP S/4HANA Finance for group reporting (On Premise)

1
Applies to:
This guide applies to the following SAP S/4HANA Finance for group reporting version:

• Version OP 2021 FPS1, OP 2022, OP 2023

REVISION HISTORY

Version / Date Description

Added additional considerations for customers transitioning to the group reporting
preparation ledger mainly explaining the impact of stopping back synchronization of
Version 2 / sender fields, chapter mainly 1.5
19.12.2022
Added CE2302, OP 2023 feature of local currency and quantity source definition in
the version maintenance, chapter mainly 1.4.4.3
Version 3 /
Updated information concerning master data maintenance.
07.03.2023

Purpose:
This document helps customers and partners to better understand how to integrate SAP
S/4HANA Finance for Accounting with SAP S/4HANA Finance for Group Reporting by
leveraging the group reporting preparation ledger.

SAP S/4HANA Finance for Accounting and Group Reporting product knowledge is
required before using this guide.
TABLE OF CONTENTS
1 GETTING STARTED ......................................................................................................................... 5
1.1 Introduction ...................................................................................................................................... 5
1.2 What’ included in which release .................................................................................................... 5
1.3 Features ............................................................................................................................................ 6
1.3.1 Additional Fields in ACDOCA ......................................................................................................... 6
1.3.2 Substitution at Accounting Posting Time ..................................................................................... 6
1.3.2.1 Default Derivation Logic for Each Field ............................................................................................. 6
1.3.2.2 Custom Defined Substitution Rules for Group Reporting Fields ....................................................... 7
1.3.2.3 Priority/Sequence for System to Read Those Substitution Rules. .................................................... 8
1.3.3 Validation .......................................................................................................................................... 8
1.3.3.1 Consistency Check Before Start Closing in Group Reporting ........................................................... 8
1.3.3.2 Validation While Posting Accounting Document................................................................................ 8
1.3.3.3 Validate Universal Journal After Data Released to Group Reporting................................................ 8
1.3.3.4 Validate Reported Data and Standardized Data in Group Reporting ................................................ 8
1.3.4 Incremental Data Release Process ................................................................................................ 9
1.3.5 Realignment ................................................................................................................................... 10
1.3.6 Balance Carryforward ................................................................................................................... 10
1.3.6.1 Balance Carryforward in Accounting ............................................................................................... 10
1.3.6.2 Balance Carryforward in Group Reporting ...................................................................................... 11
1.3.7 Analytic ........................................................................................................................................... 11
1.3.7.1 Display General Ledger Journal with Group Related Fields ........................................................... 11
1.3.7.2 Reporting in Accounting ................................................................................................................... 11
1.4 General Configuration Procedure for GRPL ............................................................................... 12
1.4.1 Pre-Implementation Considerations ............................................................................................ 12
1.4.2 Configuration Overview ................................................................................................................ 12
1.4.3 Prerequisite check ......................................................................................................................... 12
1.4.4 Configuration in Group Reporting ............................................................................................... 13
1.4.4.1 From Year for Preparation Ledger ................................................................................................... 13
1.4.4.2 Define Group Reporting Preparation Ledgers ................................................................................. 13
1.4.4.3 Version ............................................................................................................................................. 14
1.4.5 Configuration in Accounting ........................................................................................................ 15
1.4.5.1 Company Code-Company Assignment ........................................................................................... 15
1.4.5.2 Define Settings for Ledgers and Currency Types ........................................................................... 15
1.4.5.3 Consolidation Transaction Type (RMVCT) ...................................................................................... 15
1.4.5.4 Functional Area ................................................................................................................................ 15
1.4.5.5 Substitution for Group Reporting Fields in Accounting .................................................................... 15
1.4.5.6 Retained Earnings for Balance Carryforward in Accounting. .......................................................... 16
1.4.6 Master Data..................................................................................................................................... 16
1.4.6.1 Consolidation Unit ............................................................................................................................ 16
1.4.6.2 FS Item and Map GL Account to FS Item ........................................................................................ 17
1.4.7 Define Validation Rule ................................................................................................................... 17
1.4.7.1 Validation Rule for Group Journal Entries ....................................................................................... 17
1.4.7.2 Validation Rule for Reported Data ................................................................................................... 17
1.5 Other Functions Could Be Impacted (especially relevant for existing customers
transitioning) .................................................................................................................................................. 17
2 FURTHER OPERATIONS AFTER THE INTEGRATION WITH GROUP REPORTING
PREPARATION LEDGER IS ACTIVATED IN THE PRODUCTION SYSTEM .............................................. 18
2.1 Functions Available to Detect Data Quality Issues .................................................................... 18
2.2 Data Correction in Accounting ..................................................................................................... 19
2.2.1 Manual Reversal and Repost ........................................................................................................ 19
2.2.2 Realignment Function ................................................................................................................... 19
2.2.2.1 When to Execute Realignment ....................................................................................................... 19
2.2.2.2 How to Execute Realignment .......................................................................................................... 19
2.2.2.3 How to Analyze Realignment Results ............................................................................................. 20
2.2.2.4 Special Treatment on Opening Balance Adjustments (for YTD Realignments) .............................. 21
2.2.2.5 Manage Posting Period ................................................................................................................... 21
2.3 Data Correction in Group reporting using Posting Level 0C ................................................... 21
3 TRANSITION FOR NEW SAP S/4HANA CUSTOMERS STARTING IN CE 2202/OP 2021 FSP123
3.1 What to consider before activating the integration with group reporting preparation ledger
23
3.2 Data Cutover .................................................................................................................................. 24
4 TRANSITION FOR EXISTING SAP S/4HANA CUSTOMERS ....................................................... 24
4.1 Scenarios ........................................................................................................................................ 24
4.2 What to consider before activating the integration with group reporting preparation ledger
in an existing SAP S/4HANA system ........................................................................................................... 25
4.3 How to Transition .......................................................................................................................... 25
4.3.1 Review Accounting and Group Reporting Configuration ......................................................... 25
4.3.2 How to Transition Historical Data ................................................................................................ 25
5 HOW TO TROUBLE SHOOT .......................................................................................................... 27
5.1 Why don’t I see group reporting field values in the accounting document in the Manage
General Journal Entries app? ...................................................................................................................... 27
5.2 Why didn’t realignment work? ..................................................................................................... 28
Background Information:

1 GETTING STARTED
SAP S/4HANA Finance for Group Reporting comes with the vision to provide access to high-granular finance
data and provide any-time access to most recent data.
SAP S/4HANA provides a harmonized feature set and user experience to be applicable to both operational
financial accounting and group accounting (e.g. data quality validations, field value derivation, inter-company
reconciliation & matching, analytical rules such as KPI, reporting row/column definitions)
A tighter integration with accounting data is required to allow this.

1.1 Introduction
A key capability to integrate with accounting in a tighter way is to enhance the data transparency between
General Ledger accounting in SAP S/4HANA Finance for Accounting and consolidation in SAP S/4HANA
Finance for Group Reporting.
At the same time, the system should allow flexible logic to enhance the data quality in accounting to better
serve consolidation and analytical purposes for a group accountant. Substitution and validation functions will
support this scenario.
The group reporting data requirement will not block accounting document posting to reduce the risk of
blocking other processes. Any inaccurate data can be adjusted manually in group reporting or by leveraging
a realignment program in the future to provide better data quality as expected.
With improved data in accounting, the data release program can be enhanced and simplified compared to
the traditional approach.
The following sections will explain these new capabilities in accounting and group reporting in detail.

Refer to help document on the function.

- Application help
o On Premise / private cloud (OP)
o Public Cloud (CE)
- EKT document for release 2202 (initial cloud release of group reporting preparation ledgers)
- EKT document for release 2208 (enhancement of flexible consolidation unit derivation)
- Glossary

1.2 What’ included in which release

The delivery of a tighter integration with SAP S/4HANA Finance for Accounting will come with several
releases. In CE 2202/OP 2021 FSP01, the following key features are delivered:
• Additional fields in accounting journal posting
• Derivation and substitution in group reporting preparation ledger
• Realignment function to post delta adjustment in group reporting preparation ledger
• Enhanced data release
• Enhanced line validation task (validation of universal journals)
With CE 2208 and OP 2022, the following features are added:
• Flexible derivation of consolidation unit
With CE 2302 and OP 2023, the following features are added:
• Definition of source measures for local currency and quantity in the version maintenance
Note for existing group reporting customers: With the introduction of the group reporting preparation ledger,
the back-synchronization of subitem values into the sender fields is discontinued. Please check chapter 1.5
for further details.

1.3 Features
This section briefly explains the new changes/enhancements delivered as of CE 2202 to better integrate with
accounting when the group reporting preparation ledger is activated.
Refer to related documentation in Group Reporting Feature Deck 2202

1.3.1 Additional Fields in ACDOCA

As of CE 2202, these fields are available to be added into ACDOCA during accounting posting:
• Consolidation Unit (RBUNIT)
• Partner Consolidation Unit (RBUPTR)
• Company (RCOMP)
• Consolidation Chart of Accounts (RITCLG)
• Financial Statement Item (RITEM)
• Subitem Category (SITYP)
• Subitem (SUBIT)

Note: Values in these fields will be derived by the system. They will not be available for input during manual
posting in accounting. These fields can be viewed after the journal is posted, also see section 1.3.7 for
details on analytics.

1.3.2 Substitution at Accounting Posting Time

1.3.2.1 Default Derivation Logic for Each Field

Since all the values for additional fields in accounting posting will be generated by the system, derivation
logic is required. The system has delivered substitution rules on how the value should be derived:
• Consolidation Unit (RBUNIT) and Company (RCOMP)
Release CE 2202 / OP 2021 FPS1
By default, with the delivered substitution rule /0SAP/GR_RBUNIT, Consolidation Unit will be a 1:1 derivation
from Company, while Company is determined in the Finance Organization configuration. Upon setting up the
company code and company, this assignment will also be configured between them. Assignment is
maintained in table T001.
In the Cloud system, only one company code can be assigned to one company ID. There could be company
IDs that don’t have any company code assigned to them.
In the On Premise system, multiple company codes can be assigned to one company ID. The customer can
decide on a 1:1 or n:1 assignment during configuration. There could also be company IDs that don’t have
any company code assigned to them.
Release CE 2208 / OP 2022
The Consolidation Unit field is available as a substitution target field in the context GRPL core fields (see
below for further details)
The consolidation unit master data attribute company ID is editable. With this, it’s possible to assign a
company ID to a consolidation unit. 1:n assignments are possible, meaning that a company ID can be split
into various consolidation units, such as to represent segments.
Value proposals in master data and an SAP proposal substitution for the consolidation unit derivation make
sure that there are no regressions as compared to the previous release. In other words, if there’s a unique
assignment of company ID and consolidation unit, then there’s no need to create a customer defined
substitution.
For further details please refer to the EKT material of the release.
• Partner Consolidation Unit (RBUPTR)
Release CE 2202 / OP 2021 FPS1
By default, with the delivered substitution rule /0SAP/Partner, Consolidation Unit is the corresponding partner
entity to consolidation unit. By default, it is derived 1:1 from the trading partner field. In accounting, a trading
partner is the same master data as Company.
Release CE 2208 / OP 2022
The derivation is enhanced to offer a symmetric logic as for the consolidation unit and at the same time keep
the specifics of the partner unit sub-assignment. For further details, refer to the EKT material of the release.
• Consolidation Chart of Accounts (RITCLG)
Consolidation Chart of Accounts is assigned to the G/L ledger as a new configuration for the group reporting
preparation ledger. Then, accounting posting will be derived from the configuration.
• Financial Statement Item (RITEM)
As a general process for group reporting master data maintenance, G/L accounts are mapped to FS items
with a mapping version, mapping ID, and revision. Then, it’s assigned to a fiscal period, consolidation chart
of accounts, and G/L chart of accounts via the Fiori app Assign FS Item Mapping.
When there is no FS item mapped for a G/L account, a default FS item is used. The FS item used as a
default value would have a role as S-NOMAPB/S or S-NOMAPP/L.
The FS item mapping version is also assigned to the general ledger during configuration, as explained in
section 1.5.2.1.
The system reads the FS item mapping in group reporting for the period that the accounting document is
posted.
• Subitem Category (SITYP) and Subitem (SUBIT)
While the FS item is derived, a breakdown category assignment maintained for each FS item is also
retrieved, and a subitem category is derived from the breakdown category definition.
Be aware that in a standard group reporting function, when a breakdown category assigned to an FS item
requiring a subitem for transaction type, the subitem value is derived from the consolidation transaction type
(movement type) in accounting, where each asset transaction type is assigned to.

1.3.2.2 Custom Defined Substitution Rules for Group Reporting Fields

Please check the general description for substitution and validation function in financial accounting,
Rules for Substitution-S/4HANA On Premise or Rules for Substitution-S/4HANA CE 2202.

New business contexts are available for the group reporting preparation ledger specifically:
• Group reporting preparation ledger core fields:
• Group reporting preparation ledger sub-assignments to FS item: Target fields for consolidation
subitem, partner consolidation unit

For example, you can now derive the FS item based on functional area and G/L account combination.

You can also leverage a look up table in the substitution rule. Refer to the EKT document for more
information based on the example of the consolidation unit derivation in release CE 2208 / OP2022.

Note: When designing the logic, please consider the situation for period 000 (see chpt. 1.3.6.1 for more
details).
1.3.2.3 Priority/Sequence for System to Read Those Substitution Rules.

There are different substitution rules/logic that are applied during accounting posting.

Note: As a sequence, the default rule (see section 1.4.2.1) will be executed first, then the custom substitution
rule (see section 1.4.2.2). At the end of posting, there is always a consistency check against the breakdown
category. If there is any substitution rule that was created that doesn’t follow the breakdown category
requirement, the record will be adjusted again to follow the breakdown category requirement.

Also, as shown in the diagram above, core fields are derived first, then sub-assignment fields. For example,
the subitem derivation has dependency on the FS item. So, it’s executed after the FS item rule is completed.

1.3.3 Validation
In the record to report process, there are a couple validation steps:

1.3.3.1 Consistency Check Before Start Closing in Group Reporting

The consistency check program (CX8CCI) is enhanced with additional checks.
• The consistency check can be executed by period per version and chart of accounts.

1.3.3.2 Validation While Posting Accounting Document

By default, no error messages are created during accounting posting time.

1.3.3.3 Validate Universal Journal After Data Released to Group Reporting

The validation of universal journal task in the group reporting Data Monitor is enhanced with:
• Line-item validation on data in ACDOCU. This is not only a validation of data quality per breakdown
category assignment (as in previous releases), but also a validation with the rules defined in the
Manage Substitution/Validations Rules - Group Journal Entries app. The posting level “blank” can be
used in the rule prerequisites to make rules specific to data from the release task or exclude other
line-item validation rules from this task.
• New task log view consistent with other group reporting tasks.

1.3.3.4 Validate Reported Data and Standardized Data in Group Reporting

Validation rules can be set up in group reporting to provide further validation on the overall quality of data.
In the best practice content scope 1SG in version CE 2202, there are new validation rules as part of the
content:

Example:
1.3.4 Incremental Data Release Process
When you enable the group reporting preparation ledger, you gain the capability to perform incremental/delta
release of the universal journal. Note that in the traditional integration approach, the data release is always
conducted in full load mode, and data from previous releases of the same period are deleted. Now, only the
data since the last release is integrated into group reporting and with no deletion.
With the proper authorization assigned, for example authorization for group accountant only, you can still
perform full load when needed. Full mode can only be executed via background job. The setting of the
background job provides different options for replication types:
• Automatic: Default
• Complete Period: Full Mode
• Delta Period: Incremental Mode

The period information is taken into group reporting with a 1:1 mapping, which means:
• Changes of how special periods are handled in group reporting.
Data booked into a special period in accounting is longer be added into period 12. It’s stored in the
same period number as how it's stored in accounting.
• Special periods are supported in group reporting according to the definition of the fiscal year variant
of the version. This is a change from past behavior where special periods were loaded into period
12. Once the group reporting preparation ledger is activated, special periods will be executed
independently as a separate period, and hence subsequent consolidation tasks also need to be
processed in these periods.
• Period 000’s balance carryforward is handled independently in group reporting. For details, please
see section 1.4.6
Note:
➢ All these changes do not apply to plan versions of data.
➢ The new data release behavior is only active after the group reporting preparation ledger is
activated. If the year of releasing data is before the year set as “From Year for Preparation ledger” in
the configuration activity Check Global System Settings (transaction CXB3), then the old data
release behavior logic will apply.
➢ When the group reporting preparation ledger is activated, the data release task will use the group
reporting-related fields derived in accounting in the release process 1:1. No more derivation logic
takes place in the release task. For example, if there’s a custom substitution rule to change an FS
item in an accounting document to FS item B when the G/L account originally is mapped to FS item
A according to the mapping defined, then the data release will release the record into FS item B
because this is the FS item which was derived at accounting posting time. The FS item mapping will
not be used (again) in the data release.
 ➢ There's a 15-minute delay with an incremental data release.

1.3.5 Realignment
Realignment is the function that group reporting provides once a group reporting preparation ledger is
activated.
It’s used to make adjustments based on the latest derivation (such as the field substitutions, FS item
mapping, and breakdown category definition) to adjust existing postings in the system to align data to the
latest definition. Since group reporting-related fields don’t allow manual posting, realignment is the
systematic approach to make adjustments by reclassifying an originally derived value to the newly derived
field value following the latest derivation and master data definition in group reporting.

For further details, please refer to the help documentation and EKT material on Realign Group reporting
Preparation Ledger
Also, refer to section 2.2.2 for details on how to use this program.

1.3.6 Balance Carryforward

1.3.6.1 Balance Carryforward in Accounting

While balance carryforward (BCF) in accounting runs on ACDOCA data and independently from group
reporting’s process, with the group reporting preparation ledger activated, BCF in accounting will include
group reporting field derivation as well.
• The subitem derivation includes a special logic to handle the opening balance:
If a value for the subitem is derived, use the opening subitem (if available) of the derived subitem as
defined in subitem configuration.
If the subitem field is empty after derivation, check the sender field.
If the sender field is not empty, copy the sender field to the subitem field (transaction type
case)
If the sender field is empty and the breakdown type of the subitem greater than or equal to 2,
and the subitem category supports carryforward, use the carryforward of the default value.
Otherwise, leave the subitem empty.
• Customer defined substitutions should distinguish by period (0 vs 1-16) in perquisition, when
applicable.
• Balance carryforward should be executed with the “reset” option if any derivation logic had been
changed since the last update run.
• To ensure data consistency, the retained earnings G/L account used for BCF in accounting should
be the same one mapped to the retained earnings FS item.
• If there’s a new FS item mapping taking effect from period 001 of a new year, then the last period of
previous year’s mapping information will be used for this derivation.
For example, if a new FS mapping is taking effect from 001/2029 and the previous mapping is valid
from 001/2000 to 999/2028, then the system will use the mapping of 999/2028 during BCF to derive
the FS item for documents posted at 000/2029.

For customers transitioning to group reporting, balance carryforward can be used to initialize the accounting
data in period 000 of the year that the group reporting preparation ledger starts. Please see details in section
4.3.2 “How to Transition Historical Data”.
1.3.6.2 Balance Carryforward in Group Reporting

Balance carryforward in group reporting is still executed independently from accounting. Period 000’s data in
accounting is not released to group reporting.

1.3.7 Analytic

1.3.7.1 Display General Ledger Journal with Group Related Fields

• Manage Journal Entries
When you display journals in the Manage Journal Entries app, at the journal entry view, select the view for
the ledger that’s defined as the group reporting preparation ledger.
Select group reporting preparation ledger fields to view the value:

1.3.7.2 Reporting in Accounting

• Trial Balance Report
Group reporting-related fields are not added by default into standard reports like trial balance reports in the
Display Line Item app by.
For customers who have already activated the group reporting preparation ledger and require group
reporting-related fields in other standard accounting reports, please refer to the KBA 3106295 - Adding fields
possible via key user extensibility only

For OP customers, refer to Custom Fields - SAP Help Portal with a similar concept to extend the data source
of a trial balance report.
Open the Navigational Panel and in the section Additional Dimensions from Data Source, you can add
consolidation-related fields into the report row/column axis.

1.4 General Configuration Procedure for GRPL

1.4.1 Pre-Implementation Considerations

Before starting implementation, some basic design decisions need to be reviewed on the accounting side as
preparation for further group reporting preparation ledger design. See section 1.4.3

At the same time, please also review the data integration scenarios. There are different scenarios that could
occur to integrate the data from source systems into SAP S/4HANA for Group Reporting.
a. Direct integration from operational accounting in SAP S/4HANA. The release task is mainly
used to replicate the data from accounting table ACDOCA into group reporting table
ACDOCU.
b. Central Finance approach. With Central Finance, customers can connect their distributed
system landscape to a centralized SAP S/4HANA Finance system. On top of this centralized
data, SAP S/4HANA Finance for Group Reporting can be processed with all its data entry,
consolidation, and reporting features.
c. Integrate external data via Group Reporting Data Collection or with the upload options of
SAP S/4HANA Finance for Group Reporting.
The group reporting preparation ledger function discussed in this document only applies to integrate group
reporting with SAP S/4HANA Finance, for either scenario a. or b.

1.4.2 Configuration Overview

For general information, please refer to the help document on configuration activities and the EKT material.

1.4.3 Prerequisite check

There are key points to check when adopting the group reporting preparation ledger.
• No back-synchronization of sender fields from subitem (see chapter 1.5 for more details)
• Common fiscal year variant for consolidation purposes
 Please refer to Fiscal Year in S/4HANA On Premise or Fiscal Year Variant-S/4HANA CE2202.
• Common consolidation chart of accounts
• Common source of the local currency in group reporting
• Common source of group currency
• Freeze derivation rules early in the closing process
Find more details in section 1.4.5.
If your accounting system design doesn’t fulfill this prerequisite, please contact SAP Service for further
advice.

1.4.4 Configuration in Group Reporting

1.4.4.1 From Year for Preparation Ledger

Note that group reporting preparation ledgers don’t come as an option in the old integration. Instead, they
are the go-to methodology for integrating accounting with the group reporting release task. The type of
integration is controlled by one central setting in the global system settings. The configuration activity Check
Global System Settings is available to set the From Year for Preparation Ledger, which is the starting year
for the integration with group reporting preparation ledger. Once this “from year” is set, it cannot be changed.
Upgrade customers must especially decide with which year they want to start the integration with group
reporting preparation ledgers.
• For new cloud customers (who activated scope item 1SG in the CE 2202 release or later), this “from
year” setting is 1001 by default. For existing cloud customers who upgraded to CE 2202, no value is
delivered for this field. It needs to be set by the customer and serves as the activation of the group
reporting preparation ledger.
• For new OP customers on OP 2021 FSP1, this setting is blank upon installation of 1SG. Content for
the group reporting preparation ledger is included in 1SG for the version OP 2022, and the content
upgrade is not supported. Ensure to manually enter this parameter value if you are implementing OP
2021 FSP01.
• For new OP customers who implement group reporting as greenfield, the initialize program would
check and set this parameter by default as 1001 as of the release OP 2021 FSP1.
• For existing OP customers who upgraded to OP 2021 FSP1, this setting is blank upon technical
upgrade. After the technical upgrade, if these upgraded OP customers run an initialization program
in delta mode, then this from year is set to 1001.
• For new OP customers on OP 2022, this setting will be 1001 by default upon installation of 1SG.
• For all customers, once this parameter is set, it cannot be changed anymore. The usage of group
reporting preparation ledgers should not be perceived as an option but the mandatory go-to
integration method. Hence, if you need to change the year in exceptional cases, you will need to
contact SAP Support to make changes to this setting. Changing the year will only be allowed by SAP
under restricted justified reasons (e.g., issues with realignment function, see section 5.2).

1.4.4.2 Define Group Reporting Preparation Ledgers

To start enabling tighter integration with SAP S/4HANA Finance for Accounting, defining a group reporting
preparation ledger is the first step.
The configuration activity Define Group Reporting Preparation Ledgers needs to be maintained. The IMG
path for OP customers is the following: SAP S/4HANA Group Reporting > Master Data > Define Group
Reporting Preparation Ledgers.
By simply mapping a ledger in accounting to a consolidation chart of accounts, and optionally the FS item
mapping version and FS item attribute version, the ledger can be used in a consolidation version definition
as the preparation ledger. This setting is used to activate the derivation of group reporting fields in
accounting postings.
Sample Configuration

One ledger can only be assigned with one FS item mapping version. If you want to have different FS items
for the same posting based on a different version, then you need a different ledger.
Once a ledger in accounting has been assigned as a group reporting preparation ledger, future changes in
the ledger (company code assignment, fiscal year variant change, etc.) is subject to related consistency
checks for the group reporting preparation ledger (details in 1.5.1) by the system. Any inconsistencies will
generate a warning message.

Assign Opening Reclassification Subitems

Besides configuring the ledger, you can also assign a subitem that’s used to adjust an opening balance by
realignment function.

For further details on the functionality, refer to the application help or EKT material on the realignment
function.

1.4.4.3 Version
• Actual Version
Configuration for the group reporting preparation ledger is only available when the year in the global
parameters is a year as of the From Year for Preparation Ledger (as defined in 1.5.3.2).
Settings related to the group reporting preparation ledger in the configuration activity Define Versions:
Source Ledger: This field will not be editable once the year in the global parameters is a year as of
the From Year for Preparation Ledger.
Preparation Ledger: Only ledgers defined as group reporting preparation ledgers in the configuration
activity Define Group Reporting Preparation Ledgers (1.5.3.1) are available to be selected here.
Local Currency Source: Optional. The selection here will be applied to all integrated consolidation
units in this version. If not provided the functional currency measure will be used (as defined in the
source ledger). If you’re working in an OP release before OP 2023, then local currency is always
sourced from the functional currency in accounting, and you can’t set a local currency source.
Quantity Source: Optional. The selection here will be applied to all integrated consolidation units in
this version. If not provided, Quantity (MSL) will be used as source.
Group Currency Source: This field is optional. Make a selection only if you would like to source group
currency data from accounting. The selection here will be applied to all integrated consolidation units
in this version.
 • Plan Version: The integration with group reporting preparation ledger does not work for a plan
version, which should be integrated with ACDOCP. A plan version integrates with ACDOCP as the
traditional approach. So, there is no change introduced with activating the group reporting
preparation ledger.
• Special Versions: The special version for FS Group Items (Item Mapping Version) of a version will
not be used while integrating data into group reporting. During accounting posting, the group
reporting version is not known. Hence, the special version of the group reporting preparation ledger
is used instead of the version setting. After deriving the FS item based on the FS Item Mapping
Version specified in the Define Group Reporting Preparation Ledgers configuration activity, no
further derivation of FS item information based on the G/L account takes place. This is why the FS
Group Items special version is not relevant in case of integration with group reporting preparation
ledger.

1.4.5 Configuration in Accounting

1.4.5.1 Company Code-Company Assignment

Make sure any company code that’s subject to consolidation in group reporting is assigned to a company.

1.4.5.2 Define Settings for Ledgers and Currency Types

• Ledger Fiscal Year Variant (FYV)
All company codes that are assigned in a ledger that will be used as a group reporting preparation
ledger need to have the same FYV. At the same time, the FYV of the ledger must be the same as
the FYV assigned to the consolidation version.
• Ledger Functional Currency
The functional currency defined in the ledger is used to check against the local currency in the
consolidation unit master data (if no other source measure is defined in the version as of CE2302,
OP 2023). Any inconsistency will prevent the integration for the consolidation unit. Refer to Define
Functional Currency in accounting.
• Ledger Group Currency
The integration of an accounting currency measure into the group currency in group reporting is
optional. If the source of the group currency setting is maintained in the consolidation version, then
the group reporting preparation ledger needs to have the same currency key maintained for the
source for group currency key figure for all company codes.

1.4.5.3 Consolidation Transaction Type (RMVCT)

The consolidation transaction type is the default sender field for the subitem when a transaction type as a
subitem is required for an FS item. In the content of scope item 1SG, this is the case for subitem category 1.
Before implementing the group reporting preparation ledger, review the configuration of consolidation
transaction type to make sure there’s consistency with the subitem setup in group reporting.

1.4.5.4 Functional Area

The functional area is the default sender field for the subitem when a functional area as subitem is required
for an FS item. In the content of scope item 1SG, this is the case for subitem category 2.
Before implementing the group reporting preparation ledger, review the configuration of functional areas to
make sure there’s consistency with the subitem setup in group reporting.

1.4.5.5 Substitution for Group Reporting Fields in Accounting

Create any necessary substitution rules for group reporting core fields or sub-assignment fields in addition to
the delivered default rules.
Currently, SAP delivers default substitution rules (IDs listed below). They serve to do the default derivation
logic and are hard-coded. For more details on what they do, see section 1.3.2.1.
 • /0SAP/GR_RCOMP
• /0SAP/GR_RBUNIT
• /0SAP/GR_ITCLG
• /0SAP/GR_ITEM
• /0SAP/GR_ITEM_2
• /0SAP/GR_RBUPTR
• /0SAP/GR_SITYP
• /0SAP/GR_RBUPTR_2
• /SAP/GR_SITEM_2

1.4.5.6 Retained Earnings for Balance Carryforward in Accounting.

With the requirement of better data consistency and transparency between accounting and group reporting
after activating the group reporting preparation ledger, it’s important to make sure the retained earnings G/L
account maintained for balance carryforward is the same G/L account that’s mapped to the retained earnings
FS item in group reporting.

During the accounting balance carryforward, a new entry for the retained earnings of the prior year is
generated, which initially contains a G/L account but does not contain an FS item or subitem. The group
reporting field derivation is active in the balance carryforward in this case and can derive the required group
reporting field values provided that the correct derivations, such as FS item mapping, are maintained for this
G/L account.
The configuration of group reporting should be consistent with this regard. In other words, the annual net
income FS item should be carried forward to the same retained earnings prior year FS item by making use of
the appropriate FS item roles:
- Annual net income: S-ANI-BS
- Retained earnings prior year: S-RETAINED-EARNING

With this consistent setup, the process ensures that the balance by FS item in accounting ties to the balance
by FS item in group reporting for the released data. However, period 000’s data will not be released to group
reporting directly.

1.4.6 Master Data

1.4.6.1 Consolidation Unit

With the activation of the group reporting preparation ledger, there are some changes and restrictions on
consolidation unit master data maintenance.

• It’s not possible to integrate a consolidation unit with a company if there’s no company code
assigned to the company
• It’s no longer possible to define the source of local currency for a consolidation unit. Instead, the
local currency source can optionally be assigned in the Define Versions configuration activity. If no
local currency source is assigned, then the local currency in group reporting is sourced from the
functional currency in accounting. If you’re working in an OP release before OP 2023, then the local
currency in group reporting is always sourced from the functional currency in accounting, and you
can’t assign a local currency source at all.
• To integrate a consolidation unit with a company, the company code assigned to the company must
provide the same currency via the Local Currency Source as the local currency of the selected
consolidation unit. For example, if the Local Currency of the consolidation uni is set to EUR and the
Local Currency Source of the version is set to Freely Defined Currency 1, then the Freely Defined
Currency 1 set for all company codes assigned to the company, which is assigned to the
consolidation unit, must be EUR. If no Local Currency Source was maintained or could not be
 maintained (OP releases before OP 2023), the functional currency is used as the local currency
source. In this case, the functional currency of the assigned company codes is checked.
• It’s no longer possible to define a source for group currency key figure in the consolidation unit
master data. The source for group currency key figure is defined in the Define Versions configuration
activity via the field Group Currency Source.
• It’s not possible to define a deviating FYV of a consolidation unit after the integration with group
reporting preparation ledger is activated. The FYV of the consolidation unit must be the same as the
one assigned to the version.

1.4.6.2 FS Item and Map GL Account to FS Item

The mapping between G/L accounts and FS items is still maintained in group reporting as the normal
process for group reporting master data maintenance.
The specific G/L account mapping to FS items, which is applied during the FS item derivation in an
accounting posting, is derived based on the FS item mapping version in the Define Group Reporting
Preparation Ledger configuration activity. This means that the FS Group Items special version in the Define
Versions configuration activity is not relevant for this. One ledger can only have one FS item mapping
version assigned to it. Additional ledgers are required if additional mapping is needed to derive different FS
item values for different consolidation versions.

1.4.7 Define Validation Rule

1.4.7.1 Validation Rule for Group Journal Entries

You define validation rules in the Manage Substitution/Validation Rules - Group Journal Entries app. These
rules are used in the task Validate Universal Journal alongside the breakdown category check. Posting level
“blank” and posting level “0C” are aggregated before performing the checks.

1.4.7.2 Validation Rule for Reported Data

Content scope 1SG delivers an additional set of validation rules for method SRD1.

1.5 Other Functions Could Be Impacted (especially relevant for existing customers transitioning)
Currency Translation
There’s no direct change in currency translation once the integration with group reporting preparation ledger
is activated.
 • The source of local currency behavior has been changed once the integration with group reporting
preparation ledger is activated. Instead of choosing the source of local currency key figure, group
reporting always uses the functional currency as local currency for each integrated consolidation
unit. Any flexibility needed for local currency must be handled in accounting. With the 2302 Cloud
(OP 2023) release the source measure can be defined in the version configuration. However, it still
needs to be the same measure for all consolidation units.
• The source for group currency key figure is no longer defined by the consolidation unit but is instead
defined by the version.
• If errors exist in the validation of universal journal and the reported data validation and these errors
are not fixed, this will cause a related error in currency translation.
For example, if a subitem was not properly derived, the record might not be included in the selection
defined in the currency translation method. It will not be translated and might cause a rounding error
in currency translation.
• Currency translation and other functions in group reporting have line-item quality checks embedded
(mainly breakdown checks). So, it's important that the errors from the validation of universal journals
task are corrected. If not, errors may occur in currency translation. Note that the log of the currency
translation is not meant to help you correct these errors but rather understand the translation logic.
Analytics and other functions running on sender fields of subitem
Before group reporting preparation ledger, group reporting kept sender fields of the subitem (defined in the
subitem category) in synch with the subitem value even if users or group reporting functions only derive a
value for the subitem. This feature is referred to as back synchronization.
In group reporting preparation ledger the back synchronization is stopped for consistency reasons between
accounting and group reporting, as the original field in accounting cannot be updated.
This means that if a user posts a manual journal in group reporting with a subitem value (e.g. 915) and no
value in the sender field (e.g. transaction type), the field transaction type will stay empty (see first row of the
screen-shot). The same applies for automatic functions such as currency translation / reclassification. If the
currency translation calculates a difference and fills a difference subitem (e.g. 980) the corresponding sender
field (e.g. transaction type) will stay empty (see forth row of the screen-shot).

This leads to a system situation where group reporting customers transitioning to group reporting preparation
ledgers may need to change their reporting / analytics replacing sender fields with subitem.

2 FURTHER OPERATIONS AFTER THE INTEGRATION WITH GROUP REPORTING PREPARATION

LEDGER IS ACTIVATED IN THE PRODUCTION SYSTEM

2.1 Functions Available to Detect Data Quality Issues

• Reports in accounting, such as a trial balance report with group reporting fields and displaying
general journal entries with group reporting fields. For example, you may want to use the trial
balance report of accounting to compare the opening balances generated in accounting and group
reporting on the level of FS items, since in accounting the FS item derivation of the opening
balances (period 000) is not checked anywhere else. Especially, if you intend to use ACDOCA-
based reporting, including opening balances, this check is recommended.
• Realignment via the Schedule Jobs for Consolidation Tasks app
 • The validate universal journal task after data release into group reporting
• The reported data validation and standardized data validation tasks with accounting integration-
related rules.

2.2 Data Correction in Accounting

2.2.1 Manual Reversal and Repost

If a specific master data issue is detected and an impacted accounting document is identified, then the user
can choose to first correct the related setting and then manually reverse the original accounting document
and repost. The reposted accounting document would be subject to the latest derivation logic whereas the
reversal takes the previously derived fields 1:1.
However, this approach is not always feasible. For example, it’s not feasible if there are too many issues, if
the accounting document was generated by an automated document flow, or simply if it just can’t be easily
reposted.

2.2.2 Realignment Function

Realignment can be executed to detect accounting documents that have incorrect group reporting field
values.

2.2.2.1 When to Execute Realignment

Realignment can be executed anytime. How often and when you execute depends on how frequently you
change the derivation logic. If the derivation logic hasn’t changed since the last run of the realignment
program, it will not generate new journals. In other words, it will not do anything.
As the derivation logic implies a lot of system settings, depending on your governance process, it may be
appropriate to plan the execution in preparation of every closing.
The execution of realignment in special periods is also supported.
You may want to consider the following note if you run into error messages in the realignment program:
https://launchpad.support.sap.com/#/notes/3234878Note

2.2.2.2 How to Execute Realignment

Follow these steps to execute realignment:
1. Open the Schedule Jobs for Consolidation Tasks app and select Create.
2. In step 1. Template Selection, select Realign Group reporting Preparation Ledger for the job
template.
3. In step 2. Scheduling Options, select Start Immediately or schedule the job with a specific time.
4. In step 3. Parameters, select the parameters and technical settings for the program.
Mandatory Parameters:
• Consolidation Unit
• Period
• Version
• Fiscal Year
Technical Settings:
• Periodic Mode
• YTD (year-to-date)
• Log
• Test Run
Note:
The setting to execute the realignment program YTD allows the program to use the selected period’s
FS item mapping and breakdown category definition to calculate all the accounting documents for
the year (including opening balance) and make necessary adjustment for YTD data. All adjustments
are posted to the period selected in the parameter. They will not be posted back to previous periods,
even with the YTD setting.
The intention of this mode is to allow you to post a group reporting field reclassification in a YTD view
into the current period. You cannot achieve a YTD data release with this option, such as to integrate
accounting journals from past periods that have been posted after the data release of that period
was done.
Example:
You changed the derivation logic of an FS item from A to B in the middle of the year, specifically in
the middle of period 6.
In periods 0-5 there are 1.000.000 € on FS item A already. In period 6, there are 100.000 € on FS
item A (posted before the change) and 200.000 € on FS item B (posted after the change).
You’re in the period 6 (Q2) close and want to see the cumulative amounts of the year on FS item B,
not FS item A.
You can execute the realignment in the YTD mode.
The result is the reclassification of 1.100.000 € from FS item A to FS item B in period 6.
Periodic calculation will only review the period selected in the parameter and only book adjustments
in the selected period. In this example, it would reclassify 100.000 € from FS item A to FS item B in
period 6.

2.2.2.3 How to Analyze Realignment Results

The realignment program posts adjustments in accounting. The program generates a log to provide the
status of the execution with some additional details.
Analyze Realignment Job Log

Analyze Realignment Adjustment Documents

There are a couple fields in an accounting document that can be used to identify realignment adjustment
postings.
 • Business Transaction Type: Realignment documents will be posted with the business transaction
type GRRA. The relevant field is BTTYPE.
• Reference Document Type: Realignment documents will be posted with the Reference Document
Type field (GRRFP).
• Reference Document Number: The field AWREF carries the run ID of each realignment job run. You
will be able to identify the posting using this field to match the documents generated by a specific run
in the job log.
• Line Item: The line-items are sorted as follows:
- An uneven line-item number indicates the reversal of the old posting lines based on the old
derivation.
- The next even line-item number shows the corresponding new lines based on the new
derivation.
• Text: The item text indicates which group reporting fields were reclassified using the field
abbreviations.
- FS item = RITEM
- Subitem category = SITYP
- Subitem = SUBIT
- Partner unit = RBUPTR
Please refer to the EKT material of the CE 2202 release for more details on how to analyze the realignment
adjustment document.

2.2.2.4 Special Treatment on Opening Balance Adjustments (for YTD Realignments)

Please refer to the EKT material of the CE 2202 release for more details, including an example.

2.2.2.5 Manage Posting Period

To post realignment entries, the accounting period must be open in both the Manage Posting Periods app
and the Manage Posting Periods - Cost Accounting app.
In the Manage Posting Periods- Cost Accounting app, periods are managed by company codes and
business transaction type. Be aware that realignment is controlled via business transaction type GRRA. An
error message appears in the log for a realignment run if the period is not open for this business transaction
type.

2.3 Data Correction in Group reporting using Posting Level 0C

If correcting data in accounting is not possible or not preferred, you can book adjustments in document types
with the posting level 0C to adjust released reported data.
In general, the correction should always have two lines for each record:
• Line 1: Reversal of original record
• Line 2: Correct record with correct value in the validated fields
To better analyze the original records, you can take the following potential steps:

Step 1: Analyze the error messages from validation tasks.

Two tasks can potentially validate the quality of the data and give you the starting point of locating the
document that needs to be corrected.
If the error is found by the validation of universal journal task, then the task log already has very detailed
information on the issue of data. Also, it provides detailed information like the consolidation unit, FS item,
period, subitem category, and subitem. Additional fields are available for the log.
Take the information from this log and continue to step 2.

Step 2: Find out the exact data that needs to be corrected.

Option A: You can use the Display Group Journal Entries app to find the exact entries that have issues.

In this approach, line items in the correction entry can be drafted one by one based on related line items in
each document. Make sure all the fields that have a value in the original document are included in the
correction document (reversal and correction entries).

Option B: You can use the Group Data Analysis app.

Add necessary filters to reduce the data queried in this report.
In this approach, correction entries can be drafted based on the balance of each data block. The data block
should be decided by the combination of all fields where the option Enable Inputs is selected in the
configuration activity Define Consolidation Master Data Fields. All fields for which Enable Inputs has been
selected should be added into the query in either the column axis or row axis to aggregate the data correctly.
This ensures that the correction entry is posted at the necessary granularity.

Option A & B should have the same aggregated amount to be adjusted by FS item, consolidation unit, and
subitem.
Step 3: Provide necessary details in the document for future reference.
A document text can include a short description about the purpose of the document. An attachment can be
used to provide more details about the data analysis process and further notes if needed.

Note: Document types with posting level 0C will bypass consistency checks of the breakdown
category to book the reversal of wrong data. But it will still be subject to the default value derivation
defined in the breakdown category. Make sure required fields are correctly filled with expected
values to avoid creating new issues.
Also note that there may be interference with the correction by realignment. In other words, you must
avoid correcting things twice. Your posting level 0C journal may need to be reversed if you correct
the issue later with a realignment run in accounting and release the data again. Therefore, it’s
recommended to correct issues by adjusting the derivation logic, running the realignment, and
releasing the data again since this will also prevent similar issues from arising again in future
periods.

3 TRANSITION FOR NEW SAP S/4HANA CUSTOMERS STARTING IN CE 2202/OP 2021 FSP1

3.1 What to consider before activating the integration with group reporting preparation ledger
Here are a few things to consider before activating the integration with group reporting preparation ledger:
• Who can be categorized as new SAP S/4HANA customer?
o Customers who are going to start implementing SAP S/4HANA Finance (including
accounting and group reporting) in latest release that’s greater than or equal to CE 2202 or
OP 2021 FSP1.
• The usage of the group reporting preparation ledger is the mandatory default.
o Make sure that the parameter “From Year for Preparation Ledger” is set to 1001 as imported
by the content. Refer to section 1.4.4.1 for details related to this parameter.
• What’ s the derivation logic for additional fields?
o Review the default derivation logic in section 1.3.2 and analyze the potential need to create
custom defined substitution rules.
 • What’s the design in accounting?
o Make sure the design in accounting is aligned with the requirements of the group reporting
preparation ledger.

3.2 Data Cutover

While SAP S/4HANA Finance for Accounting will migrate account balances, group reporting still needs to
consider its own data cutover strategy. For example, the opening balance still needs to be brought into group
reporting as part of the group reporting implementation project.

The go-live time of accounting and group reporting can be different, even on the company code level.
Depending on which module is actively used first and when the derivation of the group reporting fields in
accounting was activated, the first period of using the release task with the accounting integration is
determined consolidation unit by consolidation unit.

Here are some examples:

Example 1: Accounting together with group reporting

- 12.2022: Go-live for both accounting and group reporting
 Accounting takes over historical data in 2022. Group reporting fields are filled from
the beginning based on the correct field derivation
 Group reporting reproduces a group close in 2022.
 Reported data could be integrated using the release task, provided that the data in
accounting is available in regular periods (such as period 12.2022). In other words,
not opening period 000.
 Group reporting does regular go-live activities in period 12.2022.
 Group reporting’s first regular usage with period 1.2023 continues to use the release
task.
Example 2: Group reporting first
- 12.2022: Go-live of group reporting comes first. Accounting data is not yet available.
You source the entire data from external sources, such as with a Group Reporting Data
Collection mapping.
- 05.2023: Company code A goes live in accounting and period 5 is the first regular period
where group reporting fields are derived. Data is taken over as part of accounting go-live into
previous periods of the year.
 In period 04.2023, you may want to compare accounting fields data with group
reporting data and adjust the data where needed.
 You define the integration for consolidation unit A as of period 05.2023 and stop the
external data sourcing in this period instead of using the release task. Note that the
task only integrates the periodic data of period 05.2023.
 If issues arise in the data quality of the derived fields, you can also decide to
continue to not integrate the consolidation unit A in the year 2023. Instead, you can
work on getting the data quality of derived group reporting fields in accounting
correct during the year and start the integration by the release task with period
01.2024.
Example 3: Accounting first, see chapter 4.

4 TRANSITION FOR EXISTING SAP S/4HANA CUSTOMERS

4.1 Scenarios
• Scenario 1: Both SAP S/4HANA Finance for Accounting and Group Reporting are already
implemented and live.
• Scenario 2: SAP S/4HANA Finance for Accounting is live, but group reporting is not yet
implemented.
4.2 What to consider before activating the integration with group reporting preparation ledger in an existing
SAP S/4HANA system
• Make yourself familiar with the changes that come with group reporting preparation ledgers as some
may represent restrictions to existing customers, mainly:
o Loss in flexibility in defining source measure for local and group currency
o Loss in flexibility in definining the fiscal year variant
o Stop of back synchronization of the sender fields of subitems
• Decide which ledger is to be used as the group reporting preparation ledger.
• Review the FYV, the local and group currencies assigned in the ledger.
• Review your reporting and functions on potential impact of stop of back synchronization of sender
fields to subitem and adjust where needed.
• Decide which year to start the integration with group reporting preparation ledger.
It’s strongly recommended to start the integration with group reporting preparation ledger from the
beginning of a new fiscal year. This way, it’s transparent to manage the cutover of a different
integration behavior. The period can’t be defined in the global system settings for the cutover to the
integration with group reporting preparation ledger.
If you must go live with related group reporting preparation ledger changes in the middle of a fiscal
year, be sure to understand the recommendation and risk along with a different decision from the
recommended approach.

4.3 How to Transition

4.3.1 Review Accounting and Group Reporting Configuration

Review the accounting and group reporting configurations considering chapter 1.4. Make the required
changes.

4.3.2 How to Transition Historical Data

It is recommended to perform a transition at the end of the year/beginning of the year.

Balance carryforward in accounting could be used to initialize ACDOCA’s data in period 000 for the year that
the integration with group reporting preparation ledger is activated.
For example, if the From Year for Preparation Ledger is 2022, then the balance carryforward in accounting
will use 999.2021’s master data definition to perform the derivation. In this case, make sure the definition,
such as the FS item mapping, for 999.2021 is consistent with 001.2022 to achieve consistent data quality
starting as of 2022.
If balance carryforward has been executed before the group reporting preparation ledger-related
configuration reaches the production system, you can re-execute balance carryforward with the reset option.
Regular usage of the group reporting data release task starts with period 001.2022.

What if I need to transition during the year?

Transition to the integration with group reporting preparation ledger during the fiscal year is possible if the
transition at the end of the year is not feasible.
If you must transition during the year, be aware of the following points:
- The From Year for Preparation Ledger must be set as the year of the transition, and the system will
behave as if the technical transition happened at the beginning of the year.
- Existing data for the year of transition needs to be handled with caution. This is because the group
reporting fields may only be derived partially in accounting as of the point in time where the
integration with group reporting preparation ledger was activated, regardless of the current posting
period.
For example, if the time of going live for the integration with group reporting preparation ledger in the
production system would be 9AM, May 5th, 2022, then set the value for the From Year for Preparation Ledger
as 2022 and transport it to production.
System Behavior
Time of Action Before 05/05/2022 12:00AM After 05/05/2022 12:00 am
Posting Group reporting fields will be derived for
Accounting No value derived in group reporting any posting with fiscal year >= "from
Document fields. year" (2022).
For years >= "from year": Transfer 1:1;
incremental.
Transformation happens at release For Years < "from year": Transformation
Data Release time. Full data release. happens at release time; full data release.

Cutover Options:
Before 05/05/2022 12:00AM After 05/05/2022 12:00 am
Option 1: • Finish all periods < 04.2022 closing • Consider opening period 03.2022 for
in group reporting and freeze business transaction GRRA. Run a YTD
accounting and group reporting realignment in period 03.2022, and
periods. check on the group reporting field level
• Never re-open accounting periods that accounting and group reporting
and never re-release data for have matching YTD values.
periods < 04.2022 as the release Rationale: If you need to run YTD
task will produce unexpected realignments in future periods of 2022,
results. the data of periods 01 - 03 is aligned
• Consider changing the between group reporting and
consolidation unit master data for accounting on a YTD basis, and only
periods 01 - 03.2022, removing the new changes are reclassified.
accounting integration. • Run periodic realignment in period
04.2022 to fill group reporting fields of
this period.
• Additional accounting documents can
be posted into period 04, if needed.
• Perform group reporting data release in
data monitor for period 04.2022.
• Close 04.2022 with group reporting
preparation ledger.
Option 2: Regular closing in accounting of • Re-open fiscal year 2022's periods 01 -
periods 01 - 03. 03 for balance carryforward and
realignment.
• Re-execute balance carryforward to
2022 in accounting as initialization of
integration with group reporting
preparation ledger (with reset option).
Check accounting prerequisites before.
• Run realignment in accounting in
periodic mode sequentially in periods
01 - 04.2022
• Re-consolidate periods 01 - 03.2022
sequentially in Group reporting,
including data release.
 • Start 04.2022 closing in group
reporting.

o All existing accounting documents posted before 9AM, May 5, 2022, would not have group reporting
field values derived. Any accounting documents entered after 9AM, May 5, 2022 with posting date
after January 1, 2022 would follow the logic of integration with group reporting preparation ledger.
o Starting 9AM, May 5, 2022, from 01.2022 onwards, the data release task will follow the logic of
integration with group reporting preparation ledger in group reporting. This means that when you try
to execute a data release task in group reporting for period 01 - 04, it will not transform data during
the release but transfer group reporting field values 1:1. Also, the regular processing will be
incremental, meaning that it'll only consider deltas since the last release. Therefore, depending on
the option chosen, you may need to schedule the release task as a background job with the full
mode option.
o In this example where periods 01 - 03 were already closed in group reporting, you have two options
to handle prior periods in 2022.
o Option 1: Freeze data for periods 01 - 03, do not reopen accounting periods and group
reporting monitors. Do not try to re-execute the release task for periods 01 - 03. This can be
prevented by changing the consolidation unit master data and removing the accounting
integration for periods 01 - 03.
o Option 2: Reopen period 01 - 03, execute accounting balance carryforward into the year
2022 again. Then, perform the periodic realignment for periods 01 - 03, then re-execute the
group reporting data monitor and consolidation monitor. Reconciliation will be required to
make sure consolidated data is still correct (reconcile before/after reconsolidation).
o In this example, if period 04 couldn’t be closed before May 5th, you need to close period 4 in group
reporting with the integration with group reporting preparation ledger. However, probably all
accounting documents for period 04 were posted before May 5, 2022. Make sure realignment is
executed in periodic mode for period 04 in accounting before proceeding to the data monitor in group
reporting.
It is recommended to ensure data consistency by reconciling group reporting and accounting’s opening
balances for the year once both accounting and group reporting’s balance carryforward procedures are
executed.

5 HOW TO TROUBLE SHOOT

5.1 Why don’t I see group reporting field values in the accounting document in the Manage General Journal
Entries app?
• Make sure you display the journal in a ledger-specific view, not just the general entry view. Only the
group reporting preparation ledgers carry the group reporting field values.
• If the correct ledger view is selected and the group reporting fields are still blank:
- Check configuration settings, such as the global system settings and the group reporting
preparation ledger configuration as described in chapter 1.4.
- Execute a consistency check program which might provide some indication as well.
- Make sure that the consolidation unit is created. The existence of the consolidation unit is a
prerequisite for the derivation logic in the release CE 2202 / OP 2021 FSP01.
- Execute realignment for a specific data region, such as G/L account or consolidation unit, in
test mode to see if any adjustment was detected by the realignment.
 If yes, then the group reporting configuration might be corrected, and documents might be
posted if there was an issue with the setup and mapping. Realignment can be used to fix the
issue in this case. The group reporting fields in the original document will never be modified
once posted.
- Review the group reporting configuration to make sure the entire setup is correct. Execute a
consistency check program, which might provide some indication as well.

5.2 Why didn’t realignment work?

There could be many possible issues while trying to use realignment:
• If you received clear error messages in the realignment job log:
There could be typical cases where you would receive detailed error messages in the log
due to, for example:
▪ Execution of the program before the From Year of Group Reporting
Preparation Ledger is activated. Realignment can’t be used for any periods
before the From Year of Group Reporting Preparation Ledger.
▪ Accounting posting verification error.
• A document number range was not maintained, so posting was
impossible.
• Accounting posting period is not open. Two posting period controls
are in place for realignment and are managed via the Manage
Posting Periods app and the Manage Posting Periods - Cost
Accounting app. Make sure the accounting period is open in both
apps, especially the posting period for cost accounting. Also make
sure the business transaction type GRRA is open.
▪ No transaction data at all in the period selected. When there is no
transaction data in the period selected for realignment, the program will give
an error message indicating the same.
▪ Error indicating the realignment adjustment posting didn’t pass accounting
posting validation.
• You should implement the latest correction notes of realignment.
• You should raise new error messages with SAP support.
• In case you’ve implemented all corrections and still face a lot of
error messages, and if the project timeline does not allow to wait for
the corresponding corrections, you may want to consider starting
with the old accounting integration and then raise an incident. In this
case, SAP support will shift the From Year for Preparation Ledger.
• Refer to note https://launchpad.support.sap.com/#/notes/3234878
for related information.
• If you received a general error message requesting you to contact SAP support, please create an
incident accordingly.
 www.sap.com/contactsap

© 2020 SAP SE or an SAP affiliate company. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.

The information contained herein may be changed without prior notice. Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP or its affiliated companies shall not be liable
for errors or omissions with respect to the materials. The only warranties for SAP or SAP affiliate company products and services are those that are set forth in the express warranty statements
accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop or release any functionality
mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future developments, products, and/or platform directions and functionality are
all subject to change and may be changed by SAP SE or its affiliated companies at any time for any reason without notice. The information in this document is not a commitment, promise, or legal obligation
to deliver any material, code, or functionality. All forward-looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are
cautioned not to place undue reliance on these forward-looking statements, and they should not be relied upon in making purchasing decisions.

SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate company) in Germany and other
countries. All other product and service names mentioned are the trademarks of their respective companies. See www.sap.com/copyright for additional trademark information and notices.