Skip to Content
Technical Articles
Author's profile photo Aydin Memioglu

Central Finance – Lessons Learned Master Data objects (Part1 – G/L Accounts)

Introduction

Having been involved in various SAP project implementations we all know how critical the learnings from a project are and how they can help us if we face the similar situation again.

We are a group of consultants at SAP dedicated to gather valuable lessons learned during CFIN projects and share within the external community. Our main objective is to elaborate on lessons learned in regards to harmonization and mapping guidelines for financial and non-financial master data objects.

This is the first blog of its nature to be followed by additional blogs in the future in regards to a variety of topics where valuable lessons could be gathered.

The following blogs will be published separately broken into 3 parts:

  • Part 1 – General Ledger Accounts (current blog)
  • Part 2 – Controlling master data object
  • Part 3 – Business Partner/non-financial master data

 

Overview

For any transactional data to replicate successfully into CFIN, Master data is critical. Master data required for CFIN can be mainly categorized into two main parts:

1. Financial Master Data

  • General Ledger Accounts
  • Cost Elements
  • Profit Center
  • Cost Center
  • Short-Lived Master Data (e.g. Internal order, Production order, Maintenance order)

2. Non-Financial Master Data

  • Customers/Vendors (Business partners)
  • Materials
  • Plants

The following chapters will provide an overview, harmonization & mapping guidelines as well as lessons learned focusing on the General Ledger Account.

 

Financial Master Data

General Ledger Accounts

Overview

  • G/L accounts are part of the Chart of Account.
  • Source systems have different Chart of Accounts. Goal is to come up with single harmonized Chart of accounts in Central Finance system.
  • The G/L account master records control the posting of accounting transactions to G/L accounts and the processing of the posting data
  • With central finance implementation as source financial transactions are replicated to CFIN, GL account is one of the main master data object that needs to be created.
  • The GL accounts settings of mapped GL accounts in the Central Finance system, must be compatible with the ones in the source system.
  • A G/L Account can have multiple attributes. Some of these attributes can be critical, some of them not when defining the mapping.

Lessons Learned

a. Field Status Group

  • Defined in company code specific area of each G/L account

  • Determines which fields are ready for input (optional), which are required entry fields (mandatory), and which are hidden during document entry (suppressed)
  • Harmonizing and defining the mapping for the Field Status Groups, especially when more than 1 ERP are involved in the exercise, can become cumbersome
  • Considerations for Mapping:
    • If the source accounts have different field statuses comparing to the field status of the target system, one of the options is to set up the field statuses for the target account fields as optional.
    • If mapping is required for Field Status Groups then all the fields must be analyzed and the Central Finance systems always needs to be more permissive than the source system.
    • If a field is optional in source, it could technically be defined as required entry in target. However, it may represent a big risk of error in cases when the field is not populated in the source.

b. G/L Account Type

  • G/L account type classifies the G/L account
  • G/L account type determines how the general ledger account can be used in financial accounting (FI) and controlling (CO)
  • In S/4 HANA cost elements become part of chart of accounts and are maintained in G/L Master data. Subsequently, secondary cost elements are now GL Accounts (in contrast to SAP ECC source systems)
  • Traditionally in ECC, Cost Elements (Management Accounting) were kept separate from G/L accounts (Financial Accounting)
    • ECC:
      • Primary cost elements: Master record created separately in FI and CO
      • Secondary cost elements: Master record only created in CO
    • S/4 Hana:
      • Primary cost element (FI and CO is merged): only one master record is created in FI (G/L account)
      • Secondary cost element: Moved to FI. Only one master record is created in FI (G/L account)
  • In S/4Hana new account types are introduced to differentiate by primary cost/revenue and secondary cost:             

  • Considerations for Mapping:

c. Open Item Management

  • Items posted to accounts managed on an open item basis are marked as open or cleared
  • The balance of these accounts is always equal to the balance of the open items.
  • Considerations for Mapping:
    • As a general rule. when harmonizing and mapping GL accounts you need to consider mapping OIM to OIM and Non-OIM to Non-OIM GL accounts
    • Mapping OIM to Non-OIM accounts can lead to inconsistencies for the subsequent postings (such as clearings, reversals) when document splitting is active.
    • Mapping Non-OIM accounts to OIM accounts is permitted. However, this will require maintenance in the target system. Please consider testing this very carefully during the project implementation. (Example: In a reporting scenario any items which were reposted from source to target from a non-OI managed GL account in source will now have status open in target system. These items will remain open in target system and won’t clear unless cleared directly in target.)

d. Reconciliation Account

  • The reconciliation account ensures the integration of a subledger account into the general ledger
  • Reconciliation indicator characterizes the G/L account as a reconciliation account

  • Consideration for Mapping:
    • Asset Accounting is not supported in CFIN, the reconciliation account of asset must be mapped to non-reconciliation account
    • Replicated FI documents which originate from asset postings in the source system are not posted to FI-AA in the CFIN. Instead, they are only posted to General Ledger (FI-GL) in CFIN using posting keys 40 and 50

 

e. Tax category

  • The Tax category determines whether the following apply to the G/L account
    • Is it Tax relevant? You decide whether you want to use the account for tax-relevant postings. If not, leave the field blank.
    • Is it a Tax account? You decide whether you want to use the account exclusively for posting taxes (< input or > output)
    • Is it Tax-relevant G/L account? You decide whether you want to use the account as a G/L account to which you make tax-relevant postings. E.g. when you post to a certain P&L account you have to provide a tax code during posting (+ Only output tax permitted – Only input tax permitted * All tax types permitted)

  • Consideration for mapping:
    • The recommendation is to set the tax category in target system as similar as it is in the source system
    • If this is not possible, then the setting in CFIN needs to be more permissive than the one in source system
    • Output tax in source with output tax in target
    • Input tax in source with input tax in target
    • If an account in CFIN has a tax category that is more strict (e.g.: +) than the one in sender system (e.g.: “*”), there is a risk for some documents to end up in error. (e.g. tax code in source document which is not in line with the tax category of the target account in CFIN.
    • Empty category in source with any category in target will work.

f. Posting without tax allowed

  • Indicates that the account can still be posted even if a tax code has not been entered.
  • If you do enter a tax code when posting to this account, the system checks the entry against the tax category.

  • Considerations for Mapping:
    • The recommendation is to set this indicator same as it is in the source system
    • If you have this set for GL in source, then it should be set in the target GL as well
    • If you have n:1 mapping and there is at least one account that has the flag set, then you should also set the flag for the target account. Otherwise there is a risk that documents will end up in error for those accounts (see explanation in previous section)

g. Account currency

  • The Account Currency indicates the currency in which the account is held (e.g. USD, EUR, etc.)
  • If a currency other than the company code currency is specified, users can only post items in that currency to this account.

  • If the company code currency is specified, users can post items in any currency to this account.
  • Considerations for Mapping:

h. Clearing specific to ledger group

  • This indicator becomes relevant if you are implementing Parallel Accounting using Ledger Approach
  • The indicator “Clearing Specific to Ledger Group” (CStLG) needs to be activated for the accounts that need to be managed as open items and are used in postings to specific ledgers

  • Standard “Open Item Management” indicator does not accept ledger specific postings
  • Customizing sequence to be considered:
    • It is not permitted for any automatic postings to be made to an account with clearing specific to ledger groups.
    • During G/L Account creation entries in automatic account determination tables (e.g. T030) are checked. System will raise an error if an entry is found in any of the account determination tables with G/L account -> CStLG flag is not allowed to be set.
    • However, please note that there is no system check at the moment of maintaining the account determination. In other words, in case the G/L account that you want to maintain is already set with the CStLG flag, the system will not trigger any error or warning message to prevent this from happening.
    • if this customizing is done in this sequence, without considering the standard restrictions mentioned above, the replication of documents that are using those accounts, will end in error during accounting interface checks.

 

Hopefully the above concepts, valuable experiences as well as lessons learned which we gathered from various projects and teams across our organization will help you to overcome similar challenges which you might face during your projects.

We invite you to post any feedback, ideas, or tell us how this content was helpful for your project.

Please also look out for lessons learned blogs Part 2 (CO-objects) and Part 3 (Business Partner/nonfinancial master data) as well.

Best wishes.

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Kyle Lawrence
      Kyle Lawrence

      Thanks for sharing the great information. Looking forward to parts 2 and 3.

      Author's profile photo Jonathan Negash
      Jonathan Negash

      This is great information. Thank you again for taking time to share your knowledge and lessons learned list.