Central Payments in SAP S/4HANA Central Finance

Overview

The Central Payment capability of Central Finance allows you to execute most of your financial operations in the newly created S/4HANA landscape while keeping your source system active. The invoice is posted in ECC or R/3 system, and payment could be done in S/4HANA.

Also Read: What is SAP S/4HANA Financial Accounting Certification?

Introduction

Central Finance provides businesses with the ability to drive transformation beyond just a centralized reporting system. Central Finance has evolved from financial harmonization and consolidation to add additional tangible benefits for businesses including central payments, centralized receivable management, and much more.

Central payment in Central Finance 1909 allows businesses to make payments centrally and perform centralized clearing in the S/4HANA CFIN system instead of at the source systems. Central payment was a challenge in previous versions because the open items, when replicated to CFIN system, were open in both the systems, which created the potential for inconsistencies. With 1809 and 1909 the source system open item, when replicated, gets cleared and the payment is executed out of the CFIN system. The central payment functionality can be activated by company code, and the invoices posted for those active company codes are cleared technically and replicated to the CFIN system. Once in CFIN, these replicated invoices are then processed and paid based on the defined payment terms.

Key Features

Activate central payment by company code.
For company codes that are activated for central payment, the invoices posted in the source systems are technically cleared. The invoices are replicated to the Central Finance system and are paid there (FINS_CFIN_CPCTL maintained for company code).
For company codes that are not activated for central payment, the invoices posted in source systems stay open and are paid in the source systems. The invoices and payment or clearing documents are replicated to the Central Finance system for reporting purpose. The replicated invoices are ruled out from the payment or clearing transactions in the Central Finance system. This avoids duplicate payments (as payments are to be processed in the source systems).
Mandate replication between source systems and the Central Finance system is automated so that SEPA direct debit is supported in the Central Finance system.

Business Values

Real status of open item (including payments and bank statements) tracked in Central Finance system.
Bank account management maintained in CF system (optional SAP MDG), when using new SAP Cash Management.
HANA optimization of payment proposal generation.
All open item related processes must be executed in Central Finance instance as well (example: dunning, collections, disputes, cash application).
Reducing the number of external bank accounts / fees.
Limit credit charges in case of overdraft.
Bundle external payments and save charges on cross border payments.
Centralize payment knowledge and optimize process in shared service center.
Use SAP Standard interface for uploading bank statements to a central platform.
Monitoring of bank communications and transactions.

Invoices posted in source system can only be paid/cleared in the original source system. Invoices replicated to central finance system cannot be paid/cleared in the target. Invoices posted directly in the central finance system can be paid/cleared in central finance system. Invoices posted in source system are marked as “technically cleared” hence no further payment/clearing is needed. Invoices are replicated to central system and can be paid/cleared accordingly. The real-time replication of source configuration to dedicated tables in CFIN allow on-the-fly check of replicated transactions. Mapping is evaluated before corresponding data is checked.

Note that: Paying centrally also might require in some cases VAT and withholding tax reports to be executed in the Central Finance system. In addition, the Tax configuration check is mandatory and hence activated together when activating central payment.

Accounts Payable & Account Receivables

Only the AP/AR open items replicated via real-time replication are technically cleared in the source systems.

Accounts Payable:

The open invoice transferred from the source systems to the CFIN system via the SLT (Real-Time Replication).
The open invoice in the source system is marked as ‘Technically Cleared’. But the invoice remains open in the CFIN system.
When the payment is made, the open invoice in CFIN system is cleared.
The bank statement clears the payment document and the transaction is closed.
However, an important point to note here is that the payment and the clearing documents are not replicated back into the source system. The life-cycle of the invoice in source system is completed at the ‘Technically Cleared’ status.

Accounts Receivables:

The process flow for Accounts Receivables follows a similar track as mentioned in the above section with the only addition is that all components of AR are integrated with the Central Credit Management box.

The customer invoice in the source system is technically cleared (end of lifecycle) and the payment document clears the open invoice in the CFIN system, and the payment/clearing document is not replicated back to the source system.

Down Payments

Down Payment Integration with SD (Request Based)

Post down payments with reference to a Down Payment Request (DPR) replicated from a source system:

A Down Payment Request is created in SD in the source system and paid in the Central Finance system. Number of the DP document in CFIN will be retrieved and filled into the Invoice Reference field of accounting document in source via RFC call. The Down Payment document can be navigated from the source system by double click (drill-down).

Procedure:

Sales order with billing plan item category (‘TAO’) is created.
DPR is posted is the source system and DPR document is replicated to Central Finance. In this process, DPR is marked as technically cleared (ALE-extern) in the source system.
Down payment could be posted in Central Finance system to clear the DPR replicated from the source system.
Transactions available to post down payment in Central Finance system:
- Bank Statements (including Manual / Electronic Bank Statement and Reprocess) (FF67/FEB_BSPROC)
- Post Customer Down Payments (F-29)
- Payment Run (F110)
- Post Document (FB01 & F-32)
In final billing, the receivable item is created in the source system, and then replicated to Central Finance system for the following incoming payment.
In this process, the receivable item is marked as technically cleared in the source system.

Key technical approaches:

Retrieved DP No.: only the number of the down payment document will be retrieved and filled into the Invoice Reference field of accounting document via RFC call.
Replicate DP: DPR document is replicated to Central Finance system using SLT technology.
Replicate receivable item: Receivable item is replicated to Central Finance system via SLT technology.

Down Payment Integration with SD (Condition Based)

Post down payments with reference to a sales order from a source system (condition-based): Sales Order is created in SD in the source system using conditions for down payment. DP is received in the Central Finance system referring to the SO of the source system. The DP must be posted with reference to the SO in the source system. This is achieved via “Remote search help”:

Procedure:

Sales Order with Standard item category (‘TAN’) is created in source system
The down payments are posted in Central Finance system with reference to the sales order retrieved from the source system.
Transactions available to post down payment in Central Finance:
- Cash Receipts in Cash Journal (FBCJ)
- Post Customer Down Payment (F-29)
- Post Incoming Payment (F-28)
- Post Document (FB01)
In final billing, the receivable item is created in the source system, and then replicated to Central Finance system for the following incoming payment.
In this process, the receivable item is marked as technically cleared in the source system.

Key technical approaches:

Retrieved SO No.: SO is retrieved from the source system via remote search help;
Retrieved DP No.: the number of the down payment document will be retrieved and filled into the Invoice Reference field of the accounting document via RFC call;
Replication: FI document is replicated to Central Finance system via SLT technology.

Down Payment Integration with MM (Request Based)

Post down payments with reference to a down payment request replicated from a source system (request-based): Down payment request is created in MM in the source system and paid in the Central Finance system. Down payment clearing as well as the final payment are also done in the Central Finance system. The purchase order history is updated by different transactions from both the source system and the Central Finance system.

Reversal of Documents

Source System vs Central Finance System

After Central Payment has been activated, all documents that were posted in the source system before activation of Central Payment still need to be reversed in the source system. The reversal is then replicated to the Central Finance system. If an item posted in the source has been cleared/paid in Central Finance in the meantime, the user needs to manually reset the clearing in the Central Finance system before executing the reversal in the source system. All documents that are posted in the Central Finance system after activation of Central Payment need to be reversed in the Central Finance system.

Cross-System Process Control

With the activation of Central Payment, business processes are distributed across systems. Replicated invoices are technically cleared in the source system and paid in the Central Finance system.

This can lead to the following challenges:

The actual clearing status of an invoice is not available in the source system. It is only available in the Central Finance system.
Business processes that depend on the actual clearing status of invoices in the source system may be impacted.
The mechanisms that are used to lock and validate the clearing status in a standalone system cannot be used in a cross-system scenario.

A new framework has been introduced in 1909 FPS1 to allow the smooth and consistent flow of business processes which involve changes to documents, and which are distributed across different systems where documents are replicated between the systems. The new framework is called Cross-System Process Control (CSPC).

Within the Central Payment scenario, you can use cross-system process control to implement the following controls:

For SD invoices, FI invoices and down payment requests, the system prevents a reversal being posted accidentally in the source system in the following cases:
- The document has already been cleared in the Central Finance system.
- The customer/vendor account is locked in the Central Finance system.
- The corresponding replicated document is locked in the Central Finance system.
In addition to individual document reversal (FB08), the controls above are also available for cross-company code reversal (FBU8).

Historical Open Items

Open items posted in the source system after Central Payment activation are technically cleared by setting the field of the clearing document (BSEG-AUGBL) to ALE-EXTERN and filling the field of the clearing date (BSEG-AUGDT). So, these open items can only be paid in the Central Finance system.

However, open items posted in the source system before the activation of Central Payment remain open in the source system. These open items are called historical open items which are open both, in the source system and the Central Finance system. To prevent double payment of these historical open items, they need to be set to technically cleared in the source system.

AP/AR items

As mentioned in Note 2346233, a pre-requisite of Central Payment is that all the historical open items must be paid and cleared in source systems before Central Payment activation.

The items which remain open after initial load, are not technically cleared and these invoices remain open in the source system as well. This means that this set of documents are open in both systems: source and central finance. If the historical open items are not cleared in source systems, the system does not actually prevent you from paying them in both source and Central Finance systems. So double payment is possible if the historical open items are not cleared in source systems.

The solution to the above issue is mentioned in Note 2654572 – Central Payment: Historical Open Items Processing in the Central Finance System. This note provides ‘Payment Block Reason’ to block the payment of historical open items in the Central Finance system. By implementing this note, payments for historical open items can only happen in the source systems as these items will get a payment block in the Central Finance system. As an alternative solution, a custom program can be developed to technically clear the open historical items.

Reversal of historical items

There are situations when reversal of payment document is necessary when both payment and clearing were done before Initial load, so were not transferred to Central finance. In this situation if the document is reversed only in the source system, the replication will fail in AIF because the referenced cleared items were not identified.

For those special cases, there is a standard program RFINS_CFIN_CORR_MISSING_CLRITM delivered via notes:

2447634 – Central Finance / Central System / Correction program: Transfer missing cleared items for a Reset-message
2608317 – Clearing Reset Triggers Error “No item cleared by document (&1, &2, &3, &4) found in the source system

The program should be executed by referencing the AIF message ID. It will create the missing open items similar as it would be created by Initial load open item balances. After that, replication of reversal is possible. The open items created by that program will be posted with the same posting date and same posting scheme (via substitution accounts) as they would be created by Initial Load of open items.

Clearing Bank Accounts

You can choose which bank sub accounts should be set to technically cleared. Only K and D is by default considered. You must configure bank clearing account in this step to be also considered here.

Historical Down Payments

For Central Payment historical open items from Down Payments need to be updated with sales-order related information, such as the sales order ID. Update down payment with sales order information (FINS_CFIN_APAR_SO_UPDATE). Update relationship (Down Payment Log) between historical open down payments and sales order (FINS_CFIN_APAR_SDDPLOG_UPDATE).

Changes to documents

After Central Payment is active it is still possible to make some document changes in the source system while other changes are only possible in the Central Finance system. Changes that may be made to ordinary cleared items may also be made to technically cleared open items. Changes that can be made to ordinary open items can also be made to these documents in Central Finance.

If any changes are made to the document in the Central Finance system, the corresponding changes should be done in the source system manually (if required). Changing the document in the source system post replication is permitted, however, it won’t have any impact in the Central Finance system.

Other Integrated processes

Once Central Payment is activated for a company code, all subsequent processes based on open item management must take place in the Central Finance System. For example:

Dunning
FX Revaluation
Interest Calculation
Customer / Vendor correspondence
Regrouping of Payables / Receivables
Provisions for Doubtful Receivables
Calculate and post Balance Sheet Adjustment
Inter-Company Reconciliation process
Month-end reporting e.g. Open Item lists, etc.

Rating: 0 / 5 (0 votes)