Companies that deal with high-volume customers, often responsible for the majority of their output, have a particular set of requirements such as scheduling agreements and self-billing.
In these scenarios, the vendor often delivers product to these types of customers based on predefined agreements with set dates and quantities, often as part of a just-in-time (JIT) production planning. Price, payment terms, and other commercial aspects are relegated to an afterthought; the on-time delivery is the most important aspect of the transaction, subject to harsh penalties when not fulfilled.
Retro-billing functionality was designed to help expedite price corrections on invoices already issued; credit and debit memos are created automatically to account for retroactive price adjustments. These credit/debit memos are then sent to the customer, often as the last step of a careful negotiation process. These documents will adjust the pending accounts receivable balance that is likely causing issues with the customer credit checks.
Retro-billing can also be used whenever there is a price adjustment that affects invoices already issued. However, this scenario isn’t often raised as a high priority requirement during the implementation project. When your company runs into the need for retroactively billing for price differences, it’s usually too late to explore this feature due to the urgency of getting it resolved. If your business acknowledges this as a likely event, it may be worthwhile to add retro-billing to your scope as a business process.
To do so in SAP S/4HANA, first you update the pricing condition records. If the validity from date of the new price is in the past, there may be invoices that were issued with the old price. If that is the case, these invoices are relevant for retroactive price updates using Transaction VFRB.
The figure below shows the selection screen you’ll see when calling Transaction VFRB. Here you must indicate the mandatory parameters.
The Payer, Sales Organization, Billing Date From, and Billing Date To fields are used to restrict which existing billing documents will be verified. Knowing which pricing condition records were updated, you can conclude which invoices must be verified. You can use the Transaction VF05N report to find the invoices that were impacted if you have multiple payers. This may happen if the condition records weren’t customer specific.
Pricing Type indicates the type of pricing update that is to be executed. Be careful choosing other options because manual prices changes may be lost.
The Billing Date Credit/Debit Memo is the date to be used in the new credit/debit memos created as a result of this operation. You might want to make this date retroactive in some instances.
After you’re done making selections, click the Execute button. All invoices matching the selection will be verified, and if the modified condition records affect the prices on those documents, they will be selected and displayed in a report, as shown in the next figure.
Credit/debit memos, return credits, and other documents assigned with order reasons configured with value 2 (Credit/debit memo to be retro-billed at price change) for Retro-Billing relevance are also considered in this report. Order reasons configured with blank or 1 Retro-Billing are ignored.
In the report shown below, you can manually select the invoices to be processed by marking the checkboxes or using the command buttons to Select All invoices or De-select all invoices. You may also use the Details button to review the full details of any of the invoices in the report or Refresh the information after executions.
13
When you’re satisfied with your selection, you may Simulate the processing or execute it directly using the Retroactive Billing button. Note that you must make a selection for the desired credit memo document type and order reason as well as debit memo document type and order reason (see below). This can be achieved by choosing More > Settings > Change; otherwise, this transaction will prompt you for these values upon processing. After you make your selection for these four parameters, click the Save button.
You may choose a special type of billing document configured specifically for retro-billing purposes or use the SAP standard document types G2 and L2, as shown in the previous figure. The reason codes must also be specified, and you can only choose entries configured with value 1 (credit/debit memo request used for retro-billing) for retro-billing relevance. If you choose order reasons configured with blank or 2 Retro-Billing, you’ll get an error message saying Valid Credit Memo Required for Retro-Billing, but this message is vague and misleading.
The criteria you use when defining the document types to use hinge on whether or not you want to consider the retro-billing credit/debit memos in reports and profitability analysis. If you use a separate document type, you can show these documents and not the normal credit/debit memo requests created.
The credit/debit memos will post to accounting and create accounts receivable entries. These entries need to cleared either via payments or adjustments of open balances using functionality managed by the finance team.
If you used the Simulate button, you’ll see a summary report of the execution results (see below) with the number of credit and debit memos that are about to be created along with the number of messages issued during this process. Use the Log button to see the messages. When you’re ready to process the document, you may click the Retro-billing button on this screen.
The same screen appears after you click the Retroactive Billing button either in the simulation execution results screen or in the report shown previously. The title will indicate whether this is a simulation result or an update run (see figure below, callout 1). Note that on update runs, the Retroactive Billing button isn’t available, only in simulation mode.
Upon successful execution of the retroactive billing, new billing documents will be created with reference to the original invoice. When reviewing the document flow of the related documents (shown below), you’ll find the debit/credit memo as a subobject of the invoice selected in the Transaction VFRB report.
13
Note: You must include condition type PDIF (price difference) on all pricing procedures that may be subject to retro-billing. Otherwise, the credit/debit memo will be issued with the full amount of the updated price. PDIF will deactivate the price condition type, and the value assigned to the PDIF by Transaction VFRB will be the difference between the price in the original invoice compared to the new condition records maintained retroactively.
The foundational course on SD processes and configuration! Understand the organizational structure and master data in SAP S/4HANA. Learn to customize basic and cross-functional settings in SAP S/4HANA, and then focus on SD processes and their configuration: ATP, pricing, sales processing, shipping, and billing. Take a close look at SD simplifications and enhancements to get the most out of your system! This upcoming course in March and April is live on the web and will teach you all you need to know about these topics. Click on the banner below to learn more and order your ticket.
Editor’s note: This post has been adapted from a section of the book Configuring Sales in SAP S/4HANA by Christian van Helfteren.