Expand +



Key Steps to Follow During a Migration to SAP Simple Finance 1503

by Noorul Khan, Consultant, SAP India

October 18, 2016

Learn the necessary configuration, migration steps, post-migration steps, tips, and tricks during an SAP Simple Finance migration.

If you want to implement and use SAP Accounting powered by SAP HANA, you have to migrate the existing user data from the General Ledger Accounting (FI-GL), Asset Accounting (FI-AA), Controlling (CO), and Material Ledger areas. Such a migration of data is necessary because SAP Accounting powered by SAP HANA rests on a uniform data model for all accounting areas. The universal data table ACDOCA contains all the line item documents from FI, FI-AA and CO. All postings of these applications are written to the new table after the installation and migration are complete.

I describe the migration to SAP Simple Finance 1503 with the entire life cycle covering pre-migration, migration, and post-migration steps. I also shed light on real-life lessons learned during this migration.

This will help companies planning to start the journey of migration to prepare and execute the process.

(Note: Before you begin an SAP SAP Simple Finance 1503 migration, the following consideration is required: SAP Note 2119188 should be checked to identify if the industry solutions and other solutions are supported. It is important to get the latest Service Pack Stack [SPS] installed. This reduces the efforts in implementing SAP Notes that could have been a part of the solution had the latest SPS been installed.

You should give special consideration to the following:

Profitability Analysis [CO-PA]: Is the company already using CO-PA? If yes, is it costing-based CO-PA, account-based CO-PA, or both? If account-based CO-PA needs to be activated as a part of migration, it is important to inject enough time in the plan to discuss its impact.

Depreciation areas: Consider the completeness of the depreciation areas and if there will be any additional depreciation areas required [for example, depreciation areas for parallel currencies].

Custom reports and enhancements: SAP promises minimal disruption, but any custom program that writes to a table [which is removed and changed to a view] needs to be re-coded. Such situations need proper consideration. SAP provides a code inspector to check such codes.

Localization: Any specific tax reports and country-specific programs should also be considered and a separate localization consultant with apt knowledge on local taxes should be a part of the team.)

Pre-Checks Before an SAP Simple Finance Migration

The pre-check is a set of programs run to check the correctness and compatibility of the existing system. During all the test phases (e.g., sandbox, unit, and quality box) I would suggest you run the pre-check and migration on a dump of production. It is done before any kind of upgrade or installation.

Furthermore, it is prudent to ensure consistency across modules. SAP proposes the use of some transaction codes that Ajay Maheshwari writes about in “Plan Your SAP S/4HANA Finance Migration with These Tips.”

For a more comprehensive check, SAP provides some reports that can be installed via SAP Notes. Here are the details:

Check prerequisites for New Asset Accounting: (SAP Note 1939592). Among other things, the report checks:

  • If a depreciation area for each parallel currency exists
  • If the periodic posting needs to be run
  • If there is any component (e.g., classic real estate or joint venture accounting) that the new FI-AA does not support

Check customizing settings: (SAP Notes 2240666 and 2129306): Among other things, the report checks:

  • If the currency settings are consistent and adaptable by SAP S/4HANA tables
  • If the fiscal year variant of the company code and controlling area are consistent
  • If the company code validation checkmark is set in the controlling area
  • Are there any valuation scenarios (e.g., transfer prices) that are not compatible with SAP S/4HANA Finance?

Download report RFINDEX_NACC, which is a very comprehensive check report. I recommend you run it at least with the option Indexes vs. Documents for a start. The results will highlight any discrepancy between the table BSEG and index tables (BSXX).

Any discrepancy found in the above check reports should be rectified before proceeding.

Configuration Steps

Several configuration steps for migration of the SAP General Ledger, CO, new FI-AA, and house banks are required, and I describe some of the important ones in this section.

After the successful installation of the SAP Simple Finance 2.0 add-in, the SAP Project Reference Object (SPRO) screen menu has a new node as highlighted in Figure 1.

Figure 1
A new node for migration in the SPRO screen

The new node consists of sub-nodes with a logical sequence (Figure 2) to which you need to adhere.

Figure 2
Logical sequence for migration activities

The first step is activation of business functions. The following business functions should be activated via transaction code SFW5:

  • EA-FIN (Financials Extension)
  • FIN_GL_CI_1 (New General Ledger Accounting)
  • FIN_GL_CI_2 (New General Ledger Accounting 2)
  • FIN_GL_CI_3 (New General Ledger Accounting 3)

The above business functions need to be selected and activated by clicking the active checkbox.

Figure 3 lists important configuration steps required before you run the migration transactions.

Figure 3
Broad configuration nodes during migration

I discuss three of these steps:

  • Preparations and Migration of Customizing for General Ledger
  • Preparations and Migration of Customizing for Asset Accounting
  • Preparations and Migration of Customizing for Controlling
Preparations and Migration of Customizing for General Ledger

To complete the Preparation and Migration of Customizing for General Ledger, you have to complete several steps. I describe the steps in this section.

Migrate General Ledger Customizing

To complete this step, click the execute icon beside the Migrate General Ledger Customizing node (Figure 4).

Figure 4
The Migrate General Ledger Customizing node

The system updates the following tables after you click the execute icon (These tables are needed in the next step, which is Define Settings for Journal Entry Ledger):

  • FINSC_LD_CMP: Comp Code-Dependent Settings for Unified Journal entry ledger
  • FINSC_LD_CMP_AP: Ledger + Company Code + Accounting Principle
  • FINSC_LEDGER: Universal Journal Entry Ledger
Define Settings for Journal Entry Ledger

To complete this step, click the execute icon beside Define Settings for Journal Entry Ledger as shown in Figure 5. With SAP S/4HANA Finance, the most important attributes of the company code now can be seen in a single dashboard.

Figure 5
The Define Settings for Journal Entry Ledger node

After you click the execute icon, the system displays the screen in Figure 6.

Figure 6
The initial screen for unified journal entry

In case you want to make another non-leading ledger, click the New Entries button highlighted in Figure 6.

(Note: Before SAP S/4HANA Finance, there was a specific node for non-leading ledger creation as shown in Figure 7. The same and other related configuration nodes are not available anymore [Figure 8].)

Figure 7
The node to define and activate non-leading ledgers in the SAP General Ledger

Figure 8
Nodes in the SAP S/4HANA Finance environment

Define Document Type Mapping Variants for CO Business Transactions

Another important configuration is to maintain the document type mapping variants. In SAP Simple  Finance 1503, the accounting documents are generated even if there is a cost movement within CO. A document type for such scenarios is required, and the configuration provides flexibility for having separate document types for separate controlling business transactions.

Click the execute icon beside Define Document Type Mapping Variants for CO Business Transactions (Figure 9) to display the screen shown in Figure 10.

Figure 9
Document type mapping for CO transactions

Figure 10
The document type mapping variant

The document type variant buckets all standard CO business transactions. I suggest that you not use the standard 0000000100 variant, but rather create a new one (Z0000000100) by copying 0000000100 and selecting the check box in the Default Variant column to make it a default variant. After you create a new variant and make it a default variant, select the new variant and click the Mapping of CO Bus Transaction to Document Types folder. This action displays the screen shown in Figure 11 in which you provide the document type that the SAP system should use while posting FI documents for CO-initiated transactions.

Figure 11
Map CO business transactions to document types

In the next configuration step, the document type mapping variant (created in an earlier step) is assigned to the company code (Figure 12). Here a default ledger group is also entered.

Figure 12
Assign the document type mapping variant to the company code

A point worth mentioning in Figure 12 is the Default Ledger Group field. Any FI accounting document generated as a result of cost flows uses the ledger group mentioned in this configuration (unless specifically mentioned — for example, via transaction code KB11N).

In some of the CO transactions (for example, transaction code KB11N), the SAP system provides the flexibility of quoting a document type and ledger group as shown in Figure 13. Any entry of a document type and ledger group at the transactional level supersedes the configuration settings.

Figure 13
The initial screen to enter manual repostings of primary costs

Define Source Ledger for Migration of Balances

During migration, the system needs to know how line items and balances need to be filled in table ACDOCA (universal data table). This configuration decides which tables will be looked upon at the time of filling in table ACDOCA. For example, consider a scenario in which a customer has the specifications shown in Figure 14. In that situation, data for table ACDOCA is picked from table BSEG/GLT0 (for years 2008 to 2011) and FAGLFLEXA/FAGLFLEXT (from year 2012 onward).

Figure 14
The source ledger for migration

Preparations and Migration of Customizing for Asset Accounting

Before I explain this step, it is important to understand that FI-AA has undergone critical changes. One of the prominent changes is visible while comparing Figures 15 and 16. Before S/4HANA Finance (Figure 15), the target ledger group could be given manually for every depreciation area, but with S/4HANA Finance (Figure 16), the target ledger group is determined automatically via the accounting principles.

Figure 15
Depreciation areas before S/4HANA Finance

Figure 16
Depreciation areas in S/4HANA Finance

The above transformation of populating account principles and target groups occurs by clicking the execute icon beside Migrate Charts of Depreciation (Figure 17).

Figure 17
Migrate the charts of depreciation

This step does the following:

  • Assigns the accounting principle and ledger group
  • Adjust the option of how to post to the SAP General Ledger
  • Adjusts the transfer of Acquisition and Production Costs values
  • Adjusts the transfer of depreciation terms

(Note: The scope of this article does not include details about the new FI-AA, so I do not discuss these steps any further.)

The next step is to continue with the new FI-AA configuration. Some of the important configuration steps include these three:

  • Define Asset Balance Sheet Accounts of Parallel Valuation as Reconciliation Accounts:

This step is required in case you are migrating from the classic General Ledger and there are multiple depreciation areas that post to the SAP General Ledger via different general ledger accounts per depreciation area.

  • Specify Alternative Document Type for Accounting-Principle-Specific Documents:

With the new two-step posting approach for asset acquisition, the new FI-AA functionality provides you with flexibility for specifying a specific document type for asset-relevant journal entries. If nothing is specified, the system uses the entry document type.

  • Define Clearing Accounts for Non-Integrated Asset Acquisition: This step is an extension of the previous step. With the two-step approach, SAP requires a clearing account. You have the flexibility to choose separate clearing accounts per asset class should there be a business requirement.
Check Prerequisites for Activating Asset Accounting (New)

The penultimate step in the new FI-AA is to run the check report Check Prerequisites for Activating Asset Accounting (New) as highlighted in blue in Figure 18 to make sure new FI-AA can be activated. To run this report, click the execute icon beside Check Prerequisites for Activating Asset Accounting (New).

Figure 18
The check report before activation of new FI-AA

After the check report gives you a favorable result, click the execute icon beside Check Prerequisites for Activating Asset Accounting (New) as shown in Figure 18 to activate new FI-AA . In the screen that appears (Figure 19), select the Actv. option to activate the new FI_AA and save your settings.

Figure 19
New FI-AA activation

Preparations and Migration of Customizing for Controlling

If you are using CO-PA, then the next step is to adapt settings for profitability segment characteristics (Figure 20). This step deletes the segment-level characteristics that were earlier defined via transaction code KEQ3. This is done for all operating concerns that have account-based CO-PA.

Before SAP S/4HANA Finance, it was hard for the system to query huge line item tables (CE1XXXX) due to performance issues. Therefore, the configuration for segmental tables (CE3XXXX and CE4XXXX) made sense as they would hold the segmental characteristic information that was relatively lesser and faster to query upon. However, with the introduction of SAP S/4HANA Finance, performance is not an issue at all, which also means you do not need to select only some characteristics as segmental, and that’s why this step deletes the segmental level characteristics.

Figure 20
The step to delete the segment characteristics

(Note: Account-based CO-PA has assumed great importance with S/4HANA Finance because of its advantage of easy reconciliation with the SAP General Ledger.

SAP understands the flexibility that costing-based CO-PA offers, and therefore, this functionality is being used widely. To bridge the gap and make account-based CO-PA more usable and acceptable, SAP has equipped it with some more features. However, you can still choose to stay with costing-based CO-PA only and get the advantage of SAP HANA speed, but everything else remains the same as before. SAP proposes that you activate account-based CO-PA also, even if you have been using costing-based Co-PA until now. This is because SAP will continue empowering account-based CO-PA further in the coming releases.)

The next step is to activate the operating concern in the following sequence:

  1. Run program FCO_ADD_COPA_FIELD_TO_ACDOCA (via transaction code SE38) to add new CO-PA characteristics to ACDOCA.
  2. After running the program, use transaction code KEA0 to activate the operating concern.)
Preparations for Migration of House Bank Accounts

There are some technical steps (Figure 21) that need to be done to use the new bank account management (BAM) functionality. BAM replaces the bank accounting function.

Figure 21
Migration of house bank accounts

The first two steps pertain to number ranges. The last step, Define Settings for Bank Account Master Data, assigns the number range IDs in the system as shown in Figure 22. You can also define account types, which is a new attribute in SAP S/4HANA for bank accounts. There are other important features that can be defined in this configuration step, but they are available with Cash Management powered by SAP HANA, which requires a separate license.

Figure 22
Details of the Bank Account Master Data setting

Migration Steps

Migration, as can be seen in Figure 23, is a set of sequential steps that involves migration or population of a new structure or enrichment of existing tables.

Figure 23
Migration steps

(Note: I do not cover the entire list of updates or checks the system does with every migration step. My intent is to highlight only some of them.)

Regenerate Core Data Services (CDS) Views and Field Mapping: This step generates compatibility views for general ledger, controlling, banks, assets, cash, and management. It redirects read access from tables to views (e.g., redirect from table BSID to view BSID). It also regenerates the mapping of customer-specific fields. The output of the program should be carefully audited to see if there are any errors in generation.

Migration of Cost Elements: This step checks if there are any inconsistencies in the cost element (e.g., some primary cost elements exist without a corresponding general ledger master data account).The expected results of check passed and zero errors highlighted in red (Figure 24) should be ensured before proceeding further; expected results can be viewed in Figure 24.

(Note: In this article, references to general ledger mean master data that remains the same regardless of whether it is from the classic General Ledger or the SAP General Ledger.)

Figure 24
Check consistency results

Migrate Secondary Cost Elements to Chart of Accounts: With this step all the secondary cost elements become general ledger accounts. The general ledger accounts are extended to all company codes that were assigned to the controlling area (for which the cost element was made).

(Note: Even if the general ledger accounts and cost elements are the same in S/4HANA Finance, their tables (e.g., SK** and CSK*) still are different.)

Migrate Default Account Assignments: This step identifies any default account assignment made directly in cost elements and moves the same to transaction code OKB9 (default account assignment).

Adapt Authorizations: With the merging of the general ledger accounts with cost elements, the authorization needs to be adopted via transaction code PFCG. This is a manual step.

Steps for a Technical Check of Transactional Data

The steps shown in Figure 25 are to check and reconcile the consistency of data.

Figure 25
Check transactional data

Analyze Transactional Data: This step checks the general ledger account open items and open items for accounts receivable and accounts payable. Among other things, it compares the data from BSEG and index tables (BSI* and BSA*). Any inconsistency found needs to be resolved. This is a repeatable step and can be run as many times as required (before the migration check is set).

Reconcile Transactional Data: This step reconciles the transactional data in CO, FI-AA, the Material Ledger, and the general ledger It goes a step further and also audits general ledger account tables and reconciles them with BSEG.

Some of the prominent checks follow (but are not restricted to these):

  • Compare table BKPF with BSEG
  • Compare table COBK with COEP
  • Compare FAGL tables with BSEG
  • Compare database views with the backup tables.
  • Compare Asset master data tables with asset configuration tables.

This is a repeatable step.

Steps During Migration for Enrichment of Data

The steps shown in Figure 26 enrich the existing tables.

Figure 26
Enrichment of data

Enrich Transactional Data: In the earlier version without SAP S/4HANA, the line item tables did not store any reference (e.g., table COEP did not store any reference of its relevant financial document), but this has changed for a speedier query result.

In SAP S/4HANA, the line item tables COEP and BSEG store a reference transaction (AWTYP) and reference key (AWKEY) for a quick reference to each other. This is a great help when the system builds ACDOCA.

Briefly, this step enriches tables by filling:

  • BSEG-fields from BKPF
  • COEP from COBK and OBJNR
  • Profit Center fields into CO line items
  • Company code data into old CO line items
  • Company code data into old CO totals

This is a repeatable step.

Check of Migrated Documents: This is a follow-up check step after the transactional data has been enriched in the earlier step. It checks the BSEG/BKPF fields and also verifies that the BSEG balance is zero. From a CO perspective, it checks if the field BUKRS (company code) is filled up properly. It also checks that the fields ACCASTY (object type), AWTYP, and AWKEY are updated in table COEP.

Migration of Line Items into a New Data Structure

This is one of the most important steps in the migration tree (Figure 27). It builds up ACDOCA from the line items.

Figure 27
Migration of line items

Migrate Accounting Documents to Universal Journal Entry Structure: This step populates table ACDOCA. The document entry in table ACODCA is also called the Universal Journal Entry (UJE) as it combines all relevant sub-modules into a single data string. In the case of CO-PA, UJE also encompasses all the CO-PA characteristics. This step is not repeatable. There is a reset process. If you need to repeat this step, you must reset the tables. This reset process is discussed later.

Check Migration of Accounting Documents to Universal Journal Entry: In this step, the UJE (table ACDOCA) is checked in terms of granularity and amounts. This step is necessary to ensure that ACDOCA holds the correct characteristics and values. While the system performs the check, the following tables or former tables are considered:

  • General ledger tables (BSEG/BKPF)
  • CO tables (COEP/COBK)
  • External and internal total tables for CO (COSP, COSS)
  • SAP General Ledger line item tables, including industry and customer tables
  • Document header (ANEK) and line items (ANEP) for new FI-AA

This step also compares the compatibility views with the original values. This step is also a repeatable step.

Migrate General Ledger Allocations: The SAP General Ledger allocation before SAP S/4HANA Finance read the data from table FAGLFLEXT (in the SAP General Ledger) or GLT0 (in the classic General Ledger). With the introduction of SAP S/4HANA Finance, however, there is not any totals table, and therefore, the program code needs to be redirected to a view ACDOCT (Figure 28). This step does the redirection. It processes the entries of table T811*.

Figure 28
Redirection of the totals table

Migration of Balances

Not everything can be populated from line items—for example, balances from carry forward or archived historic line items. The amount for such line items is calculated by comparing the sum of the line items with the old totals. The steps under Migration of Balances, as shown in Figure 29, populate the balances in table ACDOCA.

Figure 29
The steps for migration of balances

Migrate Balances: This step populates ACDOCA again, but unlike the earlier step of line item migration, this step migrates only balances. Such balances can erupt from a mismatch of line item tables versus totals tables. Any genuine mismatch is inserted in ACDOCA. This ensures that the totals in various components are the same as before. The step covers FI-AA, CO, the SAP General Ledger, the Material Ledger, customer balances, and vendor balances. If you need to repeat this step you have to reset the tables.

Check Migration of Balances: After table ACDOCA has been updated with totals (in the previous step), the system tries to match the results. This step compares the totals table (*_BAK/*_BCK) with table ACDOCA. Table 1 lists some of the backup tables and views that are used during processes for this step.


Table or view

Asset management




Customer or vendor balances


Material valuation


Table 1
Backup tables and views used during the Check Migration of Balances step

Calculation of Depreciation and Totals Values During Migration

These steps shown in Figure 30 calculate depreciation and compare it with the earlier depreciation amount.

Figure 30
Calculation of depreciation and total values

Calculate Initial Depreciation Values: This step calls the program FAA_DEPRECIATION_CALCULATE and re-calculates the depreciation. Furthermore, it populates the new table FAAT_PLAN_VALUES.

Check Initial Depreciation and Total Values: This step checks the earlier depreciation and the new one. Any change appears as an error. The list of such assets with errors can be obtained by running program FINS_MIG_AA_CHECK_RC45. This program is helpful in both checking the initial depreciation and checking the migration of balances as shown in Figure 31.

Figure 31
Check results for the initial depreciation calculation

Migrate House Bank Accounts

With the introduction of SAP S/4HANA Finance, bank accounting has changed. The new solution is called Bank Account Management (BAM). From a bank accounting perspective, the bank account master data in BAM has far more details in its master data and can be configured via Webdynpro.

In the new world the house banks are not customizing objects, and the data from former table T012K is copied into a new table: FCLM_BAM_ACLINK2 which has some more attributes.

New attributes (e.g., saving or current or other account type) can be assigned to bank accounts. All these activities can be done via the Migrate House Bank Accounts step as shown in Figure 32.

Figure 32
The step to migrate house bank accounts

Complete the Migration

It is important to understand that this step cannot be undone, so the first check should be to run the reports again and compare them with the reports taken before SAP S/4HANA Finance. After the business confirms the accuracy of the reports, the next step is to mark the system for migration complete (Figure 33). To do this step, click the execute icon beside Set Migration to Completed.

Figure 33
Set the migration as complete

Post-Migration Steps

Figure 34 shows the post-migration steps. These steps ensure that the due dates and offsetting account are filled in in table BSEG.

Figure 34
Post-migration activities


Here is a list of tips for you to review:

  1. Make sure to regenerate all the reports in the relevant library for cost center, vendors, and customers after the migration is completed. Use transaction codes GR55, FDIM, and FKIM for the purpose.
  2. Make sure that the general ledger technical clearing account for the integrated asset acquisition is made before releasing the system to the business.
  3. Update the financial statement versions to include all the general ledger accounts (secondary cost elements and asset technical clearing account).
  4. Make sure that the new document type CO is configured for document splitting properly.
  5. The transaction code FINS_MIG_STATUS provides a bird’s-eye view of the migration steps and their status (Figure 35). You can go directly to the relevant migration step by clicking it. Other details can be found under the tabs Control and Tables.

Figure 35
SAP Simple Finance 1503 migration status

At times the errors for a single migration step can run in the thousands, divided under several packages. In such cases an Excel dump to analyze all errors can be of great help. However, such an Excel dump functionality of all errors in all packages is not available. A workaround is to query the following tables in transaction code SE16n. These tables provide all the errors in a single screen and taking an Excel dump of all of them now becomes possible.

  • FINS_MASSPACKAGE: Package details on the basis of the step run
  • FINST_RECERR_ACD: Reconciliation error ACDOCA
  • FINST_RECERR_CT: Reconciliation error GL (customer tables)
  • FINST_RECERR_CTG: Reconciliation generic error GL (customer
  • FINST_RECERR_FI: Reconciliation error AP/AR/GL
  • FINST_RECERR_GEN: Reconciliation error (generic)

Table 2 shows how various migration steps can be reset and re-run.






Analysis of transactional data


 Set ID > R20


Reconciliation of transactional data


 Set ID > R21


Enrich transactional data


 Set ID > ENR


Check enrichment of transactional data


 Set ID > R22


Data migration into unified journal: line items


 Set ID > MUJ


Check migration of journal entry


 Set ID > R23


Data migration into unified journal: aggregate deltas


 Set ID > DLT


Check migration of balances


 Set ID > R24


Initial depreciation calculation


 Set ID > AFA


Check initial depreciation calculation


 Set ID > R25

Table 2
How to reset and re-run migration steps

An email has been sent to:


Noorul Khan

Noorul Q. Khan ( is a chartered accountant and an SAP certified professional with more than 12 years of total experience, including eight years of consulting experience in SAP FI/CO. He has been a part of many full-cycle implementations, as well as SAP S/4HANA, audit review, and expert consulting projects as FI/CO lead.

He works as a consultant at SAP India (SDC) and lives in Bangalore with his wife and two children.


Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!