First Steps in SAP S/4HANA Finance

2.1 Introducing the universal journal

The universal journal (ACDOCA table) significantly changes the way transactional data is stored for financial reporting. It offers huge benefits in terms of the ability to harmonize internal and external reporting requirements by having both read from the same document store where the account is the unifying element for all forms of financial reporting. You will still need to understand the different applications to the extent that you need to perform different business transactions in each application. This means that you still have to create general journal entries in General Ledger Accounting, acquire and retire assets in Asset Accounting, run allocations and settlement in Controlling, capitalize research and development costs in Investment Management, and so on, but in reporting, you read from one source, regardless of whether you want to supply data to your consolidation system, report to the tax authorities, or make internal management decisions.

Figure 2.1 illustrates the way the universal journal combines reporting dimensions from the separate applications (General Ledger Accounting, Profitability Analysis, Controlling, Asset Accounting, and Material Ledger) to provide a unified data structure for reporting that includes all relevant dimensions.

Figure 2.1: Combining reporting dimensions in the universal journal

We previously saw the key fields of the universal journal in Figure 1.3. If we now look at the details of the new line item table in Figure 2.2, we see how the existing fields for General Ledger Accounting, Asset Accounting, the Material Ledger, and Controlling are combined in the universal journal using a series of include structures, bringing data from the many different business transactions to deliver a single source of truth for financial reporting in SAP S/4HANA.

Figure 2.2: Merging the SAP ERP applications in the universal journal

The massive simplification inherent in this structure is that instead of having a separate set of revenue lines in Profitability Analysis, Profit Center Accounting, and Financial Accounting, each offering a different amount of detail about the same business transaction, you can report from a single source document in the ACDOCA table. For internal reporting, for example, you might select revenue lines for a particular product or customer (information captured as characteristics that you can choose when you generate your operating concern in Profitability Analysis) and for external reporting, you select the same revenue lines based on the profit center or company code in the document.

When we talk about a single source of truth, what we mean is that instead of looking at datasets in multiple applications, we are looking at different aggregations of the same dataset by selecting fields from the various include structures shown in Figure 2.2. As we discussed in Section 1.2.1, the idea of the column store is significant. We may have hundreds of company codes, thousands of profit centers, and tens of thousands of customers, but these can be queried much more efficiently than in the past when each application built its own data store to record information about these entities.

In this context, it is also worth understanding how the different applications used to aggregate their data in the past. Even though many of the relevant fields were included in the BSEG table, organizations would configure their Financial Accounting applications to remove the individual cost centers from a large payroll document using summarization, or to remove the individual materials from a large invoice and only keep the cost center detail in Cost Center Accounting and the material detail in Profitability Analysis. This different granularity provided its own challenges when reconciling the various applications as key information was lost in the aggregation.

Before we look at what is new, let us remind ourselves of the high-level differences between the datasets in the various applications. However, if you are new to SAP S/4HANA Finance, you can skip straight to the next section because you do not have to worry about the historical differences between the various applications. All the Financials applications aggregate by period and fiscal year, but the other reporting dimensions are different in each application, making reconciliation tricky and meaning that management meetings are often spent discussing whose version of the truth is correct rather than what to do about the business situation the figures are showing.

2.1.1 Structure of General Ledger Accounting

Depending on which version of the SAP software you are using, you can approach a move to SAP S/4 HANA with two different options for General Ledger Accounting:

• Classic General Ledger Accounting—available from SAP R/3 onwards, stores data by account, company code, and business area, as we saw when we looked at table GLT0 in Figure 1.2. If you need reporting dimensions other than company code and business area, you can activate additional applications for Profit Center Accounting and Consolidation Preparation or build your own special ledger applications for Cost of Goods Sold Reporting, Segment Reporting, and so on. The separate ledgers for Profit Center Accounting, Consolidation Preparation, and so on, are no longer required since the information is in the universal journal, but these ledgers are still updated and can continue to be used for an interim period. These special ledgers are considered part of the compatibility scope, which means that they will be supported for an interim period, but not beyond 2025.
  In addition to these ledgers, a reconciliation ledger stored the results of any allocations or settlements in Controlling that crossed company code boundaries and had to be reflected in General Ledger Accounting at period close by running transaction KALC to generate the appropriate journal entries. Moving to the universal journal makes the reconciliation ledger and transaction KALC obsolete because there is only one document in Accounting and Controlling. Here, however, the COFIT table is no longer updated and the legacy reports offered for Cost Element Reporting are no longer supported.
• SAP ERP General Ledger Accounting (formerly known as new General Ledger Accounting) available from SAP ERP onwards enabled you to extend the basic account, company code, business area approach by activating additional scenarios to support Profit Center Accounting, Cost of Goods Sold Reporting, Consolidation Preparation, Segment Reporting, and so on. Activating these scenarios extends table FAGLFLEXA to store details of the profit centers and partner profit centers, functional areas and partner functional areas, trading partners and partner trading partners, segments and partner segments, and so on. What the scenarios enable is essentially drill-down reporting for these dimensions within the general ledger. Technically, you were creating additional aggregates for each of the scenarios that you added to the general ledger. The reconciliation ledger became obsolete if you activated real-time integration with CO so that any allocation or settlement that crosses a company code boundary (or a profit center boundary, a functional area boundary, and so on) would trigger a posting in the general ledger to reflect the change. This was progress compared to classic General Ledger Accounting, but there were limits to the number of dimensions that you could safely add to aggregate table FAGLFLEXA. With the universal journal, you no longer need to activate the various reporting scenarios separately—the columns are automatically updated if you maintain the proper assignments in your master data and you can add further dimensions to the coding block and extend the operating concern for Profitability Analysis as required.

One of the common misconceptions about the universal journal is that it is the only table used for General Ledger Accounting. In truth, the old document header table (BKPF) and document line item table (BSEG) continue to exist alongside the universal journal, as shown in Figure 2.3. The BSEG table continues to be used for open item clearing and related tasks, but the entries can be summarized to remove entities such as the product sold or the cost centers, where the detailed information is only needed in the universal journal (ACDOCA). However, since the BSEG is used for clearing, you will need to retain the material for goods receipt/invoice receipt clearing.

Figure 2.3: Data model for journal entries

2.1.2 Structure of Asset Accounting

SAP S/4HANA Finance includes new Asset Accounting. The new asset accounting functions were first introduced as the business functions FIN_AA_CI_1 in EhP6 and FIN_AA_PARALLEL_VAL in EhP7. The original motivation was the need to switch the leading accounting principle as it became increasingly common for US customers to switch their leading valuation from US GAAP (generally accepted accounting principles) to IFRS (International Financial Reporting Standards). If you refer back to Figure 1.3, you will notice that the ledger is one of the key fields in the universal journal. While Asset Accounting has always supported different valuations by offering different depreciation areas for a single asset, the new approach means that the different asset valuations for IFRS and the local GAAPs are stored in separate ledgers which are independent of each other. In earlier versions of the software, the second valuation was stored as a delta (or difference) to the first valuation and was updated at period close. It is now possible to update the separate ledgers in real time whenever the depreciation area has been flagged to enable real-time postings.

Asset Accounting was always integrated with General Ledger Accounting in the sense that journal entries were created for the acquisition, retirement, and revaluation of an asset, or to account for the depreciation of the fixed asset in the general ledger. However, Asset Accounting was a sub-ledger that stored detailed information relating to asset valuation, and General Ledger Accounting stored aggregated information about the assets in the general ledger (GLT0 or FAGLFLEXA tables). The account, the profit center, and any of the items we listed for the general ledger were not included in the line item table for Asset Accounting (table ANEP), and the asset-related fields were not available in Financial Accounting or Controlling. The only reporting dimension common to General Ledger Accounting and Asset Accounting other than the period and year is the company code. Reconciliation between the applications involved finding the postings in the general ledger that applied to fixed assets (those of account type A) and comparing them against the sum of the items in the Asset Accounting application. If you created a manual journal entry to an asset account, then the two would not match because this manual posting would not exist in the asset accounting table. Now, there is no separate subledger for Asset Accounting and the asset is simply an additional dimension in the general ledger and sits alongside the company code, cost center, profit center, and so on in the posting string, which makes it substantially easier to report across applications than in the past, as we will see when we look at the trial balance in Section 2.3.1.

2.1.3 Account assignments in Controlling

Although Cost Center Accounting, Order Accounting, and Project Accounting are generally considered to be separate applications in Controlling, the basic principle of assigning costs to an account assignment (a cost center, order, WBS (work breakdown structure) element, and so on) is the same in each application.

In general, Controlling involves two types of posting for actual costs:

• The first type of posting is a primary cost posting. This simply means that the general ledger posting also includes an assignment to the cost center, order, or project responsible for the costs—for example, payroll postings, travel expenses, and asset depreciation might be assigned to a cost center, and material expenses to an order or project. Each G/L account used to record these postings is linked with a sister primary cost element in Controlling that captures such costs. There is a one-to-one relationship between the primary cost postings and the appropriate profit and loss entries in the general ledger but the posting line items in the two applications are not necessarily at the same level of granularity. This is because the general ledger items are often configured such that the cost center, order, or project is summarized (in other words, removed) in order to reduce data volumes. This is frequently the case for the material items in the invoice, which are often summarized so that the 999 line item limit for the BSEG table is not exceeded.
• The second type of posting is a secondary cost posting. This means that these costs are allocated or settled further. In our example, the payroll, travel, and depreciation costs assigned to the cost center might be allocated to orders and projects using time recording, order confirmation or an overhead surcharge, resulting in the cost center being credited and the order or project debited under a secondary cost element. The order and project costs might be settled to market segments, resulting in the order or project being credited and the market segments debited, again under a secondary cost element. There was never a one-to-one relationship between these secondary cost elements and the G/L accounts because they were aggregated to a single reconciliation account for the relevant business transaction, irrespective of whether you use transaction KALC or the real-time integration functions in SAP ERP General Ledger Accounting. As you move to SAP S/4HANA, the results of the allocations and settlements will be stored under the secondary cost elements, so be sure to adjust any consolidation systems that access account information accordingly.

The easiest way to think of the shift to SAP S/4HANA is to understand that with primary cost postings the information on the account assignment extends the journal entry to explain where and why costs were incurred, so we see that salaries were posted to a cost center and raw material costs to a production order. Secondary cost postings, by contrast, record the relationships between the senders and receivers of any allocations or settlements. These relationships can result in updates to the affected profit centers, functional areas, and so on, resulting in journal entries that record the impact of the shift on the related partner objects. In Chapter 1, we discussed the removal of the totals tables for primary costs (COSP) and secondary costs (COSS). With the introduction of the universal journal, these totals records exist only as compatibility views until SAP rewrites all programs to select from the universal journal directly. This reimplementation effort also enables the introduction of the ledger to support different accounting principles and additional currencies by adding new fields that could not easily be accommodated in the legacy tables.

However, Controlling does more than simply collect primary costs and revenues, and record secondary costs. Separate tables continue to exist for statistical key figures (COSR), activity prices (COST), variances (COSB), and commitments (COOI). In Chapter 3, we will look at how the calculation of activity prices, variances and commitments is gradually being rearchitected to accommodate the new structures.

2.1.4 Margin Analysis

Profitability Analysis (CO-PA) was generally also considered a separate application within Controlling. SAP ERP supports two types of Profitability Analysis: Margin Analysis (formerly known as account-based Profitability Analysis) and costing-based Profitability Analysis. However, for performance reasons, most organizations only used costing-based Profitability Analysis prior to SAP HANA. Margin Analysis is now the preferred choice in SAP S/4HANA.

• Margin Analysis captures the revenues, sales deductions and cost of goods sold under primary cost elements, and the result of allocations and settlement under secondary cost elements. The difference compared to Cost Center Accounting, Order Accounting, or Project Accounting is that the account assignment is not a one-dimensional cost center or order, but a multidimensional market segment or group of characteristics, such as the product sold, the customer who bought the product, the sales office, the distribution channel, and so on. The operating concern is configurable and therefore, every organization uses its own special set of CO-PA characteristics. As you move to the universal journal, a column is created for each of the characteristics in your operating concern and reporting dimensions such as the customer, product, and sales office are on an equal level with company code, profit center, and functional area.
• Costing-based Profitability Analysis, by contrast, uses the same operating concern with the same characteristics, but transforms the accounts/cost elements into value fields. Because there is a technical limitation which means that only 200 value fields are supported (in earlier releases it was 120), there are typically far fewer value fields than there are accounts and value fields exist for items without an account assignment, such as statistical freight costs or sales deductions. Because it is common practice to summarize (or remove) not just the cost center but also the material number in invoices, there is often a different granularity between the lines in General Ledger Accounting and the lines in Profitability Analysis. Costing-based Profitability Analysis continues to be supported in SAP S/4HANA Finance but because of the value fields, the data cannot be subsumed into the universal journal and table CE1 (the line-item table for costing-based Profitability Analysis) continues to exist alongside the universal journal. There is no migration service to switch from a costing-based model to an account-based model because the two models are fundamentally different approaches (accounts vs key figures).

To illustrate the new approach, Figure 2.4 shows the Product Profitability app. The dimensions on the left include fields for the market segments (Bill-To Party, Country, Customer Group, Industry, Product Sold, Product Sold Group, Sales District, Sales Order, and so on), but also dimensions from General Ledger Accounting, including Company Code, G/L Account, Ledger, and so on. This is an example of how information from the formerly separate applications is brought together in SAP S/4HANA. You will notice that this report does not show all the G/L accounts, but rather an aggregated view, displaying Billed Revenue, Recognized Revenue, and so on. These aggregations are similar to the value fields used in costing-based Profitability Analysis but are created using semantic tags. We will look at how to map your accounts to these semantic tags in Chapter 6. If you want to see which G/L accounts are behind each semantic tag, G/L Account is part of the list of Dimensions on the left and can be pulled into the rows of the report to show which G/L accounts make up the billed revenue posting.

Figure 2.4: Product Profitability app

2.1.5 Structures in the Material Ledger

The use of the Material Ledger in SAP S/4HANA is a source of some confusion. In SAP S/4HANA Finance, the use of the Material Ledger is optional, but with SAP S/4HANA, the use of the transactional Material Ledger becomes compulsory. As we saw with Margin Analysis, SAP ERP supports two approaches to the Material Ledger (the transactional Material Ledger and Actual Costing), although when most organizations talk about the Material Ledger, they generally mean that they use the second option, Actual Costing:

• The transactional Material Ledger is a subledger like Asset Accounting but structured by company code, valuation area, and material. From a Material Ledger perspective, materials have price determination 2, which simply means that inventory-related transactions are captured in different currencies and according to different valuation approaches (group valuation, legal valuation, and profit center valuation). You can continue to work with the moving average price that is calculated with each transaction update and you do not require a costing run at period close. The use of the transactional Material Ledger becomes compulsory with SAP S/4HANA on-premise edition 1511, although it has been available since SAP R/3 Release 4.0.
• Actual Costing, by contrast, is used in geographies and industries where there is a legal or business requirement to assign purchase price variances, production variances, and so on to the goods sold and goods in inventory at period close. This option requires you to execute one or more costing runs to calculate actual costs at period close. Actual Costing continues to be supported as an option in SAP S/4HANA and can be activated as an additional scope item in the cloud. The data cannot be subsumed entirely into the universal journal and the actual costing tables continue to exist alongside the universal journal. Indeed, SAP S/4HANA 1610 includes a new optimized version of Actual Costing with a simpler data structure and less closing steps.

Figure 2.5 shows the Manage Material Valuation app, where you can see that the inventory values for the bearing are available in two currencies—the company code currency (CCde Crcy) and the group currency (Group Crcy).

Figure 2.5: Manage Material Valuations app

2.1.6 Other subledgers

You will notice in Figure 2.1 that while the asset subledger and material subledger merge with the general ledger, some key subledgers remain separate. Accounts Receivable and Accounts Payable continue as separate subledgers for open item management and the clearing of payments. All you will find in the general ledger is the reconciliation account for the supplier or the customer. This is partly to do with the clearing logic in Accounts Payable and Accounts Receivable, where multiple accounting principles and multiple currencies actually get in the way if you are trying to clear an open item for a given amount. Contract Accounts Receivable and Payable also remains separate to store all details for utility billing and so on. Some industry solutions also have their own subledgers, such as SAP Bank Analyzer or SAP Insurance Analyzer for financial service organizations, or the SAP Customer Activity Repository (CAR) in Retail. These continue to integrate with the general ledger at the level of the account and some key reporting dimensions.

Of course, there are more differences between the applications than the reporting dimensions listed above. Historically, Financial Accounting worked with three currencies, while Controlling offered only two currencies. Accounting principles were also handled differently in each application (ledgers in General Ledger Accounting, charts of depreciation in Asset Accounting, versions in Controlling, currency types in the Material Ledger). Many of these differences are also being addressed in SAP S/4HANA Finance and we will discuss the relevant changes in the sections that follow.