In SAP S/4HANA, the Universal Journal provides the basis for what is essentially an enterprise-wide pivot table. Let’s take a high-level look at why it’s needed and how it relates to the structures you know from SAP ERP.
When conceiving its next-generation enterprise application, it was clear that SAP needed to change the classic data model structure as it exists in SAP ERP. The new central financial steering model is the architectural cornerstone of SAP S/4HANA, used to ensure that this ERP system delivers a financial single source of truth for an organization. This steering model or single source of truth is what we call the Universal Journal.
How does the Universal Journal manage to be the single source of truth for an organization? It captures line-item details in a first layer, which we refer to as table ACDOCA. The Universal Journal is structured along the typical business dimensions, like company code, profit center and other organizational dimensions, customer, product, and so on. This is the place to retrieve all the details of a transaction with the highest granularity of data available. The table below lists some of the reporting dimensions across different categories included in the Universal Journal.
The Universal Journal is the common line-item persistence option within SAP S/4HANA for all finance data. It combines transactional line items from different functional subdomains:
This means that the classic split between the legal accounting and management accounting worlds no longer applies, and all financial information is stored centrally in a single table.
This does not mean that all different “fields” or dimensions are always filled in the Universal Journal. Dimensions such as the general ledger account, the company code, the ledger, the document number, the record type, the period, and the fiscal year will be filled in for every posting, but—as illustrated below—different fields are filled in depending on the type of financial journal entry. In the case of an asset-relevant posting, the asset number will be filled in, but there will be no customer unless the journal entry represents the sale of an asset. In the case of a payroll posting, there will be neither asset nor customer, but only a cost center.
Technically, this is known as a sparsely filled matrix. Some columns are always filled in, but many, including the asset, customer, and material fields, will be filled in only for certain transaction types. In classic databases, this made data selection difficult, but in a columnar database like SAP HANA, the system selects data by column rather than by row. So when a user searches for a customer, for example, any lines that do not contain a customer are simply ignored.
We can use an example of asset acquisition to imagine how the posting string shown below is filled. The asset acquisition will obviously result in the update of the asset field and of the associated general ledger account. These updates fill in what used to be the asset subledger and the general ledger. The asset also is assigned to a cost center; this will be updated, too, filling in what used to be the controlling table but is now simply an additional reporting dimension in the Universal Journal.
The cost center is also assigned to a profit center and a functional area. Again, this used to result in an update to a separate profit center ledger and COGS ledger, but both are now simply further reporting dimensions in the Universal Journal. The result is a single document for the asset acquisition that combines data previously spread across multiple applications.
The posting logic hasn’t changed, so you won’t need to adjust your business processes, change field status groups, or modify the way you derive your profit centers when you move to SAP S/4HANA. However, you do need to understand that data relating to a single business transaction is no longer chopped up and stored in different application tables but instead stored as a single, richer journal entry.
The figure below focuses on the multidimensionality of the journal entry, but it’s also important to understand what the different boxes mean. They represent the various measures and reports that can be built using the data collected in the Universal Journal to satisfy the needs of the different stakeholders. You can see that the financial statements are an aggregation of all the posting lines for one or more company codes:
In this context, we also have to think about how the accounting data is segregated.
The ledger is a key element in the Universal Journal; it’s used to separate documents that support different accounting principles. This allows you to represent each measure (revenue, operating expense, capital expense, etc.) in accordance with different accounting principles. This allows corporate accountants to see all values according to a common accounting principle, such as IFRS, and local accountants to see the values for their entities according to Russian GAAP, Brazilian GAAP, and so on.
Currency is also a key element; any posting line may include several currencies. Any document in the Universal Journal will be available in a local currency (currency type 10) and a global currency (currency type 30). Other currency types can be added per ledger as required
Note that different stakeholders focus on different currencies—so a plant controller or a local accountant uses reports that mainly show the values in the local currency, whereas a corporate accountant looks at the same business transactions in the global currency. What’s important is that the currency conversion from transaction currency to local and group currency takes place in real time, rather than after the fact when the documents are loaded into a data warehouse.
If you read the technical SAP Notes and blogs about SAP S/4HANA, you will learn that the Universal Journal combines information from the general ledger (table GLT0 or FAGLFLEX), any special ledgers, controlling (table COEP), asset accounting (table ANEP), and the material ledger (table MLIT). In other words, all the tables related to actual data are being moved into a single journal entry.
But that’s not the full story: table ACDOCP is designed to extend the Universal Journal to store plan data. It is structurally designed in the same way as table ACDOCA, but with the purpose of incorporating all plan data so that you can run actual-plan comparisons. What’s important is that if you add fields to the Universal Journal, they are included in the planning table automatically if they are part of the relevant include structure. This makes it very easy to build reports that compare plan and actual data.
A third table, table ACDOCU, holds all consolidation relevant information—again, coming structurally with the same data model. The consolidation table is essentially an aggregation of the entries in the Universal Journal: it will include the legal entities that act as trading partners and the various management dimensions used for matrix consolidation, but it won’t include every order and network from the operational processes like the Universal Journal. These details are simply aggregated and do not appear in the consolidation table.
One myth we’ve encountered is that table BSEG disappears with SAP S/4HANA because all financial journal entry items posted in an SAP S/4HANA environment are recorded in table ACDOCA as the single source of financial data.
The figure below shows the structure of the accounting entries in SAP S/4HANA. The familiar tables BKPF (journal entry header) and BSEG (journal entry line item) from the SAP ERP world continue to exist in the context of SAP S/4HANA. Table BSEG is still relevant for specific operational finance processes, including open item management.
So how does this relate to table ACDOCA? There is still the classical link between the header and line item tables, as expected, but in the end, table ACDOCA contains all the details of the financial document and stores all fields relevant for accounting processes and reporting.
The final figure below illustrates the interdependencies between tables BSEG and ACDOCA. The BSEG line items have been highly summarized so that we are left with a receivables line, a tax line, and a revenue line (three separate accounts). In table ACDOCA, we see many more line items for the same business transaction. We summarized the revenue line in table BSEG to remove the customer and product in the invoice and the derived profit center, but we can see the separate customers, products, and profit centers in table ACDOCA. The tax and receivable lines were captured by company code, but we’ve used document splitting to break out the tax and receivable lines to represent the three separate profit centers in the revenue line.
When you think about sizing your accounting system, it’s important to look at whether your table BSEG has been highly summarized and how the number of table ACDOCA lines will grow if you did not previously use document splitting. One of the major headaches of table BSEG was that the number of posting lines per document could not exceed three digits. Because table BSEG now generally will be summarized, this should cease to be a problem. The maximum number of posting lines in table ACDOCA is 999,999.
The Universal Journal is a key point of SAP S/4HANA Finance, and those utilizing or plan to utilize the solution should take care to learn all about its capabilities. But this is just one key innovation that SAP S/4HANA Finance brings to the table. Learn more about predictive accounting and group reporting in SAP S/4HANA, and then read the final part of this series on efficient hard financial close.
Don’t miss out on the final part of this series when it publishes in a couple of weeks by subscribing to our weekly recap email here.
Editor’s note: This post has been adapted from a section of the book SAP S/4HANA Finance: The Reference Guide to What’s New by Janet Salmon and Michel Haesendonckx.