Skip to Content

If you are a consultant or team member working with SAP Financials on an Enterprise Resource Planning (ERP) or Enterprise Performance Management (EPM) project, this blog’s for you.  You have the opportunity to influence the Financial Accounting (FI) blueprint on a new ERP installation, or you are in position to reshape an existing working design.  It is essential to have a broad perspective on your SAP chart of accounts (COA) design and to consider the impact beyond the ERP system how the chart of accounts may integrate with one or more of the SAP EPM tools:

 

  • SAP Business Planning and Consolidation (BPC)
  • SAP Profitability and Cost Management (PCM)
  • SAP Strategy Management (SSM)
  • BusinessObjects (XI)
  • SAP Netweaver Business Intelligence (BI)

 

As a former Platinum Consultant at SAP who has had the opportunity to assist in or review many ERP implementations, and who now works with the EPM applications, I would conclude that the chart of accounts design is often done quite well to meet strictly the needs of the ERP system.

 

Case in point: when comparing legacy to SAP, many SAP projects can point to the success of reducing the number of G/L accounts which have to be maintained.  Indeed, on a typical SAP project, we’ll find that the legacy chart of accounts can be substantially trimmed, due to the nature of how SAP postings work.  It is not uncommon to reduce the number of G/L accounts from tens of thousands in legacy to just a few thousand G/L accounts in SAP.  This is possible because with the SAP posting logic in the Financial and Controlling (FI/CO) applications it is appropriate to eliminate the sub-ledger accounts, the cost centers, the inter-company segments, and other reporting dimensions from the chart of accounts, since these dimensions are captured in separate fields in the account-assignment coding block or in a sub-ledger.

 

However, if the evaluation of the SAP chart of accounts design is viewed more broadly than just the single purpose of meeting the needs of the ERP transactional system, then the grade is lowered.  Let’s look at some of the scenarios that prove to be challenges when trying to integrate the ERP chart of accounts with the EPM applications.  Then I’ll offer some suggested work arounds to these challenges.

1) Group Accounts

A common problem with trying to share a common chart of accounts between ERP and EPM is that planning is often done at a group account level (e.g. Total Salaries & Benefits as opposed to individual, detailed salary and benefits accounts).  To post a plan value at the group account level it means, of course, that the group account must exist in the master data (dimension members) in the EPM application.  Yet the owners of the chart of accounts in the ERP system have no use for the group account to exist in the master data. To remedy this group account issue, I’ll mention that the SAP ERP system provides the ability to assign each G/L account to a group account number (data element BILKT) or to an alternative account number (data element ALTKT_SKB1).  If carefully designed, either of these two fields could be used as the source for the chart of accounts in the EPM application, instead of using the main chart of accounts defined for the ERP system.  To the extent that some customers may have already defined their group or alternative account numbers for other purposes, then creative solutions have to be put forth for solving the group account issue required in EPM.  One creative approach is highlighted next in the discussion on sub-totals, but applies to the group account requirement as well.

2) Sub-totals

Another quandary often faced when trying to integrate the chart of accounts between ERP and an EPM application is how to handle sub-total result values, such as total assets, or net margin or net income.  These sub-totals are not needed in the master data in ERP, because they can’t be posted to and are calculated on the fly in reports.  However EPM applications might directly plan or need to report against these values, without wanting to have to accumulate all the detailed account data into the sub-total levels.  To solve these issues, I am aware of projects which have created financial statement versions in ERP with the appropriate level of summarization they needed for planning or reporting, then through a custom program they have created the necessary master data automatically (either in ERP or NW-BI) by building it from the hierarchy nodes.  This solution is useful because it offers a controlled process for master data maintenance and keeps the source system primarily in the system book of record.

3) Planning-only Accounts

Another frequent problem encountered in an EPM project is the nature of planning is forward-looking and may require accounts that do not yet exist in the chart of accounts sourced from the ERP system.  Fortunately this problem can be addressed easily.  If planning needs special planning-only accounts used for forward-looking or what-if scenarios, then it is simple to create these accounts in the ERP system, but block them from being usable for postings in ERP.  Sometimes I have seen opposition to this philosophy, but the argument against it really does not hold up to the alternative of maintaining the chart of accounts in two places.

4) Account Texts

When looking broadly at the integration between the ERP and the EPM applications with regard to the chart of accounts design, one has to consider that some EPM applications interact with its dimension members (master data) using the account texts, rather than the account numbers.  In other words, the G/L account number may just be an attribute or property of the text values which is available for reporting, but data input and data selections use the text values themselves.  This fact makes it important, more than ever, to adopt standardized naming conventions and abbreviations in the text descriptions for each category of accounts.  Furthermore it makes it vital to avoid using special characters in the master data text descriptions, so that they are not misinterpreted in the EPM application.  Some specific guidance examples are provided below.

 

  • Avoid use of the hyphen ➖ to not be confused with subtraction in a formula
  • Avoid use of the asterisk (*) to not be confused with multiplication in a formula
  • Avoid use of the plus ➕ to not be confused with addition in a formula
  • Avoid use of the ampersand (&) to not be confused with a variable identifier

5) G/L accounts vs. Cost Elements

SAP users know well that the chart of accounts subject is not a simple topic and the fact that one set of accounts exists in Financial Accounting known as G/L accounts and another set of accounts exist in Controlling known as cost elements.  This complication has to be dealt with when attempting to integrate the chart of accounts between the ERP system and the EPM applications.  Which set of accounts is the right source for the EPM application?  In my experience, what works best is to take a superset of both the G/L accounts and the cost elements.  This is the same approach the Profit Center Accounting application took to this dilemma, as PCA was positioned as an Enterprise Controlling application above both FI and CO and sourced its data from both areas of the ERP system.  Thus, it is easy to integrate the chart of accounts between ERP and EPM if you elect to use the generic “Account Number” (data element RACCT) as master data, instead of the G/L account (data element SAKNR) or cost element (data element KSTAR).  If BW is a source to your EPM application, then the equivalent concept is use of the characteristic InfoObject 0ACCOUNT, instead of either 0GLACCOUNT or 0COSTELMNT.

6) Statistical Accounts

Many legacy general ledgers and competing EPM tools maintain statistical accounts for data such as sales volume, number of employees, etc. in their chart of accounts.  SAP offers a different approach.  For example, sales volumes may exist in the financial applications on the same G/L account or cost element as sales revenue, but stored in a quantity key figure (measure) which is different than the amount key figure.  Other types of statistical data such as headcount is typically kept outside of the chart of accounts altogether by what is known as a statistical key figure.  These variations in treatment for statistical data must be dealt with on projects that seek to integrate ERP and EPM applications on a case-by-case basis.  However, I am not aware of any situations that can not be easily accommodated either by maintaining separate dimensionality in the EPM application for the statistical accounts, or merging the statistical data with the main chart of accounts in the load files for EPM.

7) Once Source of the Truth

Too often at SAP projects I see the chart of accounts master list being maintained in a spreadsheet, with the practice of loading a file into the ERP production system at time of go-live.  Then thereafter, updates are maintained directly in Production. The commonly used offline strategy is usually taken for two main reasons.  1) They lack control of the development system resulting in creation of rogue chart of accounts data by unsolicited users.  2) They seek to avoid mistakes in creating accounts that get posted with the wrong field attributes (e.g. functional area) or the wrong numbering sequence.

 

In contrast to the off-line approach, I strongly advocate maintaining a central chart of accounts in the golden development client and promoting this master chart of accounts throughout the SAP system landscape through the SAP transport management system or, even better, through an ALE scenario.  By maintaining the chart of accounts in the golden development system, where no postings should occur, it is possible to delete an account number, for example, if the numbering sequences change, and updates to field attributes are easily handled.  Furthermore, this approach is a controlled process that is easily monitored for its progress, in contrast to the off-line method.  Most importantly, it offers the ability to have a complete and consistent set of master data useable not only for the ERP system for allocation logic, planning layouts, or report definitions but also by the EPM applications – no matter whether the project phase is in development, test, or production.  In other words this methodology, which I recommend, will give once source of the truth.

8) Chart of Accounts <> Financial Statement Items

It’s an incorrect premise to expect that an extraction of the SAP chart of accounts from the ERP system can be used soley for financial statement planning or reporting in the EPM applications.  In many instances, the financial statement item definition is a combination of the account and another object.  Very typically this other object is the SAP functional area, but may also be a grouping of cost centers.  I’ll explain in a separate webblog why so many SAP projects suffer in realizing their financial reporting due to the manner in which they have defined their functional areas.  Then I’ll make a suggestion how this can be improved, especially when viewed from a broader perspective of integration to the EPM products. 

To report this post you need to login first.

4 Comments

You must be Logged on to comment or reply to a post.

  1. Nathan Genez
    Great blog Jeff.

    Another option for point 7 is to utilize SAP’s delivered programs RFBISA10 and 20 to automatically push the accounts to any other SAP ERP system.  It’s not as automated or hands-off as an ALE scenario, but much simpler to implement. 

    The COA is the backbone of any Financial transactional system and key to its longterm success.  That has always been well known.  But with SAP’s multiple ‘ledgers’ within FI/CO, increased product offerings such as BPC, and physical separation of financial activity from reporting, planning, and financial consolidations…  well, it’s an area that customers need to spend even more time up front designing a solution to account for all of this complexity.

    -nathan

    (0) 
  2. Chris Pauxtis
    Often times people look downstream to solve data issues – often the solution to the problem can and should be up river. 

    Thanks Jeff!

    (0) 

Leave a Reply