Skip to Content
Author's profile photo Sven Denecken

#S4HANA use case series: 4b – increase financial business performance (tech view)

In the previous use-case blog post #S4HANA use case series: 4a – increase financial business performance (biz view) we explained how the transition in real-time in the production is essential to address the new market needs. In the same way, the new area of big data provides larger and, in terms of content, richer data sets – but the urgency to make decisions faster every in this context, the real-time Finance has also a significant impact on the entire business process. Finance in real-time is not just another modernized finance system, but it’s a paradigm shift in looking at and running the financial processes.

Today´s blog will shed a light on what has changed with SAP S/4HANA from a technical point of view to address the need concerning their business processes and their IT landscape.

Data model simplification

Enterprise applications in the past needed to store data in aggregate table in order to meet performance expectations in view of limited database performance. Aggregate tables contain it´s by nature redundant information. This makes the entire process memory intense and predisposed for inconsistency conflicts. However, before the in-memory technology, aggregates and indexes were required to map various requirements of the documents.

In parallel, if we analyze the data model of SAP ERP Financials, several instances of data redundancy become apparent. The fundamental separation of different components (such as financial accounting, controlling, profitability …) into separate table structures is a case of duplicate data.


Figure 1

The challenges of the architecture (see figure 1) before SAP S/4HANA was the huge reconciliation efforts concerning the combined content of several tables. Data is the most important factor for finance. If the data foundation is wrong, then everything else can easily be wrong and this combined content of several tables represents “the truth”. The merge from separate components and data models into a Universal Journal as the Single source of Truth enable radically new approaches to finance, in addition to the usual benefits of a redundancy-free system.

Faced with millions or billions of accounting documents (headers, primarily stored in table BKPF) and their line items (table BSEG) and slow disk-based performance, SAP ERP Financials needed materialized views and materialized aggregates in order to provide sufficiently fast access to line items with specific properties or aggregates values. For this reason, the classical core data model of Financial Accounting (see Figure 2) contained, among others, six materialized views: three for open line items (BSID – Accounts receivable table, BSIK – Accounts payable table, BSIS – G/L accounts table) and three for cleared line items (BSAD, BSAK and BSAS) separated in the same tables. We had also three materialized aggregates for corresponding totals (KNC1, LFC1 and GLT0).


Figure 2

Parallel posting

Removing materialized views and materialized aggregates from the financial accounting data model has an immediate positive impact on the transactional throughput of the system.

In the case of SAP S/4HANA Simple Finance, posting an accounting document requires neither inserting redundant duplicates into materialized views nor updating redundant aggregate values. The corresponding effort and database operations to maintain consistency are no longer necessary.

Enterprise systems usually handle a lot of transactions in parallel. In the case of materialization, the concurrent aggregate updates in particular can lead to contention, because materialized aggregates have to be locked for updating. In the case, for example, heavily used G/L accounts, the database system has to handle the otherwise parallel postings sequentially if they access the same G/L account in order to consistently update the totals for this account. This unhappy situation con no longer occur in SAP S/4HANA Simple Finance, as all transactions simply insert multiple into the database, which does not require locks.

Single source of Truth: Universal Journal

The Universal Journal is the single source of truth and the holistic basis for next-generation accounting in SAP S/4HANA Simple Finance. Technically, the new Universal Journal is a harmonized and redundancy-free data store of actual data serving the

  • General Ledger (G/L)
  • Management Accounting/Controlling (CO)
  • Asset Accounting (AA)
  • And Material Ledger (ML) components.

The Universal Journal is one single physical table, and SAP HANA provide the necessary speed we need to aggregate hundreds of millions of line items of one table within seconds!


Figure 3

The new journal entry consists of a header (table BKPF) and the respective items (table ACDOCA). The table ACDOCA contains all fields needed for G/L, CO, AA, ML, PA and we have now 6 digit fields for line item numbering (no longer the 999’ document lines limit).


Figure 4

Concerning the usage of Material Ledger for parallel currencies and parallel valuation purpose, the contents of tables MLIT, MLPP, MLPPF, MLCR, MLCRF, MLCD, CKMI1, BSIM is now stored in ACDOCA. MLHD data is stored in BKPF.

MLHD, MLIT, MLPP, MLCR still keep prima nota information, in case of manual price changes or material debit/credit

Immediate Benefits of the new Model

The Universal Journal has all fields (columns) required by the business processes and the individual components. Whereas the technical handling of a table with so many fields would have created significant difficulties in the past, now we can dare to do thanks to SAP HANA’s superior compression technologies and columnar layout. In addition, we have the following innovations:

  • Significant coding changes (aka. Unified Journal)
  • Merge the transactional tables for the General Ledger, Asset Accounting, Management Accounting, CO-PA and Material Ledger into one
  • Merge the account and cost element

Between FI and CO, in our new architecture we merge CO and FI so that real-time integration is guaranteed by design. Users can natively drill down to the same line items from the key figures and reports of both components.

Stay tuned for the next use cases and follow me via @SDenecken for latest news.


Overview of SAP S/4HANA use cases: #S4HANA – the use case series – Intro & Overview


Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Clemens Kopfer
      Clemens Kopfer

      You mention 2 Tables as being part of universal journal:

      ACDOCA and BKPF.

      What about BSEG and COEP?
      I believe they stay, whereas some other older tables, eg GLT0, are definitely gone (replaced with CDS-View).

      Can you elaborate on that?

      Author's profile photo Former Member
      Former Member

      BKPF and ACDOCA are the primary tables (Header and Line Item) , BSEG and COEP are relevant and continue to exist but significants has been redcued.  S/4 HANA Finance - we encourage the customers to use Account based COPA .

      Author's profile photo Partha Vemuru
      Partha Vemuru

      Dear Sven,


      What is the impact of BUZIE field limitation (999) from BSEG table, when we have more than 1000 accounting document lines. I agree that ACDOCA handles this scenario, but interested to know how BSEG reacts.


      thank you,