Describing Features of SAP Self-Billing Cockpit

In this chapter, you will get a high-level overview of the Automotive Industry Solution SAP Self-Billing Cockpit. If you would like to learn more about this solution, please consider taking the following course: Implementing SAP Self-Billing Cockpit (which is available on SAP Learning).

Processing high volumes of self-billing transmissions calls for a modern, digital solution with automation and mass change capabilities.

Issues in self-billing transmissions received from the buyer should be detected automatically and be highlighted early in the process to avoid time-consuming post-processing.

Self-billing involves the buyer taking on the responsibility of preparing and sending invoices to the supplier based on the goods or components received, thereby transferring the invoice verification process to the supplier. It is a widely adopted practice in industries where buyers and suppliers have close long-term relationships and frequently release comparable orders for physical products. Self-billing is particularly popular in the Automotive Industry, where it is used for settling the deliveries of vehicle components.

In this process, the buyer - typically an OEM or tier-1 supplier - shifts the ownership of the invoice verification process to their supplier. This means that it is not the supplier who sends an invoice to the buyer. Instead, the buyer prepares and sends the invoice in the form of a self-billing document along with the payment to the supplier and it is now their responsibility to verify the stated quantities and values to be settled.

When conducting business in different countries, different legal requirements apply for self-billing processes.

The verification of incoming self-billing invoices by the supplier is usually time critical because there are short periods for filing an objection against the received invoice while it is a challenge for the supplier to detect issues and deviations easily. Often this invoice verification is a manual process for the supplier which is cumbersome, time consuming and error prone.

SAP Self-Billing Cockpit is designed to identify errors and deviations early in the process, which allows the user to correct errors directly within the solution or to use the insights gained to seek clarification with the buyer - even before the contentious self-billing invoices are posted in the S/4HANA system. This makes SAP Self-Billing Cockpit an invaluable tool for suppliers to automate and streamline their self-billing processes because it raises awareness of issues and deviations early in the process, facilitates quick error resolution and prepares the billing data in S/4HANA for accounts receivables processing.

In this section, you will learn about the end-to-end supply chain scenario in which SAP Self-Billing Cockpit is applied and about the different processing types for self-billing invoices that are supported by SAP Self-Billing Cockpit.

• Applied when an internal billing document is created with goods issue
• This is usually the case in Germany, France and other countries

• Applied in countries where legal authorities request suppliers to create billing documents that are identical with the self-billing documents received from the buyer
• The supplier must create the final billing documents only after receiving the self-billing documents from the buyer
• SBINV is applied in countries like Spain and others

Which processing type is applicable usually depends on the country and its regulations where you want to implement the self-billing process. In certain countries, it is legally required to post the billing document in your system with same values and quantities as stated in the self-billing invoice issued by the buyer. Consequently, you must wait until you receive the self-billing invoice from the buyer before you can create a billing document in your SAP S/4HANA system taking over the transmitted data. This requirement is reflected in the Self-Billing with Invoice Creation processing type. In other countries where such a legal requirement is not in place the Self-Billing with Automatic Posting is usually applied. In this case, the billing document in your S/4HANA system is already created after the goods issue posting.

Self-Billing is usually applied in the context of an end-to-end supply chain scenario, where buyer and supplier are in a long-term delivery relationship with frequent deliveries of the same goods.

This delivery relationship is usually represented in the SAP S/4HANA system by scheduling agreements and the buyer will send forecasts with their demand for certain dates on a regular basis. Based on these requirements, the supplier will create an outbound delivery in the S/4HANA system, ship the goods physically to the buyer and post goods issue in the system.

In the Self-Billing with Automatic Posting - and different than in a regular billing scenario - the supplier will now create an internal billing document that is not sent to the buyer. When the buyer received the delivered goods, they will post goods receipt and run the so-called Evaluated Receipt Settlement (ERS) on the goods receipt data. As a result of ERS, the buyer issues a self-billing invoice and transmits it electronically to the supplier.

On supplier side, the self-billing transmission is then received into SAP Self-Billing Cockpit where it is checked and processed. When no errors are detected in the transmitted self-billing message, the solution will automatically perform a simulation. In this simulation, the values and quantities from the internal billing document created previously and the self-billing document received from the buyer will be compared and any deviations will be checked against defined tolerance limits and highlighted for the user.

The user may now review the simulation result and act, if required - for example, by correcting data in the SAP S/4HANA system or engage in clarification with the customer so resolve any issues. If all issues have been resolved, the user can retrigger simulation and - if the new simulation result meets their expectations - trigger execution.

During execution, the internal billing document, and the corresponding journal entry in S/4HANA will be updated with the payment reference transmitted by the buyer in the self-billing transmission to facilitate a smooth matching process of the incoming payment in financial accounting later. Furthermore, new debit or credit notes may be created during the execution step for difference clearing and to track open items.

The Self-Billing with Invoice Creation scenario is also applied in a long-term delivery relationship between buyer and supplier with frequent deliveries of the same goods.

Up to the point of the goods issue posting on supplier side, both processing types follow the same logic. After goods issue posting, Self-Billing with Invoice Creation is different: the supplier will not create an internal invoice before they have received the self-billing transmission from the buyer. This means that after the buyer has received the goods, they will post goods receipt in their system and run the Evaluated Receipts Settlement to issue and transmit a self-billing invoice towards the supplier.

When the self-billing transmission is received in SAP Self-Billing Cockpit on supplier side, the solution will verify the received data and run a simulation on it. Since there is no internal invoice available that can be used to compare the expected and received self-billing data, SAP Self-Billing Cockpit will trigger the simulation of a billing document in SAP S/4HANA. As a result of this simulation S/4HANA returns the values and quantities to SAP Self-Billing Cockpit that the supplier   would have billed based on their goods issue data and price condition records maintained in S/4HANA. This data set is then compared to the self-billing invoice transmitted by the buyer, deviations are detected and checked against defined tolerance limits.

The user now has the possibility to act on and resolve detected issues before triggering the execution of the self-billing document. During execution, SAP Self-Billing Cockpit will trigger the creation of new billing documents in SAP S/4HANA, including the payment references received from the buyer in the transmission. This will enable the matching of the incoming payment in financial account in the subsequent steps of the end-to-end process.

During processing of self-billing transmissions, the solution makes use of several key features that are shared for both processing types. This section covers these key features along with lighthouse capabilities like retro-active billing and deviations analytics.

Receive Transmission: Receive and process incoming self-billing transmissions sent by buyers for direct shipment and third-party processes (consignment).

Verification Checks: A series of edit checks, validations and data retrieval performed on transmitted self-billing documents

Simulation: Compare the results of the transmitted self-billing documents with the corresponding deliveries and billing documents to determine the results to be updated in S/4HANA.

Execution: Trigger the updates to and the creation of billing documents and journal entry in S/4HANA

Confirmation: Receive confirmation back from S/4HANA and mark the self-billing document as confirmed

The key features along the process that enable efficient processing of self-billing transmissions with SAP Self-Billing Cockpit and S/4HANA are as follows:

• Receive Transmission: SAP Self-Billing Cockpit provides one SOAP API each for the Self-Billing with Automatic Posting and Self-Billing with Invoice Creation processing type. With their defined structures they facilitate the receipt of transmissions from the buyer. One transmission can contain multiple self-billing documents. The self-billing documents include the received product quantity and the requested net value to be settled.
• Verification Checks: The system performs a series of checks on the data in the received self-billing documents. Based on the received data, the system first determines an outbound delivery using an outbound delivery number or external delivery note number, and then determines a reference delivery document in the integrated system. According to the reference delivery document, the system determines a reference billing document in the integrated system. The system then imports and displays data from these reference documents. If a self-billing document contains no errors, the system automatically proceeds to simulation. Otherwise, the system stops verification and displays the relevant error messages.
• Simulation: When the system verifies that the received self-billing documents contain no errors and determines their main reference number, the system aggregates data, if possible, and then compares this data with the reference data.
• Execution: Depending on the simulation results, the system automatically proceeds as follows: If there is no difference in net value, the system executes self-billing to trigger the update of the reference number in billing documents and accounting documents. If there are differences in net value, the system executes self-billing to trigger the update of the reference number in billing documents and accounting documents as well as the creation of new debit or credit memos for difference clearing. Furthermore, the creation of debit or credit memos might be triggered if the tolerance checks results in the need to generate open items.
• Confirmation: If the billing documents and accounting documents have been successfully updated or new ones have been created and posted in the integrated system, the self-billing document is confirmed, and the confirmation is shown in SAP Self-Billing Cockpit. Otherwise, the system displays the relevant error messages.

Retroactive billing is a special billing function often used in scheduling agreement processing. New pricing agreements made with the customer may also affect existing invoices that have already been processed and settled. This is often the case in scheduling agreement processing when the buyer changes prices retroactively for previous months which makes it necessary to revalue the deliveries that have already been billed with the previous price.    To cover these requirements, SAP Self- Billing Cockpit supports the processing of self-billing invoices that contain retroactive billing information.

When a new self-billing transmission is received, it is identified as retro-active billing based on indicators transmitted by the buyer, so called action codes. During the simulation step, the system determines the internal retroactive billing values and compares them with the claimed retroactive billing value from the buyer.

Deviations are highlighted to the users, and they are checked against defined tolerance limits allowing for early issue detection and correction, such as adjusting pricing condition records in the S/4HANA system or reaching out to the customer for clarification. The system determines whether to create new open items based on the claimed net value change and the internal retroactive billing value, preventing unnecessary new open items.

If the buyer's claimed net value differs and defined tolerances are exceeded, the system will indicate open item relevance and create billing documents for clearing and open items in the SAP S/4HANA system when executing the self-billing document containing retro-active price changes.

When transmissions are received and deviations are detected, SAP Self-Billing Cockpit will clearly highlight all deviations on the object pages of the respective self-billing document. For analyzing and keeping track of deviations across self-billing transmissions, SAP Self-Billing provides the following analytical apps:

• Manage Price Deviations to analyze price deviations across different transmissions per buyer and product. If the root cause is identified as wrong pricing condition records inside S/4HANA, a new price simulation can be triggered for all affected deviations directly from the Manage Price Deviations app after the pricing condition record was updated in the S/4HANA system.
• Manage Quantity Deviations to analyze quantity deviations across different transmissions per buyer and product.
• Manage Tax Deviations: to analyze tax amount, tax rate and tax ID deviations across different transmissions per buyer and product.

If more specific reporting requirements should be addressed that are not met by the out-of-the box analysis functionality, there is an option to integrate SAP Self-Billing Cockpit with SAP Analytics Cloud. Transmission data inside SAP Self-Billing Cockpit can be accessed by SAP Analytics Cloud to build custom reports and dashboards according to customers' individual reporting requirements.

In this chapter, you will learn about the high-level architecture of the SAP Self-Billing Cockpit and how it integrates seamlessly into the system landscape.

SAP Self-Billing Cockpit is a native cloud solution developed and operated on the SAP Business Technology Platform (BTP). It integrates seamlessly with one or more SAP S/4HANA systems to read, update or create relevant business documents such as outbound deliveries, billing documents and journal entries. By using SOAP APIs, the integration was realized leveraging state-of-the-art interface technology without the need to have an EDI middleware between  SAP S/4HANA and SAP Self-Billing Cockpit. SAP Self-Billing Cockpit is compatible with all deployment options of SAP S/4HANA:

• S/4HANA Public Cloud
• S/4HANA Cloud, Private Edition
• S/4HANA

With SAP Self-Billing Cockpit in place, the self-billing transmissions are sent from the buyer to an EDI middleware - for example, SAP Integration Suite, in industry-standard message formats such as VDA, Odette, EDIFACT, and so on. The communication between the EDI middleware and the SAP Self-Billing Cockpit is based on SOAP APIs. Therefore, in the EDI middleware the incoming self-billing transmission needs to be mapped to the XML structure of the SOAP APIs and sent directly to SAP Self-Billing Cockpit where it will be processed.