The following tips will help you to prepare well in advance for a Central Finance implementation in terms of system requirements, resource planning, delta configuration, and the knowledge about key processes that are supported by SAP and the ones that are not supported as of S/4HANA Finance 1605. Central Finance is a deployment option and not a functionality within SAP S/4HANA. SAP introduced it to simplify the process of adopting SAP S/4HANA Finance.

The Central Finance Option

SAP S/4HANA Finance is an exchange innovation in the sense that installation of the SAP S/4HANA Finance Add-On replaces the classic SAP Financial Accounting and Controlling (FI-CO) modules with re-engineered SAP Accounting Powered by HANA, leaving all other modules as is. To install the SAP S/4HANA Finance Add-On, the SAP system needs to be on SAP ERP Central Component (ECC) 6.0, with enhancement package 7 or above. The database must be an SAP HANA database. For organizations that have a heterogeneous landscape (more than one SAP ERP instance or non-SAP instances) that want to adopt SAP S/4HANA Finance, it is a mammoth task to:

• Migrate all the instances to the SAP HANA database
• Upgrade all the instances to SAP ERP Central Component (ECC) 6.0 and enhancement package 7
• Install the SAP S/4HANA Finance Add-On on all the instances

This increases the complexity, effort, and the cost for adoption of SAP S/4HANA Finance. To keep it non-disruptive for such customers, SAP came up with an innovation deployment option called Central Finance. Instead of upgrading all the instances, you can add a new instance having the SAP S/4HANA Finance Add-On installed on it. You then can connect all the existing instances to the new SAP S/4HANA Finance system. And guess what? The existing instances remain untouched, which means the process is non-disruptive to the business. You only have to apply a few SAP Notes in the source system. All the finance transactions posted in the source systems are automatically transferred to the new SAP S/4HANA Finance system. That becomes the system of record for Financials that can then be used for central process execution. For example, the period-end close can be performed on the new central instance, instead of performing it in multiple instances.

Implementation Aspects to Be Considered While Doing a Central Finance Project

In this article we intend to enlighten you about the various aspects of doing a Central Finance implementation, including systems, data, and the process.

Systems

Let’s understand which systems are involved, their relevance for Central Finance, and how they can be deployed. Table 1 summarizes the systems required.

Systems	Mandatory	Optional	Deployment
System Landscape Transformation (SLT) Replication Server	X		On-premise or on cloud
Master Data Governance (MDG)		X	On-premise or on cloud
SAP S/4HANA Finance	X		On-premise or on cloud

The SLT Replication Server is mandatory for a Central Finance implementation as it connects the source system (existing SAP/non-SAP systems) with the target SAP S/4HANA Finance system. For each finance posting made in the source system, a database trigger is initiated in real time. SLT then reads the data from log tables and initiates the postings into the target Central Finance system. The use of SLT here is different than what you may have used it for in euro conversion projects. The business mapping takes place on the Central Finance interface. The posting into the Central Finance system is not a replication but a fresh posting in itself, unlike in the case of an SAP Business Warehouse (SAP BW) system in which the postings are just replicated. This means you can have your own validations and substitutions in place in the Central Finance system before the documents are reposted. SLT works on the database level, which means that no changes are to be made in the application layer of the source systems. This comes in handy when you want to connect a non-SAP system to the Central Finance system, thereby facilitating a non-disruptive transformation. MDG is optional and is needed only when data harmonization is one of the objectives of a Central Finance implementation. For example, if multiple company codes are using different charts of accounts, you can use MDG to transform the General Ledger (G/L) accounts before the posting is made into the Central Finance system. This facilitates harmonized reporting from the Central Finance system. The data harmonization through MDG is not just restricted to the chart of accounts, but can extend to customer masters, vendor masters, material masters, cost centers, and profit centers. The SAP S/4HANA Finance system (Central Finance system) is the system on which the SAP S/4HANA Finance Add-on is deployed. It acts as the target system for financials where all the documents from the source system are reposted. As such, it is mandatory. All the above systems can be deployed either on premise or in the cloud.

Data

In this section of the article, we cover how master data is replicated to the Central Finance system and how master data harmonization is achieved. In this context, it is important to differentiate between:

• Long-term data such as G/L master, vendor master, customer master, material master, cost center, and profit center that does not change in the short term. In case it ever changes, the mapping needs to be adjusted, either in the MDG or in the custom tables, as the case may be.
• Short-term data that is short lived such as internal orders, production orders, QM orders, and maintenance orders.

Long-Term Master Data

For replicating long-term master data such as G/L accounts, vendors, customers, and material masters, you can use SAP BusinessObjects Data Services (BO-DS). This can read the data from the source system tables and replicate it into the target Central Finance system. You can also create the masters in the target system manually or by using Legacy System Migration Workbench (LSMW). Data harmonization of the long-term master data can be done either by using MDG or by maintaining custom tables for mapping and using relevant Business Add-Ins (BAdIs) while reposting the financial documents in Central Finance. For example, during go-live all the existing master data such as G/L master, material master, customer master, and vendor master would be updated in mapping tables. After go-live if any new master is created, then that needs to be updated in the mapping tables. For MDG mapping, type CFINIMG in the command box and then follow menu path CFINIMG > Central Finance > Mapping > Define Value Mapping. Figure 1, for example, shows the mapping between G/L accounts to be maintained in the MDG system.

Short-Term Master Data

As mentioned above, the mapping in MDG is perfectly suited for long-term master data. However, for short-term master data, it is not feasible to maintain the mapping in the tables on a regular basis. For example, when several production orders are created on a daily basis in the source system, it is not possible to maintain the mapping in the MDG several times a day, as that would be disruptive to the business. Therefore, SAP has given a solution for such short-lived cost objects called the Cost Object Mapping framework. The following is the SPRO node for Cost Object Mapping framework. The IMG path is CFINIMG > Central Finance > Mapping > Cost Object Mapping > Define Cost Object Mapping. Following this path takes you to the screen shown in Figure 2. You can replicate such short-lived master data on a 1:1 basis as well as on an N:1 basis. That means multiple internal orders in the source system can be mapped to one internal order in the target Central Finance system, say, based on business area or profit center. For example, you can choose to have one internal order per business area/profit center in the target Central Finance system instead of replicating them on a 1:1 basis. While the Cost Object Mapping framework is a very big concept in itself, for the purpose of this article, two key aspects are worth mentioning: For production orders only N:1 mapping is supported. Multiple production orders from the source system are mapped to one product cost collector in the target system. In this regard, if the organization chooses to perform the period-end close in the Central Finance system, the work in process (WIP) and variances will be calculated as per the repetitive manufacturing process (i.e., WIP valuation will happen at the target cost and the variance calculation won’t be dependent on the production order status). At the time of the writing this article, SAP does not support work breakdown structure (WBS) replication until version 1511 FPS 02 and hence it is also not available in the Cost Object Mapping framework. Refer to SAP Note 2184567- Central Finance - FAQs. However, if it is needed, you can address it by way of a custom development, using the following two BAdIs: BADI_FINS_CFIN_AC_INTERFACE and BADI_FINS_CFIN_CO_INTERFACE. This means any posting made in the WBS elements in the source systems can be routed to a WBS element or an internal order in the target system using these BAdIs.

Process

In this section, we explain the process of transferring financial data and transactions from the source systems to the target Central Finance system. This can be divided into the following steps:

1. The initial load (of historical financial data)
2. How the financial documents are reposted from source systems to the Central Finance system
3. Post-processing options in case of errors during reposting
4. The audit trail of the document posted in the target to the document in the source

We also explain what transactions are reposted from the source system to the target system and the limitations that exist at the time of the writing of this article.

Initial Load in Central Finance

In a net new (greenfield) implementation, the first step for cut-over is to load legacy data in the SAP system. Similarly, in a Central Finance implementation, you follow an approach called initial load. Here, you need to specify, for example, that the line item details for the last two or three years are to be carried over, and only the balances prior to that. In the initial load, the historical data is transferred to the Central Finance system and only after that can the regular financial transactions from the source systems be reposted to the Central Finance system. For this purpose, you have to mark the initial load as complete. Only after that are the regular ongoing transactions reposted. For an initial load of financial data, you maintain table VCFIN_SOURCE_SET in transaction code SM30 in the source system. You specify the particular company code and from which year the line items are to be transferred (Figure 3). For any period prior to that, only the balances are transferred. The detail in Figure 3 means that for company code 1001, the line items are to be transferred starting 2016/Period 1 (refer to the third and fourth columns in Figure 3). This naturally implies that balances are to be transferred for periods prior to 2016. You can also mention the year from which you would like to carry forward the balances. It can be the year 0001 (since inception) or a specific year, say, FY 2012 in this example. From period 1 of FY 2016, line items are to be transferred. The following must occur before the historical balances and line items can be transferred to the target Central Finance system:

• The replication of master data such as cost centers, G/L accounts, and profit centers must be complete. Short-lived master data such as internal orders and product cost collectors are created based on the settings maintained in the cost object mapping framework.
• You may need to maintain default account assignments in transaction OKB9 for the cost elements.
• You have to maintain a migration clearing account at the company code level that will be used to balance the document while the historical balances/line items are replicated. The balance in this account is always zero.
• Every reconciliation account and input/output tax account must be assigned to a substitution G/L account. Postings are first made to the substitution account and then transferred to the relevant G/L account by off-setting the substitution account. The balance in this account is always zero.

After the initial load is done, select the Initial Load… check box in Figure 3, which indicates that the initial load is complete. The online replication in the system can start only when this check box is selected.

How the Financial Transactions Are Reposted in Central Finance

In this section, we explain how the financial postings are replicated from the source system to the target system. Figure 4 is a diagram of this process. The series of steps in which a document is reposted in a Central Finance system follows:

1. The document is posted in the source system (SAP/non-SAP system)
2. A database trigger updates the log table in the source system.
3. SLT reads the log tables. SLT works at database table levels and uses a replication object for each table to be transferred. For transfer of FI documents, triggers for table CFIN_ACCHD are read. For CO documents triggers for table COBK are read. For transfer of orders, triggers for table AUFK are read. All these links are delivered as standard SLT content and you do not need to set up these links by hand.
4. Before reposting to Central Finance, SLT checks if any MDG mapping exists. If yes, it replaces the data as per mapping rules.
5. Before reposting to Central Finance, SLT also checks if any data in the source document is to be replaced by the Cost Object Mapping framework configuration and replaces the cost object accordingly.
6. SLT then feeds the data to the Central Finance accounting interface.
7. Any validations and substitutions written in the Central Finance system are also performed before the reposting.
8. The accounting document is reposted and the Universal Journal is updated.
9. If there is any error, the document can be seen in the Application Interface Framework (AIF) and can be post-processed by the user after making necessary rectifications. (AIF is discussed later in the article.)

Post-Processing Options in Case of Errors During Reposting

In this section we explain how the errors during the document reposting to Central Finance are to be managed.

First, all the financial documents that are posted in the source system must be posted in the target system. If the documents fail for any reason, say, mapping does not exist or a G/L account is blocked, then all such postings can be found in the AIF.

Once the root cause of the failure is rectified, the postings can be processed from within the AIF. You can also change the G/L accounts and cost centers involved in the posting before the postings are processed again from the AIF.

Before the introduction of the AIF, Error Correction and Suspense Accounting (ECS) was in use. However, the AIF has a lot of advantages over ECS in terms of post-processing capabilities. For example, the errors of on-line replication related to FI postings and CO secondary postings can be handled through the AIF. In ECS, errors related to a CO secondary posting can’t be handled.

AIF has the capability to distribute messages to different users for analysis. Execute transaction code /n/AIF/ERR. In the screen the system displays (not shown), enter AIF in the Application field, and click the execute icon or press the F8 key to display the screen in Figure 5. In Figure 5, you can see that the error message highlights the missing mapping for Cost Object.

What Transactions Can Be Reposted

It is important to note that Central Finance is a system for centralized financial reporting and hence only FI and CO documents are reposted in Central Finance. Therefore, the logistics documents, including parent documents (such as purchase orders or sales orders), are not eligible for replication. The material documents, such as goods receipts, incoming invoices, and customer billings, are also not replicated. Rather, the accounting documents generated therein are reposted as finance documents. Subject to the limitations in Table 2, all the financial documents/information is reposted from the source system to the target system.

Serial number	Finance process	Remarks
1	G/L, AP, or AR open items	These are reposted to Central Finance Line items are technically cleared upon reposting Functionality released for SAP S/4HANA Finance 1605/SAP S/4HANA 1511 FPS02, after SAP Notes 2147776 and 2292043 are applied
2	Noted items (A noted item is a single item entry with no financial impact.)	Not supported
3	WBS postings	WBS elements are not supported by the Central Finance scenario (Refer to SAP Note 2184567)
4	Settlement rules	Settlement rules are not replicated Need to be addressed through a custom development
5	IO settlement to CO-PA/Cost Center Assessment to CO-PA/top down distribution/indirect activity allocation to CO-PA	Settlement documents in these cases are not replicated (Refer to SAP Note 2320298) From costing-based CO-PA (CBCOPA) in the source system to account-based CO-PA (ABCOPA) in Central Finance From ABCOPA in source to CBCOPA in Central Finance From CBCOPA and ABCOPA in source to ABCOPA in Central Finance
6	Asset Accounting	Asset postings from the source system are posted into a normal G/L account and not into a reconciliation account. Hence, fixed asset masters are not created in the Central Finance system.
7	Document change- FB02	Document changes are not replicated. Limited functionality released for SAP S/4HANA Finance 1605/SAP S/4HANA 1511 FPS02, with SAP Note 214777
8	Sales orders as cost objects	Sales orders as cost objects are not replicated. Need to be addressed through a custom development
9	Special purpose ledger/EC-PCA/costing-based CO-PA postings	Not supported

Audit Trail - Drill Back

The finance department of any organization would be concerned with the traceability and auditability of the reposted document in the target system. Central Finance offers a complete solution with regard to this. Any financial document reposted in the target system can be linked back to the document in the source system. Central Finance can drill back not only to an SAP ERP but also to a non-SAP ERP system, with some modifications depending on the application used. New fields such as Sender Logical System, Sender Company Code, Sender Document No., and Sender Fiscal Year can be seen in the document header. This helps you to know the source system from which the posting has come into Central Finance. Execute transaction code FB03. In the screen the system displays, enter a document number and display the document header. The new fields shown in Figure 6 can then be seen in the header. You can also use the document relationship browser to see the Central Finance financial document linkage to the source document from the sender system (sales order, purchase order, or the financial document of the source system). Execute transaction code FB03 and display the document (the screen is not shown). After you click Environment, Document Environment, and then Relationship Browser, the system displays the screen in Figure 7. In Figure 7, you can see the accounting document 100000817 in Central Finance system and its linkage to the accounting document 4400000727 from the source system.

Table ACDOCA stores the G/L account and real cost object information of the source system. Execute transaction code SE11. In the screen the system displays (not shown), enter ACDOCA in the Transparent Table field and then click the display icon. This action displays the screen shown in Figure 8.

In addition to this, more fields can be added in the same include of table ACDOCA to capture additional information from the source system, such as short text or assignment.

It is also possible to search for a document in the Central Finance system by giving a document number of the source system.

Key Insights and Recommendations with Regard to Central Finance

The following points are worth noting in a Central Finance environment:

1. Tax reporting – Recommended to be done from the source system, as you create tax codes with zero percent in the Central Finance system. The postings in the tax G/L accounts are only reposted as a normal G/L posting.
2. Document splitting – Can be switched on in the target system without any need of a New G/L migration. This setting applies to all data.
3. Initial load - Initial load needs to be triggered even if there are no balances to migrate. For example, during a Proof of Concept (POC), SAP recommends that you execute an empty load. This is needed so that online replication can be activated in the source system.
4. In a POC, the initial load must not be used to demonstrate how the real-time transaction postings would be reposted to the Central Finance system, as they follow a different process.
5. Cost of goods sold (COGS) split during the initial load – SAP does not support a COGS split during an initial load. The cost component split for COGS is only supported during an on-line transfer.

Future Roadmap of Central Finance

According to SAP’s roadmap published on the Service Marketplace, SAP plans the following innovations in Central Finance for future releases:

1. Replication of WBS elements from a source system to the target Central Finance system
2. Central payment and reconciliation functions
3. Replication from costing-based CO-PA
4. Central Material Ledger