Skip to Content
Technical Articles
Author's profile photo Peter Hennig

Integrate SAP Subscription Billing with a non S4 SAP Backend

Hello Integrators!

Today´s blog post is a about the SAP Subscription Billing Cloud. Once you know what your customers want and need such as  running campaigns on Marketing Cloud and leveraging multiple inbound channels such as Facebook etc. the next step is to persuade customers to buy the services and products, that you are offering. That´s what you want, right? The Revenue Cloud an integrated way of doing just this.

This is a tool designed for modeling your products, including pricing. The cloud receives the consumption data and collects the payment information in billing objects. One off and recurring fees are added to the billing objects. After the billing cycle is closed, the billing objects are replicated to the backend.

Normally, the replication is designed to exchange data with a S4 System. Over the last few days, we spent some time connecting it to our ECC on premise system. If you face the same challenge, this guide will help you.

Architecture and Security


The picture below describes the architecture of your scenario.

As you can see, the ERP System is not communicating directly with the internet. With the Cloud Connector provided by SAP, you can easily decide and configure, which services of your backend system are available from the outside.

Standard iFLow delivered by SAP


Throughout the Package “SAP Subscription Billing Integration with SAP S/4HANA Cloud: Convergent Invoicing”, SAP delivers an iFlow to shoot the Billing Data from your Subscription Billing to a Backend System. The iFlow is called “Replicate Billing Document from SAP Subscription Billing to SAP S4HANA Cloud as Billable Item”.

I am going to describe briefly how it works here. The iFlow distinguishes between business partners, that already have a contract account, and those that don´t. If your business partner doesn´t have a contract account, the iFlow calls a webservice that then creates one in the backend and writes the returned ID back as an external reference to the business partner.

Throughout the remainder of the process, the iFlow collects the billing data for that customer and sends it to the backend system to create billable items.

Functionality to create Contract Accounts and Billable Items in the iFlow is only available on S4-Systems. However, our goal was to set up an integration with an ECC System.

Providing the Services ourselves


To do this, we created the two services in our on-premise system. The webservice is easy to create after downloading the WSDL-files from the iFlow. With this information, the wizard in sap creates webservices that easily create all the required structures for input and output.

After that, we had to implement the business logic behind it. For creating billable items, SAP standard provides function modules that are generated automatically for every single billable item class:

Then we only had to take the information that the cloud provides and parameterize it according to the input structure of the function module.

It was important to send the right output data back to the cloud, to satisfy the iFlow. For the creation of the billable items, the iFlow expects a positive Bitstatus:

After replicating the Billing Data, the Status turns to ‘transferred’ visualized with green color:

Adjusting the iFLow to our needs


We also created a copy of the standard-iFlow:The iFLow has problems with business partners that don´t have any external reference. The external reference corresponds to the ID the business partner has in the backend system. If you create the business partner directly in the cloud application, it won´t have any external reference. Nevertheless, the iFlow tries to replicate the billing data and throws an exception. Because of this, we modified the script for the extraction of the business partner ID.



This is our recommended method for setting up a non-S4 Scenario and still using the iFlow logic that is intended by SAP.

With these adjustments, you can easily model products in a cloud infrastructure and calculate the amount of money, your customers owe. The cloud is more flexible and easier to setup than a separate application like a convergent charging system.

You only need to use your backend system for transferring the billing objects to your contract accounting. If you already use Convergent Invoicing, you can merge the created Billing Documents to your well-known billing and invoicing process, if you want to.

Feel free to contact me, if you have any questions or proposals.






This Post was originally published here.

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo kristofer chua
      kristofer chua

      Hi Peter,

      Thanks for sharing the article. I just have a doubt and if you can help me clear it, i would really appreciate it.

      Based on the diagram that you provided:

      1. Inbound request to Cloud Integration doesn't need to flow to Cloud Connector. Does this mean the SOAP APIs from CPI can be called directly by ECC?
      2. Outbound request from Cloud Integration requires flow to Cloud Connector.Doesthismean-
        1. API/Service needs to be created in Cloud Connector and linked to another service in  ECC?
        2. How will the API from ECC be called by the Cloud Connector when an API is triggered?