With the announcement of the new S/4HANA system, many process modules have been implemented in the new S/4 Core. But hardly any other module has been subjected to as many adjustments in the previous release cycle as the ECC known SAP CS module. From the removal of basic functionalities, such as the ability to generate resource-related invoices, via the DPP in the first release, to the adoption of former CRM document types and a basic integration into CRM inventory processes, the current release 09/2023 offers a tool set for the first time to be able to reflect existing customer requirements on a large scale.

Implementation in the new S/4 HANA Service Core

SAP’s strategy for integrating the new S/4HANA core processes in the service has become increasingly more detailed over the iterations of the last releases and, as of September 2023, provides a homogeneous picture for the first time.

The reference architecture represents the service core centrally embedded in the process flow of service processing. It includes all operational components of service processing such as quotation, repair, maintenance, commissioning, warranty and spare parts processing and the integration of invoicing and associated accounting processes.

Upstream of this, the SAP Service Cloud offers functionalities for customer interaction and provides basic information such as: For example, cross-channel contact information, ticketing and customer-specific information on SLA and entitlement handling are available.

Downstream of the Service Core is the SAP Field Service Management (FSM) module, which provides operational functions for technician deployment planning and implementation. At the planning level, deployments of technical service specialists can be planned and dispatched. The on-site technician is provided with a tool set with which he or she can design and carry out their own operations with feedback, material removals, form output, and GIS integration.

The reference architecture is rounded off by selected asset management elements. System performance can be measured here using SAP Asset Performance Management. An integration of GIS and location services enables visualization by the service and asset manager. Intelligent maintenance scenarios (reactive, predictive & preventive maintenance) offer options for optimizing the system condition and standby time.

With the release 09/2023, the process architecture of the new S/4HANA service scenarios provides a complete picture of the usage scenarios of the service processes at the macro level, thus enabling strategic planning of the service landscape. In detail, there are still (sub)processes that are currently not available or not fully available yet. The upcoming releases will provide information about the speed at which they will be available.

Core processes in Service Core

After classifying the new service core into the holistic SAP-supported service processing, we would firstly explain the core processes of the service. This will create an understanding of the current challenges and requirements for the process architecture and provide a basis for the process and transformation variants listed later.

Customer Service to Field Service

The classic technician process describes the handling of service processes in the field.

Technikerprozess Serviceprozesse im Feldeinsatz

After the service request has been received, an offer is made based on the relevant customer master data and the implementation of the credit control. At this point it is possible to determine costs and revenues based on planning data. Based on the nature of the offer, material availability can be determined, parts lists can be broken down and, if necessary, advance shipping of the parts from the warehouse to the place of use can be initiated.

The service scenario is then planned, and the technician deployment is scheduled. The service order created serves as a cost object and enables employees to report the times, kilometres driven and materials extracted after the activities have been carried out and thus realize actual costs and prepare the determination of the actual revenues. At the end of the process, the invoice is processed in the scenario determined (effort-related, time & material or at a fixed price).

Service Contract to Recurring Service

The next core process “Service Contract to Recurring Service” describes the classic maintenance processing based on the contract system.

Service Contract to Recurring Service

After the initial conclusion of a service contract, maintenance planning is carried out, depending on the system condition, operating cycle and maintenance intervals. Depending on the service contract, an advance offer can be generated here. Consumables for carrying out maintenance activities are checked in advance for availability and provided.

During service planning, it is checked on a case-by-case basis whether the activities can be carried out by our own technical specialists or whether external procurement of services is necessary and, if necessary, carried out. While the activity is being carried out, open warranty requests are offset, which may have a cost-effective effect on the maintenance order generated. The end of the process is the confirmation of the order and the financial processing – here usually via the billing plan of the service contract.

A big change in this context is the introduction of the new service document types. This means that the previously known interaction between SD (maintenance contract in ECC) and CS documents (generated maintenance messages and orders) is deliberately separated here and converted to specific service document types. The previously mentioned service contract is no longer an SD document, but is generated based on the previously known CRM document types. In the new Service Core, an interface to the SD module only comes into play again in billing and transfer to the invoice. A “billing document request” (BDR) is then generated for the service contract, which can then be transformed into an SD billing document using the billing document stock.

Return to Inhouse Repair

The core process for in-house repairs includes the collection of materials, the inspection and derivation of repair tasks and the re-provision of the material to the end customer.

Return to Inhouse Repair

Initially, the repair request is usually processed centrally by a customer service agent. The defective device will then be delivered. Additional processes such as integration into expanded returns processing or the parallel delivery of a replacement device are made available here. After the property to be repaired has been taken over, a credit check can be carried out on the customer. The device is then inspected and assessed and the (standardized) error pattern is derived.

On this basis, a repair offer can be generated. After the offer has been accepted, the repair order is generated and can be processed individually or using checklists. If it is determined that it cannot be repaired, the device will be removed and scrapped as part of the repair order. If the repair was carried out successfully, the repaired object is delivered to the customer. Depending on the nature of the offer, an invoice is generated at the end of the process either at a fixed price or dynamically based on effort.

Process variants and Implementation approaches

Due to the high level of structural realignment, SAP AG provides various implementation approaches for the new service core, which must be checked for implementation suitability in individual cases. The section below provides an overview.

Compatibility Mode

Compatibility mode initially represents the easiest way to convert service processes to S/4HANA. This mode represents the transition from ECC to S/4HANA, in which core functionalities of the old SAP CS are adopted 1:1. Existing document types continue to be used from the SD processes and new document object models are not yet used.


As part of the process standardization, the compatibility mode is an expiring solution that will currently be continued until December 31, 2030. Migration scenarios here are extremely simple: existing data is transferred to the new S/4HANA system and can be continued without further adjustments. Process optimization and integration into service-specific modules (cloud integration, asset management) are only rudimentary possible here.

S/4HANA Service Core

The originally developed S/4HANA Service Core includes the separation of old SD and new CS document object models and offers process integration for the previously presented core service processes.

S/4HANA Service Core

One of the most serious drawbacks in the original Service Core is the lack of a dynamic item processor that enables the creation of resource-related billing processes. Billing for the new service document types is therefore only possible at a fixed price. Furthermore, there is no complete integration into surrounding service scenarios (service cloud, asset management).
For this reason, the transition to the original S/4HANA Service Core will not occur.

S/4HANA Service 2023 with advanced execution

With release 09/2023, SAP AG implemented extensive adjustments to the service core processes. These will be published under the working title “S/4HANA Service 2023 with advanced execution”. In this application scenario, new service object models are combined with existing functionalities from SAP PM and SAP SD, thus creating a process area to be able to map existing processes combined with new functionalities from the Service Core.

S/4HANA Service 2023 with advanced execution

In the process, the new service document types are initially used in order to be able to map service-specific contracts, inquiries, offers or even orders. If billing is to be carried out at a fixed price, the new service receipts are sufficient, and the process can be processed through the SD Billing Integration into financial accounting. However, if effort-related scenarios are to be mapped or feedback is to be used to determine actual costs, one to “n” maintenance orders are generated from the service order position, which then provide all the necessary follow-up functionalities. If necessary, these can be invoiced on an expense-related basis via the DPP. As can be seen in the previous diagram, SD documents for the contract, offer and order no longer play a role in service processing with advanced execution.

Implementation of new Document types

The following process diagram for “Service with advanced execution” should not be seen directly as a core process in service processing, but rather as a structural overview. A cross-sectional view of the document types and object models is created here, which are integrated into the recurring service process steps (enquiry, customer interaction, service sales, planning, implementation, and billing). This process architecture is referred to in the S/4 Service Core as “Service with advanced execution” and includes elements from the new service as well as the well-known modules SAP PM, SAP SD and SAP FI.

Implementierung neuer Belegarten und Dokumententypen

The left area shows the new service object models, i.e. those document types that did not exist in the old SAP CS. The separation of elements of the SAP SD module becomes particularly clear here. There are new document types for service contracts, offers and the commercial service order. From the service order, a maintenance order is generated for executable items called “execution order items”, which can also be used in an offer phase as a planning element for work processes and material usage.

Based on this maintenance order, all other relevant objects are derived for implementation. Checklists are triggered in the order, reservations, external procurement and elements of advance dispatch are made in reference to the maintenance order and not to the service order. The following process steps, such as the confirmation of times or materials, also take place in reference to the maintenance order. The billing request can then be derived as an interface to the SAP SD module in reference to the service order or maintenance order.

Summary and conclusion

After a bumpy path of S/4HANA releases in recent years, the current release 09/2023 is the first time that a range of functions is available in the S/4HANA Service Core that can reflect customer requirements across the board and thus serves as a solid starting point for the development of perspective migration scenarios.

The integration of the new document object models takes some getting used to at first, but it clearly reflects the existing world.

Of course, there are also other open topics on the release list that are constantly being recorded, evaluated and processed. In this way, the range of functions is sensibly expanded step-by-step.

The development since the release 09/2017 has been subject to changes in the strategic direction with regard to the design of the service processes. Since the last realignment with the release 09/2021 and the successive adjustments and extensions, the current release 09/2023 represents a solid basis for re-implementing service processes or migrating simple scenarios to a new S/4HANA installation. In order to be able to determine a suitable migration approach for complex service scenarios, it makes sense to first gain experience with the new architecture and process integration. During further development, these processes can then be re-evaluated with regard to their ability to migrate and the lack of process integration.

Questions about Service Core?

Do you have questions about the new Service Core? Simply write to sapberatung@inwerken.de. Our consulting team will contact you! You can find additional services in our portfolio.