Overview of Central Finance Architecture

Why we need central finance:

Customers with several systems in their landscape from earlier loads financial data from their system into different data warehouses. The only option to report on the company’s overall financial data is in this manner. We require long-running batch operations that are routinely scheduled to extract and transform data before loading it into the data warehouse. This poses several difficulties, including:

  • Not happening in real-time but rather once a day or week.
  • The data that a customer is looking at the data warehouse is never up to date.
  • Require high reconciliation efforts.
  • Data warehouse accepts data without checking whether it is correct or not

Both SAP and non-SAP ERP systems have a long history in many businesses. Separate customization requirements, release levels, and even different charts of accounts are all features of these systems. the ability to view all of our consolidated reports on a single system, and it should be in real time. To have consolidated reporting, we must have central financing in place.

What is central finance:

An SAP S/4HANA system that receives financial accounting transactions in real time from SAP or non-SAP ERP source systems is known as SAP S/4HANA for central finance. Only financial transactions, including those related to controlling posting and cost objects, are replicated by central finance. With the option of developing an uniform reporting structure, central finance establishes a central reporting platform for FI/CO.

Business benefits of central finance:

The benefits offered by central finance are over with various options. They are namely as:

  • Real time replication of all banks related open items into central fiancé provides global bank balances and cash positions as on date.
  • Central finance offers the ability to drill down information to the source systems and provides full traceability of postings.
  • The universal journal entry of central finance is a single dataset, across multiple applications. As a result, the time and effort required for reconciliation is reduced to zero. Data is available for instant reporting.
  • Central finance as an integration point, instead of performing a full logistic and financial migration, simplifies the integration of new entities, while offering agility and flexibility.

Central Finance Architecture:

Central Finance landscape architecture contains mainly 3 systems:

  • The first system is the SAP ERP as the source system where the main business processes run, and FI and CO documents are posted
  • The second system is the SAP SLT as the integration platform which reads and replicates the FI and CO documents.
  • The third system is the SAP Central Finance as the target system on SAP S/4HANA where the FI and CO documents are re-posted.
  • Central Finance is also able to replicate cost objects as pre-requisite for the FI and CO postings.


Source System:

Any ERP system can be defined as a source system for central finance.

Integration of SAP S/4HANA and ECC 6.0 as source systems: it is supported out of the box. However, applying some SAP notes or upgrading to the latest service pack (SP)

Integrate out-of-maintenance SAP releases (for example, 4.6, 4.7 and 5.0): Additional effort required in the form of project work as source systems with central finance system. This approach is commonly referred to as “downporting”.

Other Sap ERP: Technically, integration of other SAP ERP (SAP ByDesign and SAP Business One) is currently only possible through the interface staging table in SLT. The same applies also for any non-SAP ERP system.

On the SOURCE system, there are some other components, i.e., DB Triggers, Logging Table, read engine, Mapping and Transformation engine, write engine and Staging table, which are explained now.

DB Triggers:

Monitors for any events like insert, delete, modify, and update that takes place in the source system application table. DB triggers will be created on the source system.

Logging Table:

If the database triggers, the updated data from the application table will be stored in the logging tables as triggered data. On the source system, logging tables will be established.

Read Engine:

The task of reading the data from the logging table and sending it to the SAP SLT Replication server will fall to the read engine.

Staging Table:

The SAP central financial system is connected to multiple legacy systems using the staging area, which uses diverse data models. To make it easier to import and replicate data from legacy systems (non-SAP) to a central finance system, SAP offers prepared material for data loading from simplified staging zones. The data structure of the legacy system affects the extraction and loading of the data to the staging area.

SAP Landscape Transformation:

  • SLT loads data from relevant source tables to SAP S/4HANA.
  • If data is added, deleted, or updated SLT detects the delta in the source system.
  • In real time, the delta information is replicated from SLT to the target system.
  • Two types of replications are supported: table-based replication and application-based replication
  • Central finance uses the application-based replication.
  • The SAP LT Replication Server uses a trigger-based replication approach to pass data in real time, from the source system to the target system.
  • There are three technical options to deploy SLT for central finance integration. They are as: 1. SLT deployed on a separate instance, 2. SLT is deployed in the source system and 3. SLT is deployed in the central finance system
  • Though we have three deployment options, SAP recommends to go with SLT deployment of separated instance.

Other parts, such as the technical mapping and transformation engine and writing engine, which are now detailed, are part of the SAP landscape transformation, which may be a separate system.

Mapping and Transformation Engine:

This will be responsible for structured transformation of data as per target SAP S/4HANA DB format.

Write engine:

The task of writing the data from the SAP SLT Replication server into the SAP S/4HANA DB will fall to the Write Engine.

Central Finance System:

There are some other components on the SAP S/4HANA system, which is the Central Finance system, including the Central Finance Interface, Business Mapping, AIF, and Universal Journal, which are now described.

Central finance Interface:

A number of stages, including prepare, map, adjust, and post, are taken when the data is sent to the central financial interface. In all three interfaces, the procedures are comparable. In the final step of the central finance interfaces, SAP standard functions are used to construct cost objects or uploading FI and CO documents. Any replication-related error, such as one involving the use of SAP standard functions, is recorded in AIF and requires attention.

Business Mapping:

SAP Master Data Governance (MDG) provides domain-specific master data governance to centrally create, change, and distribute master data for your complete enterprise system landscape.

It can be deployed in the central finance system or as a master hub.

It provides consolidation standard processes for business partner (customer or vendor), material, and custom object in MDG 9.0.

Central finance uses SAP MDG foundation function to maintain and perform business mapping.

Application Interface Framework Monitor:

  • Single place for error handling of all central finance replication scenario.
  • It provides (interface name, document number, error message number, replication date, etc.
  • Central finance uses AIF to define 3 main interfaces for cost object replication, FI/CO posting replication and CO internal posting replication
  • Error message can be rephrased if a message text is not meaningful.
  • Messages can be assigned to SAP-transaction codes (for example, IMG activities), which allows users to navigate to the place where the error can be resolved.
  • Emergency correction mode available, which requires special authorization, means that posting data fields can be corrected by entering the correct value.

Internal accounting Interface: If no errors, it will post in internal accounting interface and moves posting to the ACDOCA table.

Central Finance Data Replication:

Central finance splits the process of data replication into 2 parts:

The first part is the initial load. This step loads/replicates existing data only in the source system.

The second part is the real-time replication. This step replicates all newly created data, and also changes existing data in the source system.

Initial Load:

The initial load must be executed in the right order:

First, load the cost objects. These are required for the FI/CO and CO internal posting in the central finance system.

Perform the initial load of FI/CO posting.

Make sure that all the postings are successfully replicated in the central finance system.

Start the initial load of CO internal posting. The initial load of cost object and CO internal posting, uses SLT to load and replicate data. This means the selection happens via SLT.

All data in central finance that is replicated by SLT goes through AIF. This means that AIF is the monitoring and error handling tool, for SLT-based replicated data in central finance.

The initial load of FI/CO posting uses MDF (Mass Data Framework). MDF uses RFC connection to read data from the source system.

Not all data in central finance, that has been replicated via MDG, goes through AIF. This means the monitoring and error handling tool is the application log of MDF.

Posting excluded in Initial load:

The below posting cannot be transferred as part of the initial load and ongoing replication.

  • Postings to CO-FI reconciliation ledger (GL Reconciliation Postings).
  • Clearings are not transferred as part of the initial load, but you can activate the transfer of clearings via ongoing replication. For more information see Handling of Open Items
  • Clearing resets are not transferred as part of the initial load but you can activate the transfer of clearing resets via ongoing replication. For more information see Handling of Open Items
  • Noted items (apart from down payment requests and payment requests)
  • Parked documents
  • Balance carryforward items

Real-Time Replication in Central Finance:

Following the database’s storage of FI/CO documents, the source system’s log tables are updated with database triggers.

The data can be fed into the appropriate interfaces that central finance provides via SAP SLT in real-time data collection from the posted documents in the source system.

The table COBK serves as a header table for the replication of CO secondary posting documents, and its sub-tables are also used (such as COEP).

The document header table and its related subtables (BKPF, BSEG, etc.) are insufficient for FI documents. Once a document is submitted, several other details that were required for uploading are no longer available. It is necessary to have the information, though, in order to correctly post a document into the central finance system.

The data required for document uploading is therefore kept in tables, with CFIN ACCHD serving as the header table. The central finance system receives a replication of this data via the SAP LT replication server.

The temporary data can be removed from tables using the cleanup-program RFIN CFIN CLEANUP, which needs to be scheduled on a regular basis (for example, once per month).


A central ERP system underpins the new financial methodology known as “Central Finance,” which is built on a new set of technology. Consolidated group consolidation, business planning, and transaction execution are all made possible. I discussed the Central Finance architecture and its two components of data replication in my blog article. I’m hoping it will offer some insightful data on government finance. I’ll try to go into more detail on source system configuration, central finance, business mapping, and central payments in my future blog article.