Skip to Content
Author's profile photo Marc Ellison

Central Finance Tips and Tricks #4 – Keys to Success

Having recently completed a successful go-live of a Central Finance implementation, I found some time to reflect and share key points to help others achieve the same successful outcome.

1) Get the right resource mix

Central Finance implementations require a broad range of skill sets.  Having the right skills available is critical for ensuring the success of a project. Having full time business process and subject matter experts cannot be underestimated. These roles should provide significant input into the requirements and shape the business outcomes that Central Finance will deliver. In terms of IS teams tasked with delivering central finance, below are some key roles that we had in place.

Role Description
Project Manager This role speaks for itself
Central Finance Business Architect

Responsible as the interface between the business stakeholders

Drives the S/4 HANA Finance roadmap and value proposition

Conducts blueprint workshops and provides guidance on S/4 HANA finance functionality to accounting standards.

Central Finance Solution Architect

Conducts blueprint workshops and provides guidance on S/4 HANA and Central Finance.

Lead for the delivery of the central finance core build, SLT and changes in source systems.

Lead for functional and technical knowledge of S/4 HANA Finance and Central Finance, including limitations, initial load, replication and mapping.

Technical Solution Architect Responsible to lead sizing activity and system installations
Technical Deployment Manager

Leads the technical implementation on source systems, SLT, and manages regression testing for these.

Manages the deployments and transition through environments.

FICO Consultants Deliver the core build of the Central Finance system, having MDG knowledge and S/4 HANA Finance knowledge is beneficial.
Technical Specialists

Developers with FICO experience and skill sets covering ABAP, MDG, SLT.

Responsible to deliver enhancements for customer specific requirements.

2) Prepare for technical system readiness

Before you embark on a Central Finance journey one of the first steps is to get a working landscape. Typically, this would be a sandbox environment for on premise customers or cloud systems. A hybrid landscape is also possible where on premise can connect to cloud S/4 HANA solutions. Whatever model is chosen the key is to first evaluate the current S/4 HANA technical releases available in the roadmap viewer.

For real time replication, the DMIS add-on is required to be installed on source, central and the SLT server. For those standing up new instances of S/4 HANA as the Central System my recommendation is to install the latest version and support pack (yes, the latest, not your traditional support pack – 1). For customers with source systems that are on older ECC releases expect to implement hundreds of notes to enable Central Finance functionality.

Once the technical changes are identified they must be implemented, tested and moved through the environments. Regression testing is important to execute with notes technically changing core Finance functionality.

3) SAP Launchpad is your best friend

The maturity of S/4 HANA Finance and Central Finance as a deployment option are still relatively new. This means that you need to plan a strategy to monitor and implement SAP notes and a regular basis during a project life cycle. Get familiar with the SAP launchpad and put in place a process to monitor updated and new notes, implement and test them.

4) Understand the limitations of the Central Finance solution

There are many standard limitations with Central Finance, however some can be overcome with customer solutions. Here I outline some of the known limitations:

  • The initial load does not contain the same level of detailed information available with real time replication. An example is sales invoices from the SD module. At the time of billing raw data is captured in the source system CFIN staging tables, this data contains dimensions such as the sales order, sales conditions along with corresponding amounts. This detail is transferred to central finance and can be used for derivation, mapping etc. In contrast, the initial load simply extracts data already posted to the Finance module on the source system, and in many cases the data is aggregated at GL account level.
  • The replication of fixed asset postings is not supported. In other words, it is not possible to set up a fixed asset sub-subledger on the central system and replicate asset postings from the asset sub-ledger from a source system. All asset postings are simply posted to a GL account on Central Finance and the asset number, sub-numbers are lost.
  • Like the previous asset point, an inventory sub-ledger is not supported. Material movement transactions posted in the source system will post into a GL account on Central Finance.
  • Not all Controlling business transaction type are supported. Note 2320298 explains the supported business transactions. In real world terms, this means that some processes that run on source systems, such as COPA top down distribution will not replicate and need to be executed separately on Central Finance.
  • Settlement rules on orders or WBS elements are not replicated to Central Finance
  • Costing to Account Based COPA is not officially supported. Customer projects will have to close the gap with their own enhancements. One key area to address is the generation of COPA information for cost of goods sold postings occurring on source systems that are only set up with costing based COPA. In standard costing based setups, no COPA segment is generated.
  • Logistics, material and sales documents such as purchase orders, purchase requests, sales orders, sales invoices and material documents are not replicated to Central Finance. Only the resulting accounting or controlling documents from processes off the back of these types of documents are replicated.
  • Document splitting is not officially supported in a Central Finance scenario when the source system does not have document splitting activated. Customer specific solutions are necessary to ensure that splitting design is robust and can handle different business scenarios, especially important when dealing with multiple SAP source systems with differing business processes and configuration. Extra time for analysis, design and testing must be planned for in cases where document splitting is necessary.
  • The third party (external) interface for non-SAP systems does not support clearings. It is not possible to transfer invoices and subsequently clear them via the interface.

 5) Test replication using Production systems connected to a test central finance system

Connecting Production source systems to a Pre-Production Central Finance system is recommended in the admin guide. This is an extremely useful testing approach. I cannot think of many other examples where so much test data is generated for so little effort. This approach decreases the testing effort and gives the project team means to:

  1. reset and delete data on central finance in case changes are necessary to core configuration e.g. document splitting
  2. the ability for month end processes to be completed and comparisons made to existing reporting solutions prior to the solution being productively deployed
  3. provide some statistics on expected number of AIF errors encountered to help size and train support teams

6) Understand the tools available for fixing replication errors

For real time replication, many tools are available for handling errors. The most powerful is using AIF emergency correction mode but there are also other tools available. Knowing what to use and when is crucial for teams managing Central Finance operations. Refer to some information I put together in the blog Central Finance Tips and Tricks #3 – Understand the Utility Programs

7) Keep a running sheet or replication handbook of errors faced and how they were resolved

From conception – in the early prototype stages right through to productive solutions – keeping a record of what errors were faced and how they were resolved will save many moments of “I am sure I have had that error before?”. The sheer number of errors encountered, especially in the early stages of a project can be enormous. Recording key information will go a long way to saving time and provide vital information for sharing within project teams and for teams managing business as usual processes. Example data that should be recorded:

  • Real time or Initial load
  • Message Class
  • Message Number
  • Area (Configuration, Code, Master Data etc)
  • Error Message
  • Cause
  • Resolution
  • Any follow up actions needed such as restart of AIF messages

8) Early engagement of partners to plan sizing

The sizing of SLT and the S/4 systems are important to get right. Can SLT handle the load that will be placed on it? How big S/4 will grow and how fast? Do you need to factor in planning and consolidation processes on S/4 in addition to the Universal Journal growth? There are many factors to consider when performing a sizing exercise and this should be one of the first pieces of work undertaken.

9) Have a well-defined catalogue of key replication regression testing scripts

Following on from my point about system readiness and applying the latest notes on a regular basis, defining key business scenarios to test with central finance is imperative. These tests, or at least a sub-set should be ready to run once notes or bug fixes are applied.

10) Lock down your Universal Journal data model early

Define the data model and key fields you will use for operational processes and reporting early. Doing so will provide clarity on what activities, such as enhancements and reporting build, need to be factored into the plan. Removing fields from the Universal Journal (including COPA) can be time consuming and error prone, defining coding block extensions and COPA fields in a system with no transactional data is much more appealing.

11) Limit the scope of the initial load

It is possible to load detailed documents from a source system as far back as you like. However, this carries additional effort to:

  • Ensure mappings of historical data is available on Central Finance. Decisions will need to be made, do you want to set up and map blocked customers, cost centres, profit centres, vendors, GL accounts, cost elements etc? How much reconciliation will be done to source systems, will adjustments be posted directly on Central Finance in case of misalignments?
  • The extraction and load times could be significant. Extracting data from systems with millions of records will likely result in long run times.

My recommendation is simply – reduce the initial load documents extracting period and get into real time replication as soon as possible. Only then will you get the rich raw information into Central Finance due to the initial load limitation (see the point on limitations mentioned above).

Assigned Tags

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

      Good morning Marc,

      I completely agree with what you mentioned in section 5) - connecting a productive system.

      Unfortunately this cannot be realized in our company due to policies. Our idea is: Adding a complete month from a test system (which is a copy of the productive system) to the CFIN staging tables in order to see the full bandwidth of all postings in the CFIN interface and AIF.

      Have you any idea which function modules / classes could be used to get already posted data into the staging tables (CFIN_ACCHD,...) on source systems?


      Michael Ziegler

      IT Schaeffler Group | S/4 HANA Finance Team

      Author's profile photo Kris Stono
      Kris Stono

      Hi Michael,

      Sort answer is that you can’t use already posted data. You can use it as reference data to create new postings and then capture these into the transfer tables after activating recording (initial load/empty initial load).

      Already posted documents are not identical to replication documents so extracting posted data and trying to retrofit into the transfer tables will not give you the required results, unless you try and enrich the data after/during extraction. Reason is that already posted data will have some ‘data loss’ as the documents would have already gone through the internal accounting interface in the source system (summarisation, logistics data stripped out). You need the richer data prior to the accounting interface processing, and you will not get that with your approach.

      You could look at IDR:

      This feature is made available for Central Finance SAP S/4HANA 2021 FPS1 with SAP Note 3017968.

      Source systems as of SAP ECC 6.0 (implementation as described in SAP Note 3017968  Information published on SAP site) are supported.

      An IDR system can be a separate tenant in a system with release SAP ECC 6.0 or higher (implementation as described in SAP Note 3017968  Information published on SAP site).

      Other approaches would be ‘early recording’ in production where you start capturing new documents for a month and then extract the tables, similar to connecting a productive system but without actually connecting the prod system, so the transfer tables get populated in Prod and managed there. Once you extract the tables you can delete the content and stop recording (might need SAP help with this).

      Or…use the already posted documents and create scripts that can generate new postings in your test system.

      If you have a friendly user base/shared service centre then request the they create new documents for a mont…good luck with that!

      I will update the comments if I think of anything else.