Introducing the universal journal: excerpt from First Steps in S/4HANA Finance

The universal journal (table ACDOCA) 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. 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

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, you can report from a single source document in table ACDOCA. 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. Here, 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 for 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 available in table BSEG, 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.

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, there are actually two General Ledger Accounting options available:
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 needed reporting dimensions other than company code and business area, you could 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. 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.

SAP ERP General Ledger Accounting (formerly known as new General Ledger Accounting) available from SAP ERP onwards allowed 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 as required.

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 between accounting principles as it became increasingly common for US customers to switch their leading valuation from US GAAP to IFRS. If you refer back to Figure 2.1, you will  notice that the ledger is one of the key fields in the universal journal. This means that the asset valuations for IFRS and for local GAAP are stored in separate ledgers which are independent of each other, whereas in early versions of the software, the second valuation was stored as a delta or difference to the first valuation.

While 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, this did not mean that the account, the profit center, or any of the items we listed for the general ledger were included in the line item table for Asset Accounting (table ANEP) or conversely that the asset was 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, 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.

Keep reading in  First Steps in SAP S/4HANA Finance by Claus Wild and Janet Salmon.

 With their latest product SAP S/4HANA, SAP is revolutionizing how we approach finance by re-architecting data persistency and merging accounts and cost elements. This book offers a fundamental introduction to SAP S/4 Finance.

Dive into the three pillars of innovation in including SAP Accounting powered by SAP HANA, SAP Cash Management, and SAP Integrated Planning. Find out about the new configuration options, updated data model, and what this means for reporting in the future. Get a first-hand look at the new user interfaces in SAP Fiori. Review new Universal Journal, Asset Accounting, Material Ledger, and Account-Based Profitability Analysis functionality. Examine the steps required to migrate to SAP S/4 Finance and walk through the deployment options. By using practical examples, tips, and screenshots, the help readers to:

– Understand the basics of SAP S/4 Finance
– Explore the new architecture, configuration options, and SAP Fiori
– Examine SAP S/4 Finance migration steps
– Assess the impact on business processes

Claus Wild is a widely recognized electronic payments and cash management expert. Claus has built extensive experience working for an international manufacturing company and as a trainer at SAP. He will join Stellwerk Consulting GmbH in Cologne, Germany, as a Senior Consultant in 2017.

Janet Salmon is the Chief Product Owner for Management Accounting at SAP SE. Janet is known to many SAP Financials professionals for her writings on Controlling and related subjects in SAP Financials Expert. Janet has overseen many SAP Controlling functionality product developments both as a Product and Solution Manager. Most recently she spearheaded changes to the user interfaces within Controlling and data transfer from Controlling to SAP HANA.