In this blog series, we are looking at some of the challenges and risks that most commonly affect SAP S/4HANA conversion projects and how to mitigate them with the right selection of tools and approaches. In the previous blog Conversion to SAP S/4HANA On-Premise –  what are the key problem areas (and what to do about them)? I tried to outline areas where customers usually experience difficulties when converting from SAP ERP to SAP S/4HANA.

As explained earlier, one of the most critical phases of any conversion to SAP S/4HANA is the financial data migration. For more information, please check out the blog Conversion to SAP S/4HANA- Insights into Finance Data Migration.

We already talked about how important for successful financial data migration is to have clean and consistent transactional data, how a company can end up with data inconsistencies and what impact it can have on the conversion project plan. Let’s remind ourselves, that no matter how well you manage the integrity of your data, chances are that you are going to have some errors in it. Therefore, in this and the next blog post, I will focus on tools which help us to detect inconsistent financial data. We are going to talk about various programs available in the system for checking financial data before, during and after conversion to SAP S/4HANA.

In general,  we can classify these check programs into several categories. We have consistency checks which are to be performed in the source SAP ERP system before the technical installation of SAP S/4HANA and we have check programs running in the target SAP S/4HANA system. We recognize a configuration, master data and transactional data consistency check.  According to component, we have consistency checks in different finance related application areas: in General Ledger, Asset Accounting, Materials Management etc.

In this blog, we will go through consistency checks based on the phase in which they are to be performed. In the first part of this blog, I will explain checks which you should run in the Preparation phase, in the source SAP ERP system. In the second part of the blog, we will explore the consistency checks available in the Realization phase, just before or during financial data migration. So first, let’s take a look at the Preparation phase.

Consistency Checks in the Preparation Phase

Consistency checks are the important part of preparatory activities which are to be performed in the source SAP ERP system before installation of SAP S/4HANA. Here we have 2 types of checks.

Configuration and master data consistency checks are newly developed programs specifically for conversion to SAP S/4HANA. They check whether functional and configuration prerequisites for conversion are met.

Transactional Data Consistency Checks include programs for reconciling General Ledger totals with Sub-ledgers totals (, GL<>FI-AA, GL<>MM, GL<>ML, GL<> EC-PCA  etc.) and a couple of programs for checking data consistency of selected tables (i.e. document tables <>indices etc.).

All these programs have been around for a long time. The majority of them are recommended to be executed on a regular basis as a part of a closing process in Finance. There are high chances that you know them and already ran them in the past.

Configuration consistency checks

 

Simplification Item(SI) Check is a new tool available as of release 1709. It contains not only the configuration but also master data and few transactional data consistency checks. It comprises checks in various functional areas. In Finance, SI check replaces the former pre-conversion check of general ledger customizing (program FINS_MIG_PRECHECK_CUST_SETTNGS). The Finance pre-checks, contained in the SI check, examine the consistency of your ledger, company code and controlling area settings to determine whether a financial data migration is possible.  The list of checks, possible root causes for errors and their solutions are described in detail in the SAP note 2245333 Pre-Transition Checks for FIN: Error Messages and Possible Solutions.

For further details on how to implement and run SI check, please refer to the blog of Markus Goebel SAP S/4HANA Simplification Item Check – How to do it right which is being continuously updated with the latest information.

Check of prerequisites for FI-AA Migration – Checks for functions and configuration not permitted. The program has been integrated into SI Check starting from release 1809.

 

Transactional data consistency checks

Reconciliation of AR/AP sub-ledgers with General Ledger

 

Comparative analysis reports – there are 2 comparative analysis programs, SAPF190 for a system with classic General Ledger and TFC_COMPARE_VZ for a system with new General Ledger implemented. They are used to compare values from document line item tables with transaction totals tables and with the secondary application index tables

TFC_COMPARE_VZ makes a comparison between the following tables:

1. Document lines (BSEG/BSEG_ADD) with secondary indices(BSIS/BSAS/BSID/BSAD/BSIK/BSAK)
2. Document lines (BSEG) with AR/AP sub-ledger totals (KNC1/3 LFC1/3 )
3. Document lines (BSEG/BSEG_ADD) with new GL line items (FAGLFLEXA )
4. New GL line items (FAGLFLEXA ) with new GL totals (FAGLFLEXT)

If the program finds any discrepancies or inconsistencies, it will highlight them store them in a log.

In case of inconsistencies between the FAGLFLEXA and the FAGLFLEXT  you may the report TFC_ADJUST_VZ  to correct them. However, If there errors from the single document comparison i.e. between the Entry view (BKPF & BSEG) and the NewGL view (in FAGLFLEXA), the correction report will not run.

You may also refer to the following  wiki articles:

FI Consistency check (program RFINDEX ) consists of ten functionalities which can be activated by flags in the selection screen.

1. Reconciliation of the document tables (BKPF) against the index tables (BSIS/BSAS/BSID/BSAD/BSIKBSAK )
2. Reconciliation of the index tables (BSIS/BSAS/BSID/BSAD/BSIKBSAK) against document tables (BKPF)
3. Search for missing document headers (BKPF)
4. Reconciliation of document headers (BKPF) against line items (BSEG)
5. Check clearing transactions
6. Reconciliation of documents against transaction figures
7. Reconciliation of indices against transaction figures
8. Open item as at the key date
9. Find double entries in the index table
10. Check accounts/FS.

The disadvantage of the RFINDEX is that very often it lists inconsistencies which do not have any impact on conversion. It means that not all errors reported need to be also corrected. If RFINDEX detects inconsistencies, please contact SAP support which is able to run the program in update mode to correct data.

Please note that runtime of FI Consistency Check and FI Comparative Analysis can be significant,

Reconciliation of Asset Accounting (AA) with General Ledger

 

There are two dedicated data consistency check programs for Asset Accounting (transaction codes ABST and ABST2). In addition, you may find standard asset reports such as Asset History Sheet (report RAGITT01) or Asset Balances (RABEST01) helpful when evaluating the consistency of asset accounting data.

First, you execute ABST2 which identifies all G/L accounts where is there is a discrepancy between GL account balance and Asset values:

Reconciliation  FI-AA and G/L (transaction ABST2) selects the asset summary records (ANLC), summarizes the values on G/L account and business area levels, and writes the summarized values to table EWUFIAASUM. Then this table is read, and the values are reconciled with the G/L accounts. The output of the program is a list of GL accounts per company code with differences in amounts between AA and GL.

In the next step, individually for each of the affected GL accounts, you run:

Consistency Check of General Ledger and Asset Accounting (Transaction ABST) is used for reconciliation of AA  values with G/L account postings on individual G/L account level. In the first step, the asset line items (ANEP,ANEA) for each fixed asset are summed up and compared with the asset summary records (ANLC). In the second step, asset line items (ANEP) of a fixed asset are summarized per each document number and compared with the G/L account line items (BSEG and FAGLFLEXA in case of new GL) posted to this fixed asset. You can run the consistency check only for asset balance sheet account with line item management active and in the depreciation area which posts online.

Most common reasons for differences and how to solve them:

Please refer to the following  SAP Notes

• SAP Note 2032547 – Reconciliation FI and FI-AA. ABST2 Differences
• SAP Note 543151 –   FAQ Note Reconciliation of FI <-> FI-AA
• SAP Note 104567 –   Collective note Euro FI-AA: Analysis phase

Reconciliation of Materials Management (MM) with General Ledger

 

We have 3 programs available to reconcile MM with General Ledger. The core functionality is the same for all 3 of them, they compare the balance of stock GL account balance with the total of stock values as recorded in Materials Management/Material Ledger. They display the total value of the stock together with stock G/L account balance and any deviations between them. The program RM07MBST is the oldest and is able to read stock values on an individual material level from MM tables. The program RM07MMFI was developed as a faster alternative to RM07MBST as it reads values from MM tables on the valuation area level. The program FAGL_MM_RECON is primarily designed to read stock values from Material Ledger. If material ledger is not active, it reads values from MM tables.

Please refer to the following SAP Notes for most common causes of differences and possible solutions:

• SAP Note 968812 – MM/FI Difference for material stocks
• SAP Note 520010 – FAQ: Inconsistencies in inventory management

Reconciliation of Special Ledger (SL) with General Ledger

 

Ledger comparison (transaction GCAC)  compares the totals records of any two ledgers. You can use this program to compare standard general ledger totals with any standard or customer-defined special ledger totals table. You can use in system new GL activated with leading ledger 0L (table FAGLFLEXT) or classic GL with ledger 0 (table GLT0). Because it is a generic transaction it works with all applications which are based on the special ledger concept including classic Profit Center Accounting ledger 8A (table GPCT) and EC-CS consolidation staging ledger 09 (table GLT3) or consolidation ledger 1C (table ECMCT).

If the program finds any differences, you may also refer to SAP Note 729433 – Differences between SL and GL for possible causes and solutions.

 

Reconciliation of Profit Center Accounting with General Ledger

 

If you use classic Profit Center Accounting (EC-PCA), you need to reconcile Profit Center Accounting ledger (8A) with General Ledger.  For this you can execute either transaction KE5T (for classic GL only) or transaction GCAC (for both, classic GL and New GL).

Compare G/L Accounts in FI with Profit Center Accounting (transaction KE5T or KE5U)

The program compares Profit Center Accounting totals (table GLPCT) with classic GL totals (table GLPT0). If the program finds any differences, please refer to SAP Note 81374 for possible causes and solutions.  You may execute the program with the option to clear differences automatically). If you reconcile the differences automatically, the clearing records are posted in tables GLPCT (summary record table) and GLPCA (actual line items). The clearing postings are posted with origin object type 98. You can analyze these line items in line item reporting by specifying this origin object type.

Ledger comparison (transaction GCAC)

If New General Ledger Accounting is active in your system, you have to use the generic transaction GCAC for comparing ledgers. Here, you can enter any base ledger and any comparison ledger. For Profit Center Accounting you enter ledger 8A (table GLPT0) and for new general ledger 0L (table FAGLFLEXT).

Conclusion

As you can see, there is a number of consistency checks to be run in the source SAP ERP system. In the next blog, we will look into consistency checks in the Realization phase. These are the checks which are supposed to be executed in a target SAP S/4HANA system after technical conversion (after SUM tool installed SAP S/4HANA software components). In addition, we will discuss why these checks are more detailed and able to detect data errors which failed to be noticed by checks in the source SAP ERP system.

What is your experience with inconsistent data? What would you improve in SAP consistency checks? Share your thoughts in the comments below!

Brought to you by the SAP S/4HANA RIG