Financial Management Blogs by SAP
Get financial management insights from blog posts by SAP experts. Find and share tips on how to increase efficiency, reduce risk, and optimize working capital.
Showing results for 
Search instead for 
Did you mean: 
Ever wondered how to link your sub-ledger accounting with an operative service system? My blog article will show you how to use the Disconnection and Reconnection of Services function in SAP S/4HANA Cloud  (also available in on-premise versions) and how to configure it to your own solution!


  • Understand the feature

  • Understand the process

  • Master data

  • Disconnection of services

  • Reconnection of services

  • Transfer disconnection and reconnection requests

  • Monitoring of disconnection and reconnection requests

  • Understand the configuration

  • Conclusion

  • Appendix

Understand the feature

Contract Accounting allows you to block or disconnect services consumed by your customers, if the customers are having open receivables which are relevant for dunning. This means you can establish a connection between your open item management system and an external, technical system which is responsible to provide the service to you customer.The feature is embedded in the Contract Accounting dunning process and is flanked by operational and analytical apps.

A disconnection request for the end-customer's service is generated from the dunning process based on the customizing settings in your system. The disconnection requests are transferred from the financial system to the operational, technical service system. This system disconnects the service for further usage. If the customer clears the corresponding open item, a reconnection request is created. This request is also transferred from SAP S/4HANA to the operational service system to reconnect the service for the customer. Individual services - e.g. in the healthcare sector - can be excluded from this mechanism.

Understand the process

Process Overview

The process steps:

  1. A dunning activity creates one to many disconnection requests, based on your configuration.

  2. The disconnection requests are transferred to the external system, this system will execute the disconnection requests created in step 1.

  3. Based on incoming payments, Contract Accounting analyzes if the service can be connected again, a reconnection request is created.

  4. The reconnection requests are sent to the external system, this system will connect the service, the end customer can continue to consume the service.

Master Data

A service is represented in Contract Accounting by the provider contract object with one to many provider contract items.

Without this object you can not use the Disconnection and Reconnection of Services feature.

If your business case contains services which should be excluded from the disconnection, you can set the indicator “Disconnection of service not permitted” (XDISCOEXEMPT) on the level of the provider contract item.

You can find the flag on tab Items: Dunning.

Service lock flag

Disconnection of services

The disconnection request is created during the dunning process. In your dunning procedure, a corresponding activity is needed (020 – Service Disconnection Request;function module name in on-premise systems FKK_DISCOPROPOSAL_CREATE_0350). As soon as this dunning activity is executed and the criteria are met, the disconnection request is created. Regardless of whether the dunning procedure is assigned to the contract account, the provider contract or the open item itself. Additionally, the field "Reconnection Status" (DFKKOP.RCSTA) is set to true on the open item.

From experience, it is recommended to send a proper correspondence to you customer in order to ensure a clear and fair communication.

Example dunning procedure with disconnection activity

For the on-premise users who like to dig through the tables of Contact Accounting, I would like to give some hints about the attribute RCSTA (Reconnection Status) in table DFKKOP.

This field contains the status of an open item regarding the service disconnection or reconnection.


  • Space - Item is not part of a disconnection request.

  • X - Item belongs to a disconnection request.

  • 1 - An incoming payment was posted. The reconnection can be analyzed, but it’s pending.

  • 2 - Reconnection analyzed: The incoming total payment was greater then the defined threshold.

  • 3 - Reconnection analyzed: The incoming total payment was smaller then the defined threshold.

Status changes:

  • Space to X : Set by dunning activity.

  • X to 1 : Set by incoming payment.

  • 1 to 2 : Set by analysis of incoming payment; payment was higher than the defined threshold.

  • 1 to 3 : Set by analysis of incoming payment; payment was smaller than the defined threshold.

  • 2 to 1 : Set, if the payment was reversed or in the case of a clearing reset.

  • 3 to 1 : Set, if the payment was reversed or in the case of a clearing reset.

Reconnection of services

In order to reconnect the service for the customer, exactly these open items must have been cleared, who have triggered the disconnection request. No matter which process in Contract Accounting has posted the incoming payment.

The analysis, if incoming payment do met the criteria to reconnect a service, has to be scheduled as a separate job. In the case, that all requirements are fulfilled, a reconnection request is created.

This process step is called “Analyze and create reconnection requests” and has two tasks:

  • Check, if incoming payments are good enough to reconnect a service

  • If yes, create the reconnection request

The ID of the app is F4654 - Create reconnection requests (on-premise transaction FKK_DISCPROP_ANALYZE).

Entry screen app Create Reconnection Requests

Transfer disconnection and reconnection requests

It makes sense to transfer the disconnection and reconnection requests on a regular basis (e.g. once a day) from your finance system running Contract Accounting to your operational, technical system.

You can use for this purpose app F4658 - Send Disconnection/Reconnection Request (on-premise transaction FKK_DISCOPROP_SEND).

The status of the disconnection and reconnection requests can be changed if you reverse dunning activities or reset clearings.

This list shows the possible status of a request and explains from where it derives:

  • Valid: just a valid disconnection and reconnection request.

  • Obsolete - disconnection request: The disconnection request was not sent to the external system; status change due to dunning reversal.

  • Invalid - disconnection request: The disconnection request was already sent to the external system; status change due to dunning reversal.

  • Obsolete - reconnection request: A payment was reversed; status change due to clearing reset.

Send disconnection reconnection requests


The disconnection and reconnection requests are transferred by two separate, asynchronous interfaces from Contract Accounting to the external system.

Your external, operative system needs to implement these interfaces in order to process the incoming requests.
Both interfaces are based on a SOAP API provided by SAP.

Interfaces between Contract Accounting and external system

For the cloud edition you configure in the Communication Arrangements app the scenario SAP_COM_0579 (Finance - Contract Accounting Service Disconnection and Reconnection).

Communication Arrangement 0579

Monitoring of disconnection and reconnection requests

The requests for disconnection and reconnection requests created out of dunning and payment processes, can be easily monitored with the Fiori app F4943 - Monitor Disconnection Requests.

This app groups and visualizing all the requests based on their status (valid, invalid or obsolete).

You can use different criteria for selection of data, e.g. the company code or the contract account number.

Entry screen monitoring app

In the detail view of a disconnection request you can see:

  • General information like the dunning amount and company code

  • The dunned business partner items

  • A reconnection request, if applicable

The example screenshot shows a sent disconnection request with a corresponding reconnection request.

Disconnection request detail view

Understand the configuration

You can find the configuration for Disconnection and Reconnection of Services easily in the Configure your Solution app.

Configuration Steps

Each request has its own number, therefore a number range interval must be defined for the object FKK_DISCO (my most favorite number range name).

The number range object

The settings are depend on the company code.

A currency can be specified for thresholds, Contract Accounting will convert the currency if needed.

Configuration of disconnection and reconnection

The most important thing is to set the thresholds correctly, as described in the following section.

Minimum open amount

During the dunning process, Contract Accounting checks whether the dunned amount exceeds this threshold. If yes, a new disconnection request is created.

In our example shown in the screenshot, a dunning amounting to 90 Euros will not lead to a disconnection request, but a dunning amounting to 150 Euros does.

It is also important to consider the minimum amount that is assigned to the dunning level. If the dunning activity is not fired for the dunning level, the disconnection request will not be created.

Maximum open amount

Incoming payments are compared with the Maximum open amount configured. In the case that the total amount is smaller than the configured maximum open amount, Contract Accounting will create a reconnection request.

If 0 Euros are defined as maximum open amount, the reconnection request is created only, if all items belonging to a disconnection request were cleared.

Max. percentage

There is also the option to work with the Maximum percentage. Let‘s assume that 1% is defined as maximum percentage, Contract Accounting will then create the reconnection request only if 99% of the open items were cleared.


From my point of view this business transaction gives you the chance to leverage the strengths of Contract Accounting and link them with an external, operative service system. In consequence, you can control from your open item management system directly, if a service can be consumed from a customer or not.

It would be great to receive your feedback and your thoughts about this article in the comments section.

The most of you already know our community resources for SAP Billing and Revenue Innovation Management, if not please subscribe to them:

I hope this blog post is useful for you and that you can profit from this feature, if you like this article you can start following marius.tack01. From time to time I will write some blog postings about interesting learnings on my projects.




  • DFKK_DISCO_PROPH - Service disconnection request header

  • DFKK_DISCO_PROPI - Service disconnection request items

  • DFKK_DISCO_LOG - Logging table disconnection

  • DFKK_RECO_PROP - Service reconnection request

  • DFKK_RECO_LOG - Logging table reconnection


Documentation (deep link to this feature):
1 Comment