In my last Beyond ERP – Improve your SAP Chart of Accounts design to integrate with EPM I discussed some key considerations that will improve the integration between ERP and EPM regarding the chart of accounts design. Today I am writing on a related topic to improve the design and use of the field in Financial Accounting called the Functional Area. Together the chart of accounts and the functional area are often the building blocks for defining the items in the financial statements when the company presents its P&L using the cost-of-sales accounting method in the ERP system. However, I’ll explain in this blog why EPM users should consider using only the functional area field to define their line item or account dimension used for financial statement items. This option necessitates a re-examination of the functional area design that starts in ERP. Let’s take a deeper look at this topic.
With the cost-of-sales accounting income statement, sales revenues are matched to the costs or expenses involved in making the revenue (cost-of-sales). The expenses are listed in functional areas as the example is shown below.
Producing a cost-of-sales income statement in a typical legacy general ledger systems is achieved by simply defining the appropriate ranges of G/L accounts for each P&L row, since their chart of accounts probably will have included a departmental segment that is representative of the function. However, given the architecture of the financial applications in the ERP system which separates the general ledger in Financial Accounting from the management ledger in Controlling, producing the cost-of-sales P&L is not as straight-forward, compared to other general ledgers.
Salary expense example
Realize it is possible and advisable to have a smaller chart of accounts in SAP than usually found in legacy G/L’s. In fact, the SAP chart of accounts will reflect only the natural categorization of the expense. For example, you may have only one salary account, rather than a separate salary account for each cost center (department).
But think about how salary expense is included in multiple lines on the P&L. The salaries of the manufacturing supervisors are part of the cost of goods sold line, warehouse management salaries are in the distribution costs, plant and headquarters management costs and support function salaries are included in the administration section, the salaries of the engineers and scientists are rolled into R&D expenses, and so on. How is this achieved? The apparent answer would be to define the P&L rows using both the G/L accounts and the cost centers, but that approach is not recommended by SAP.
A brief history lesson
It is helpful to understand the origins of this issue. In what is now referred to as the “classic G/L”, SAP made the design decision to not encumber its general ledger reporting tables with the cost center field. (For emphasis, I make the distinction between a reporting table (e.g. GLT0) verses the document line item table (BSEG) which does contain the cost center field). To the architects at the time, it would not have been good judgment to add hundred or thousands of rows of cost center detail to the general ledger, in order to be able to summarize it back to a few lines on the cost-of-sales accounting P&L. Thus the idea of the functional area field was born. The trick was to utilize the account assignment objects (such as the cost center, or the WBS element, or the order) provided in the posting to determine the “functional” nature of the expense and to update the reporting tables (GLFUNCT, GLPCT) by this new functional area dimension. The result was the cost-of-sales type P&L could be rendered using the functional area or a combination of the accounts and the functional area, while still keeping the financial reporting table(s) relatively small to minimize any performance deterioration that would have occurred if the cost center field were to be added.
[For completeness I will mention, lest I’ll hear from you, that with the “New G/L” that has been available since the release of SAP ERP 2004, the cost center field is now available in the general ledger reporting tables.] However, the functional area field persists there too and is still the preferred way of creating cost-of-sales P&L statements.
In my prior solution review experience at many ERP projects, I have often seen the functional area field defined to provide only the few lines of detail needed below net sales on the P&L. In a typical installation, the functional areas often included lines for cost of goods sold, distribution, general and administrative, selling, and R&D. The functional areas did not typically include balance sheet accounts or top-line P&L accounts, such as revenues and discounts. But this design of the functional area posting logic causes some FI document lines items to have a blank functional area (balance sheet and P&L accounts through net sales, for example), while other line item expenses to have the functional area field populated.
The above design of the functional area posting logic is common practice and works for ERP-based reporting. In order to produce the P&L in the ERP system, it involves creation of the Financial Statement Version. The financial statement version can be defined using G/L accounts, functional areas or a combination of both of these elements.
However the design and use of the functional area as described above does create issues when attempting to deal with financial planning and reporting scenarios in other applications, such as with Netweaver BI or the EPM tools. I’ll explain more shortly, but first I will mention one shortcoming that exists even in the ERP system book of record.
Audit and Controls
From a financial audit and control perspective it is better to have the functional area field always filled and an error message output from a validation rule if the functional area is not derived in the posting. Otherwise if the functional area is not filled on each line item, it may be just intended or it could signal a missed assignment or substitution rule, an event you would not want. Of course, a similar validation rule could be used to verify a functional area is derived when expected for a subset of accounts, but it would require more advanced prerequisite logic to look for certain ranges of accounts and/or to check for the existence of cost objects. In other words, it is easier to issue an error message, if the functional area is not populated in the financial document, and this is a more consistent and complete design for the audit team to sign-off on.
Since not all common practices are indeed best practices, I would like to recommend to you what I consider to be the best practice for the functional area design. Namely, to define the functional area as the lowest level that you seekto show on your financial statements, then to create a financial statement version hierarchy without accounts by using only the functional area. This means, of course, that every financial posting needs to have the functional area filled no matter if it involves a balance sheet account, a revenue account or a discount account. What does this alternative design offer? It becomes obvious when attempting to utilize other tools beyond ERP for financial planning and reporting. Let’s look at a common issue that arises in BW if the common functional area design scenario exists.
A frequent and undesirable problem that I came across on SAP projects was a lack of drill-down from the financial reports. This manifested when attempting to create financial statements using the BEx Analyzer reporting tool within the SAP Business Warehouse. Financial users demand the ability to run financial reports and drill-down into details of what caused a variance on a report, for example. If they see a variance in the distribution section of the P&L they want to drill-down and see if it was caused by warehousing or transportation, for example. If it was in warehousing, they may want to know was it at company-owned warehouses or leased space, and so on. They want to keep drilling down in logical groupings of expenses until they reach the detail level. Ideally, users are able to traverse a hierarchy of financial statement items to do this analysis, and they can open or close a hierarchy node at their will, without having to see all row expansions at once. Nor do they want to be presented a financial report that contains the list of accounts in one column and the list of functional areas in the next. This output creates an almost unreadable grid effect, but it is prevalent in BEx reports that attempt to use a hierarchy along with another drill-down characteristic in the lead columns.
To present the cost-of-sales P&L appropriately formatted in BEx, it may be necessary to define the rows individually using a combination of both the chart of accounts and the functional areas. In BEx, this query definition must contain what is known as a row structure. In practical usage, structures greatly limit the ability for users to drill-down in an ad-hoc way. Typically, report-to-report jumps have to be setup before hand. Creation of structures and creation of jump queries are usually only handled by a small group of so-called powerusers. Due to an unfortunate design of the functional area field in the ERP system and the resulting reporting issues, widespread roll-out and use of ad-hoc reporting to all members of the financial community is hampered, which reduces system acceptance and lowers the project’s return on investment.
The problem described above was not intended by SAP; however it is a common issue experienced on projects because the designers don’t define their functional areas optimally and they often do not utilize delivered BI content for financial statement reporting. See the link on Financial Statement Reporting in SAP BW for more background information. Within the standard BI content there exists the characteristic InfoObject 0GLACCEXT used for financial statement items. This special characteristic is unique since it can contain G/L accounts as well as functional areas. In this way, both P&L reporting methods (cost-of-sales and period accounting) can be displayed in the SAP BW system.
In summary, a useful approach to take with the functional area design is summarized into the following task steps.
1) Define functional areas equal to the lowest level wanted to be displayed on financial statements. This is applicable to both balance sheet and P&L.
2) Assign functional areas to CO objects and where possible directly to G/L accounts and cost elements. Be careful since it may not be possible until the next fiscal year start to change an assignment after a posting is made to these objects.
3) Define substitution rule steps to derive the functional areas, if the direct assignment option is not suitable for each circumstance.
4) Define the financial statement version using only the functional area.
5) Run report RFBILA00 in ERP to validate results.
6) Activate BW business content for the following:
- 0FIGL_VC2 Cost of Sales Ledger: Balance Sheet and P&L Statement
- 0FIGL_C01 Cost of Sales Ledger: Transaction Figures
7) Setup the ETL related to the above; specifically see that the financial statement version is created as a hierarchy on InfoObject 0GLACCEXT using datasource 0GLACCEX_T011_HIER for BS/P&L item.
8) Run query 0FIGL_VC2_Q0001 Bal. Sheet and P&L (Cost-of-Sales Acc.): Actl/Actl Comparison
EPM suite integration
In the EPM applications, most P&L models need an account or line item type of dimension. Depending on your planning or reporting needs, that may best be represented by the chart of accounts as I explained in my prior blog. But if financial statement reporting is desired, the chart of accounts alone will not be sufficient and the functional area field may also be needed, if the financial configuration has been defined as common practice. Sometimes the data modeler does not want to deal with two dimensions in their planning or reporting process. They may even decide to concatenate the account with the functional area field through ETL in order to deal with a single dimension. Alternatively, if the functional area is customized differently in ERP as suggested here, the functional area field alone may satisfy financial statement reporting. I’ve detailed how to utilize this approach in SAP BW. This concept is easily extended to the EPM solutions, as the functional area field or InfoObject 0GLACCEXT could be used as a basis for the account or line item dimensionality in the EPM products.
As financial planning and reporting has transferred from the ERP system and into the Enterprise Performance Management (EPM) applications, it is important to re-examine the design and use of the core enterprise structure elements, in order to improve for an integrated solution across the entire suite.