How To Efficiently Set Up and Manage Your Rebate Programs: Rebate Processing in SAP

Rebate Processing in SAP:
How to Efficiently Set Up and Manage

Your Rebate Programs
By Matthias Liebich, MLI Solutions, LLC
Editor’s Note: Even a casual stroll through the Sunday paper reminds us that we can no longer
ignore the proliferation of rebates in our lives. Taking the “if we can’t beat ’em, join ’em” attitude,
SD master Matthias Liebich decides it’s time to show SAPtips readers the inner workings of
rebate functionality in SAP®. Matthias points out that even the most flexible and robust ERP
systems have to be stretched and tweaked to support “the crazy deals that salespeople sometime
concoct to incent their customers”. This 30-page white paper presents a sweeping review of what
the SAP rebate function can and cannot do. Matthias introduces rebate planning, setup, and
configuration in SAP. He then brings the focus to the detail level, using screen shots to illustrate
the procedures for managing the rebates, primarily relating to accrual, paying, and tracking.
Introduction
When I opened the Sunday paper a while ago, I was overwhelmed with all the President’s Day
offers of “free” things. Of course, after reading the small print, I realized that it was only free “after
rebates”. Every time I see these ads that promise me “free” DVDs or food, I get excited; but my
wife never fails to remind me that there is no such thing as a free lunch.
It is common for companies to pay rebates to their customers in return for fulfilling certain
requirements. The classic example is the car manufacturers. They give their car dealerships a
rebate at the end of the year, depending on how many vehicles they sold. This way, the dealers
make money, even if they sell you your dream Beamer at “invoice” price (all right, maybe not a
BMW).
How do SAP customers manage these rebates? This is the subject of this issue’s pricing related
white paper. SAP provides a basic set of rebate functionality to manage the most common rebate
scenarios. However, no standard system can handle the crazy deals that salespeople sometime
concoct to incent their customers. This white paper will show you what SAP rebates are capable
of (and what not). It will guide you through standard configuration, how to plan and set up rebates
in SAP, and most importantly, how to track and pay out rebate payments. Rebate functionality
first was available in rudimentary form back in R/3 version 2.1. With R/3 Release 3.0, that
functionality received a significant overhaul. Since most SAPtips readers are running on 4.6 (as in
this white paper) or 4.7 versions of R/3, you can be confident that the rebate tips provided in this
article will be applicable to your installation.
Copyright © 2005 by Klee Associates, Inc. Page 1

www.SAPtips.com
Overview of Functionality
If you know how to set up your pricing configuration, you will not have any issues configuring
rebates. It uses the same condition technique (but with rebate specific features), about which I
will go into detail when I walk you through the rebate setup.
But before I go into the configuration of rebates, it is helpful to understand how rebates work in
SAP.
For example, in this white paper, we assume that we want to give a customer a 3% discount on
everything he or she buys (condition type ZB03). In addition, we will give away another 1%
discount if the customer reaches a certain amount of gross sales for the year, for a specific group
of products (ZB01). We will also have a promotion that will give the customer $1.00 back if he or
she buys certain products (ZB02). After all these rebates are set up, the rebate conditions will
apply on applicable invoices as accruals instead of off-invoice discounts. The rebate agreement
tracks the applied amounts, which can be reviewed at anytime in the rebate agreement. Once we
decide to pay out any rebate amount to the customer, we will create a rebate settlement, which is
represented by a credit memo request. This reverses accrued amounts and pays the actual
monies to the customer either in form of a check or a credit memo.
I would like to divide the rebate process in SAP into three separate components:
1) Configuring Rebates
2) Setting Up Rebate Agreements
3) Managing Rebate Agreements and Payments
1) Configuring Rebates
The configuration section for rebates can be found in the IMG under Sales and
Distribution>Billing>Rebate processing. Some of the configuration transactions are shared with
regular pricing, but it is easier to remember this central configuration path to access your entire
rebate related configuration.
Prerequisites
Before you even start configuring rebates, three settings have to be made in order for rebates to
work:
1. The Payer partner needs to have the “Rebate” field checked in the Customer master on the
Sales Area>Billing Document tab.
2. The billing type must be marked as relevant for rebates (IMG Sales and
Distribution>Billing>Rebate processing>Activate Rebate Processing>Select billing
documents for rebate processing).
3. The sales organization must be marked as relevant for rebates (IMG Sales and
Distribution>Billing>Rebate processing>Activate Rebate Processing>Activate rebate
processing for sales organizations).
The system will issue respective messages when you are trying to process any rebate-related
transactions with any of these settings missing.

www.SAPtips.com
Condition Technique for Rebates
Rebates use the condition technique, but distinguish themselves from pricing in applying to
transactions over time, versus on a transaction basis.
In this white paper, I will not get into the creation of rebate condition tables (since the settings
work the same ways as in pricing). The only thing you have to be aware of is that rebates have
their own field catalog and their own condition table naming convention. So you could potentially
end up with two condition tables “001”; one for pricing and one for rebates, which could have
different key fields. If you want to query the tables with transaction SE16, you need to use the
technical names: A001 for pricing, and KOTE001 for rebates.
To create rebate-related access sequences (AS), use IMG path Sales and Distribution>Billing-
Rebate processing>Condition technique for rebate processing>Maintain access sequences. You
will recognize the screen (see Figure 1) since it is the same one as for pricing. In order to
distinguish pricing and rebate specific access sequences, enter “1” in field “Cat” (Category) for
rebate specific AS. Select AS “BO01” and double-click on the “Accesses” tab.
Figure 1: Access Sequence for Rebates
The big difference between the rebate and the pricing access sequence is that there is no
“Exclusion” flag available for rebate-related AS (as you can see in Figure 2). This means multiple
tables for an access sequence could apply at the same time.
However, OSS note 105681 explains how to turn on the Exclusion flag, but there are several
other impacts in doing this change, which I will address in the last part of this white paper.

www.SAPtips.com
Figure 2: Condition Tables in a Rebate Access Sequence
Rebate-related condition types are identified by condition class “C” (Expense Reimbursement).
When you create a new rebate condition type (IMG path Sales and Distribution>Billing>Rebate
processing>Condition technique for rebate processing>Define condition types) and you change
the class to “C”, you will realize that several fields you can usually use in a regular pricing
condition will disappear or become unavailable. For example, you will not be able to use
Condition Updates or Group Conditions. Instead, you get a configuration section exclusively
available for rebate condition types (see Figure 3).
If the “Rebate proc.” field is blank, accruals will be posted on each applicable invoice. Entering an
“A” will prevent the automatic generation of accruals on invoices. The latter would make sense if
you don’t base your rebate payment on actual sales, but on the specific performance of the
customer (such as a display in a store or an advertisement in the paper). These rebates would be
paid out as a lump sum and would require the creation of a manual accrual. For example, you
want to give the customer a $5000 rebate if he displays your product at the entrance of his store.
You then would create a one-time manual accrual of $5000. Once you have proof of compliance
by the customer, you can create a lump sum payment in that amount, which would reverse the
accrual and pay the amount to the customer.
With the “Provision con.” Field, you determine if you want to reverse your accruals at time of
partial payment (we will cover payments later in that paper). Leaving this field blank will reverse
the accrual; a value of “A” will not reverse it.

www.SAPtips.com
Figure 3: Rebate Condition Type Definition
Now that we defined our rebate conditions, we can add them to our regular pricing procedure
(IMG path Sales and Distribution>Billing-Rebate processing>Condition technique for rebate
processing>Maintain Pricing Procedures). Please note in Figure 4 that not all configuration fields
are available for the rebate conditions in the standard system. Alternate condition type “AltCTy”
and Alternate condition base value “AltCBV” will not let you do any manipulations on how the
rebate is calculated. Also, you will not be able to do any manual changes to rebate conditions.
The requirement “24” in column “Reqt” prevents the rebate condition from displaying on any
document type but the invoice. Simply take this requirement off if you want to have visibility of
rebates at order entry time as well.
A very important setting for the rebate conditions in the pricing procedure is the account keys. As
I mentioned in the introduction, at invoice time, accruals are being created that post to
accounting, to give you visibility on how much you owe your customers. The posting of this
accrual is done by accounts assigned to the account key in column ‘Accrls’ (Accruals); usually a
sales deduction and an accrual account. The settlement document (in form of a credit memo)
uses the accounts assigned to the account key in column ‘ActKy’ (Account key), which reverse
the accrued amounts and credits the customer.
It is also imperative that any sub-total line a rebate condition refers to needs to be stored in one of
the seven available sub-total fields (KZWI1-KZWI6 and BONBA in column “SubTo”). If you are
using multiple pricing procedures, you want to keep the sub-total designations common (i.e., 1 for
gross price, 2 for net price).

www.SAPtips.com
Figure 4: Rebate Conditions in a Pricing Procedure
Configuring the Rebate Agreement
You might be familiar with sales deals in SD. The rebate agreement is based on the same
principal, but way more powerful in how you can configure it. To maintain rebate agreement
types, use IMG path Sales and Distribution>Billing>Rebate processing>Rebate
agreements>Define Agreement types. Select “New Entries” to create a new agreement type.
All field references in this section are made in regards to Figure 5.
Default values
The first section (Default values) serves to define the defaults that apply for every rebate
agreement of that type. You can define the default start and end date of the agreement. The
default start date is important in regards to whether or not you want to allow retroactive rebates.
For example, if you set the start date of a rebate agreement to today’s date, all invoices from that
moment on are eligible for the rebate and will apply on the invoice itself. However, if your default
is the beginning of the current year, the system will calculate rebates for all invoices in the past,
from that date on, even if they did not apply on the invoice. These rebates are called retroactive.
The other default in this section allows you to set a payment method, which is freely definable to
suit your individual situation. Every rebate settlement will create a credit memo request in SAP;
however, if you set your default to “C” for check, it will carry this flag forward to FI, to later let you
cut a check. Of course, all of these defaults can be overwritten during creation of the actual
rebate agreement.

www.SAPtips.com
Control data
The “Condition type group” is linked to the rebate agreement type in a different configuration
transaction, which we will get into a little bit later. This condition type group defines which rebate
condition types are allowed for the rebate agreement type.
The “Verification levels” field is also a default that defines the level of detail you see when you
review the applied invoices within a rebate agreement. You can change this default while
reviewing the verification level in the rebate agreement.
The “Different val. period” option lets you define whether or not the rebate condition records you
create out of the rebate agreement can have validity dates outside of the ones of the agreement. I
suggest you leave this field unchecked.
If you want to allow manual accruals (we will get into what these are for), you need to indicate this
and define the respective order type. “B4” is the standard SAP order type for manual rebate
accruals.
You are able to create the same rebate agreement automatically in regular intervals with the
same data (but different validity dates). To turn on this feature, utilize the “Arrangement calendar”
field to do that. You can add a standard SAP calendar, or your own defined one, to schedule the
automatic creation of rebate agreements. In a separate step, schedule job RV15C005, which can
also be accessed via transaction “VB(D” (yes, that’s the left parenthesis in the transaction code),
to automatically extend your agreements.
Manual payment
The “Manual payment” section of the rebate agreement defines how much can be paid out during
a partial settlement. You would use partial settlements if, for example, the rebate agreement is
defined for a full year, but the payouts are supposed to happen on a monthly, quarterly, or any
custom defined schedule.
You can choose whether you want to allow partial settlements only in the amount of what you
accrued so far. This is a good idea if you don’t want to pay out more than what the customer is
entitled to. However, you can also allow any payment amount, if you choose so. As with manual
accruals, you need to define the partial settlement order type, which is “B3” in the standard SAP
system. If you don’t want to wait to reverse your accruals until the final settlement, you can do so
for the partial settlement by checking the “Reverse accruals” box.
Just as with agreements, you can also schedule regular payments by entering the appropriate
calendar in the “Settlement periods” field. Use program RV15C001 (accessible through
transaction “VB(7”) to schedule your payment runs. This will create automatic payments
according to the defined schedule.
The reversal of the accruals is independent from the payment amount of the final settlement. For
example, if you accrued $10,000 over a given period, but the customer did not reach their sales
goal, you might want to pay only half that amount or nothing at all. No matter what the payment
amount is going to be, the total remaining accrued amount for the agreement is reversed.
Settlement
The “Settlement” section defines the final settlement order type (“B1” in standard SAP) and the
minimum status that needs to be set in the agreement before it can finally be settled. This will
become more clear when we cover the actual settlement of a rebate agreement later in this
paper.

www.SAPtips.com
The standard correction order type “B2” is needed if the statistical and actual accrual amounts are
getting out of sync. This is mostly the case for retroactive rebates.
Text determination
You can assign text types through standard SAP text determination to the agreement type as
well, which will enable you to add comments. These comments will show on a printed rebate
agreement
Figure 5: Definition of a Rebate Agreement
Condition Type Groups
I mentioned the assigned condition type group in the definition of the rebate agreement. With IMG
menu path Sales and Distribution>Billing>Rebate processing>Rebate agreements>Condition
type groups>Define condition type groups, you can freely define your rebate condition type group
(see Figure 6). Make sure that you leave the “Cat.” (Category) field blank. This defines the
Condition Type Group as relevant for rebates. Sales deals share this configuration transaction
and would be identified with a category of “A”.

www.SAPtips.com
Figure 6: Definition of Condition Type Groups
Assigning Condition Types to Condition Type Groups
In this configuration step (IMG Sales and Distribution>Billing>Rebate processing>Rebate

agreements>Condition type groups>Assign Condition Types/Tables To Condition Type Groups),
you define which condition tables, of which rebate condition types, you allow for a specific
Condition Type Group, and in which order they appear in the rebate agreement (see Figure 7).
Since the standard SAP rebate functionality does not allow exclusions in the access sequence,
the order of condition tables can be freely defined here. You can assign multiple condition types
that can have different access sequences.

www.SAPtips.com
Figure 7: Assigning Rebate Conditions to Condition Type Groups
Assignment of Condition Type Groups to Rebate Agreement Types
Finally, we are able to link the Condition Type Group to the Rebate Agreement Type through the
IMG menu path Sales and Distributions>Billing>Rebate Processing>Rebate
Agreements>Condition Type Groups>Assign Condition Type Groups to Rebate Agreement Types
(see Figure 8).

www.SAPtips.com
Figure 8: Assignment of Condition Type Groups to Rebate Agreement Types
2) Setting Up Rebate Agreements

The rebate agreement is the central point for processing rebates. Here are the main tasks that
can be done out of this transaction:
• Define the payment method and validity of the rebate agreement.

• Define the condition records with rates and scales for which rebates should apply. NOTE:
You cannot create rebate condition records with the regular pricing transaction VK11 or
VK31. (This is due to the condition class of “C” as indicated in the section above about
condition types.)
• Review all applied invoices to a specific rebate agreement.
• See which payments were already made and how much you accrued.
• Generate partial and final settlements, as well as manual accruals. NOTE: If you attempt to
create any rebate credit memo manually with VA01, you will get an error. The reason for this
is the same as the one for the condition types. In order to track all payments within the rebate
agreement, they have to originate from that rebate agreement.

www.SAPtips.com
To create a rebate agreement, either execute transaction VBO1 (with the letter O, not a 0) or use
menu path Logistics>Sales and Distribution>Master Data>Agreements>Rebate
Agreement>Create. In the screen shown in Figure 9, enter the rebate agreement type and click
on the “Organizational Data” button. Enter the sales area in which the rebate should be
paid. It is important to understand that this sales area will be used to create the rebate
settlements. The condition records that are created within this rebate agreement can be for the
same or for different sales areas. For example, your rebate payments are going to be made in
sales area 1000,01,01. However, you set up different condition records for different rates in
different sales areas (1% for 1000,01,01, 1.5% for 1000,02,02,etc.). Click on the “Copy” button.
Figure 9: Entering a Rebate Agreement
On the next screen (Figure 10), enter the description of the rebate, the rebate recipient, the
currency in which the rebate payments are going to be made, the payment method, and the
validity period of the agreement. Here are some comments to the individual fields:
The rebate recipient has to be a payer partner. You also need to make sure that the payer partner
type that you are using (“RG” in standard SAP) is linked to the account group you are using for
the sold-to (“0001” in standard SAP). As we can see later, the rebate recipient becomes the sold-
to in the rebate settlement credit memos.
The payment method defaults from the rebate agreement type configuration setting and can be
overwritten here. The same applies to the validity period. Originally the valid from date is
defaulted to today’s date (as set in the agreement type). Since our sales department was (as
usual) late to give us the agreement information, we need to back-date the start date to the first of
the year. We assume that the rebate agreement is valid for the whole calendar year, but if you
want to do it by fiscal year, just adjust the dates to your liking. Once all this data is entered, click
on the button to create rebate condition records.

www.SAPtips.com
Figure 10: Rebate Agreement Overview Screen

www.SAPtips.com
Do the available condition types and tables in Figure 11 look familiar? You are correct, these are
the settings of our condition type group (see Figure 7). Double click on the key combination for
which you would like to create a record. For this rebate agreement, we choose condition type
BO03 with the customer key combination.
Figure 11: Available Condition Types in a Rebate Agreement
You can see that the validity period for the condition record defaults from the validity period of the
rebate agreement. As we defined in the agreement type, an attempt to change the validity period
(to one outside the agreement validity period) would result in an error. However, you can change
the validity period to one within the range of the agreement period. For example, if you set up the
agreement for the whole year and you pay out on a monthly basis with different amounts, it
makes sense to create multiple condition records with monthly validity dates.
If you enter a rate in Figure 12 and hit Enter, the same amount applies in the “Accruals” column. It
is important to remember, that the rate represents what you are going to pay to the customer, and
the accrual is what you accrue over time on invoices. This becomes very clear when you are
using scales. Although you are able to maintain different rates based on different scale levels of
sales achievements, you can only maintain one accrual rate.
The accrual rate applies on each invoice, at which time you don’t know if a customer will reach
the next scale level over the time of the agreement. You might want to maintain an average
accrual rate (for example, if you have scale rates of 1, 2, and 3%, your accrual rate might be the
median of 2%). However, based on your accounting guidelines, you also might either over- or
under-accrue.
You also have the choice not to accrue at all (for example, for a lump sum payment) and can take
out the accrual rate entry. However, if you are trying to create partial settlements and configured
the agreement to not allow higher payments than what you accrued, you will have to create
manual accruals in order to do so.

www.SAPtips.com
Figure 12: Rebate Pricing Record Rates
Select the condition record and click on the “Details” button.
At the bottom of the “Control Data” section of the details screen (see Figure 13), you can see that
the condition record was created retroactively. This means that not only will invoice line items
apply from this day forward, but also the ones that were created from the valid from-date of the
condition record, until today’s date.
Since a rebate settlement in SAP is reflected as a credit memo request, a material number is
needed to generate the credit. The material for this credit memo is stored in field “Matl. f. settl.”
(Material for settlement). Since the key combination we choose is by customer, we need to define
a material of our choosing. For most of my clients, this always causes an issue with reporting,
since the materials that are actually being accrued on cannot be easily tied to the material of the
settlement. You will always have to choose a material if the material number is not part of your
condition table. In the latter case, the material number defaults as the settlement material.
If you like to create more condition records, use the green back-arrow to go to the “Valid
Condition Types and Key Combinations” screen (see Figure 11). However, if you are done with
all your rebate pricing maintenance, you can now save the rebate agreement. At this point, I
would like to give some insight on the number of condition records you create per rebate
agreement. Although we allowed three different condition types to be maintained within
agreement type “ZSRB”, it does not mean that we have to maintain it in one and the same
agreement. It makes sense to distinguish multiple rebate agreements based on the type of rebate
you want to give. For our example we will create three separate rebate agreements: One for all
the items a customer purchases throughout the duration of the rebate, a second can be created
for the performance based (scale). and a third agreement for the material promotion.

www.SAPtips.com
This way, if you want to see the status of one of your rebate programs, you can look at it without
having to dissect other rebate conditions. It also improves performance since the system does not
have to read every invoice line item every time.
Another common mistake I often see is that instead of creating new rebate agreements (for
example, yearly renewals), clients just extend the validity end date of the agreement. The
problem with that scenario is that when you want to look online to see which invoice line items
applied to the rebate, the system has to look back at two or more years worth of data. Get your
mocha latte while the program is running. When you come back, you will realize that you timed
out of the transaction. Instead of increasing the validity period, it takes the same amount of time
to create a new rebate agreement with reference by clicking the button (see
Figure 9). You can also use the automated rebate agreement renewal transaction “VB(D”.
Figure 13: Rebate Condition Record Detail
Figure 14 shows you our condition record for condition type BO01 for which we wanted to set a
sales goal. The customer needs to buy $100,000 worth of Health Foods (represented by Volume
rebate group “01” of the material master) in order to get an additional 1% rebate. We will always
accrue 1% on all applicable invoices since we don’t know at that time if the customer will reach
that goal. Once we create the final settlement, all applicable sales will be accumulated and
compared with the scale value. If the threshold is not met, nothing will be paid out, but all accrued
values will be reversed.
NOTE: The scale levels are always only applicable to the condition record they were created for.
You can’t comply with a request like: “If you buy $100,000 worth of item A, B and C …,” if A, B
and C are not in some kind of grouping.
Also, since SAP Release 4.5x, you are able to use interval scales, just like in pricing.

www.SAPtips.com
Figure 14: Scale View of Rebate Condition Record
After we have created our rebate agreement, we can check an invoice that has rebate conditions
applied. The service rendered date (not the pricing date!) of the invoice line item is used to
determine the validity of a rebate condition record. All rebate conditions are line item conditions,
so go to the “Conditions” tab of one of your invoice line items.

www.SAPtips.com
You see in Figure 15 that two rebate conditions applied. BO02 for our material promotion with a
$1.00/EA allowance and the 3% of condition type BO03 for everything the customer buys. It is
possible that the same rebate condition type applies several times, unlike regular pricing
conditions. You could for example have a Headquarter rebate that pays 3% of all sales of a payer
(BO03). In addition you have a rebate agreement that pays an additional 1% for a specific sold-to
customer (for example, a new store promotion). This is also set up as a BO03 condition record.
You would see both BO03 records, one with 3% and one with 1%.
Figure 15: Applied Rebate Conditions on an Invoice
Next, select one of the rebate condition types and click on the “Details” button.

www.SAPtips.com
You can see that, although not specified explicitly in the rebate condition type configuration, the
rebate condition is automatically an accrual. The rebate agreement number to which the condition
record belongs to is also shown in the rebates section of this screen (see Figure 16). It is also
indicated if the condition is retroactive or not.
Figure 16: Condition Detail of a Rebate Condition on an Invoice
3) Managing Rebate Agreements and Payments

Verification levels
After several invoices are created, we can access the rebate agreement either in change
(Transaction VBO2) or display mode (VBO3). To see which invoice line items applied, select the
“Verification level” button shown in Figure 10. Items that show accruals of 0 are invoice line
items that applied retroactively. Since the rebate agreement did not exist when they were created,
no accrual could be made. You can drill down to an individual invoice by clicking the invoice
number once. If you would like to change the level of detail shown, select the button
on the “Verification Level” screen shown in Figure 17. Remember that we set the verification level
in customizing the agreement type to “Open”, meaning every line item shows. It might make
sense (if you have thousands of invoice line items and you would like to just see totals by
customer) to select verification level “D”. One annoying thing to note is that the month displayed
is always the calendar month, even if you set up your condition records by your fiscal month. This
can lead to misinterpretation of the data. This issue was addressed with SAP, but the answer was
that the system works as designed and that there are no plans for an enhancement.
As mentioned above, it can happen that the system times out if you are trying to review the
verification level online (due to the large number of applicable invoice line items). In this case, use
transaction “VB(8”, which lets you run a verification report in background.

www.SAPtips.com
Figure 17: Verification Level of a Rebate Agreement
Creating Partial Settlements
As mentioned before, you can automate periodic creation of rebate payments. You need to
decide, based on the number of rebate agreements you have, and their complexity, if this option
makes sense. For example, it makes sense to schedule regular payments for rebates where the
customer gets a certain percentage for everything he buys. However, rebates that check scales
or need manual calculations or adjustments should be handled manually. In this paper, I will
explain how to create manual settlements.

www.SAPtips.com
In order to create any kind of settlement, you need to be in change mode (Transaction VBO2) of
the rebate agreement. Clicking the “Create Manual Rebate Payment” button will open
the partial settlement screen as seen in Figure 18. All condition records of this agreement are
displayed (in our example just one). In the “Max amount” field you see the accrued amount as of
today, which, by our configuration setting, is the maximum amount we are able to pay in a partial
settlement. If we would enter a higher amount, we would get an error. Enter the amount you want
to pay in the “Amt. to be paid” field. Note that the amount you enter always defaults as a negative
amount. Save your changes.
Figure 18: Partial Settlement Amount Screen
An information message is displayed that a partial rebate settlement was created.
NOTE: You cannot create a final settlement until all open settlement requests are posted to
accounting. The reason for that is the actual payments are updated in the rebate agreement only
at accounting time, to determine what is left to pay.

www.SAPtips.com
You can process the settlement request with transaction VA02. You need to release the credit
memo billing block before the request can be invoiced. Looking at the line item pricing screen
(see Figure 19), you see that only the rebate condition type appears, although the same pricing
procedure as the one on the invoice is used. There are two entries. One is to actually credit the
customer with the specified amount, the other one to reverse the accrual. Since we configured
the partial settlement in the agreement type to always reverse the accrual (See Figure 5), the
amounts are always the same in a partial settlement. Save the credit memo request and invoice
it.
If you realize you made a mistake before you invoice the credit memo request, you can delete the
credit memo request with transaction VA02, which will increase the available accrual amount in
the rebate agreement again. In case you already invoiced the settlement, you will need to cancel
the credit memo. Since you then cannot delete the credit memo request, you have to reject all the
line items.
Figure 19: Pricing Screen of Partial Settlement Credit Memo

www.SAPtips.com
Going back to the rebate agreement itself, you can see which settlements were already created
for this agreement. Select Rebate Payments>Rebate Documents and select the type of
document you would like to see. Partial and full settlements can be accessed separately. Since
we only created a partial settlement so far, this is the only option that is available. Click the check
mark and you will see all (in our case just one) partial settlements that were created for this
rebate agreement. Figure 20 shows the settlement amount (what was credited to the customer)
and the reversed accrual amount. If you would like to see the actual credit memo, click on the
invoice number (to select it) and the “Display” button. If you have a credit memo request that
is not invoiced yet, you will see the credit memo request number here. This helps if you try to
determine if you have any “open” settlement documents for this rebate agreement.
Figure 20: Rebate Documents of a Rebate Agreement

www.SAPtips.com
Another view of payment data can be accessed from within the rebate condition record. Go into
the “BO03” condition record for your customer specific rebate and select “Goto-Payment data”.
This view (see Figure 21) shows you the total accrued dollars, how many accrual dollars were
reversed, and how much money was paid to the customer already. In the lower section of the
screen, it is indicated how much accrued money is left to pay out. From here you can also initiate
a partial settlement by entering a payment amount in field “Amount to be paid”, just like we’ve
done in Figure 18. The same check (process) for maximum accrued value occurs here.
Figure 21: Payment Data for a Rebate Condition Record

www.SAPtips.com
Manual Accruals
As I mentioned before, sometimes manual accruals need to be made in order to increase the
accrued amounts for a given condition record. The most likely scenario is when you create a
rebate agreement in the middle of the year, but set it retroactively valid for the whole year. The
system will take previous invoices into consideration, but no accruals for these invoices are
accounted for. If we want to make partial settlements, we would not have accrued as much as we
would like to pay out. So we need to increase the accrual amount by creating a manual accrual.
In order to know how much we need to accrue in addition, click the “Sales volume” button on
the Agreement Overview screen. The resulting screen (see Figure 22) shows the actual eligible
rebate amount (in our example $281.25) and the accrued amount ($102.48). We need to create
an accrual for the difference of $178.77.
Figure 22: Sales Volume Screen of a Rebate Agreement

www.SAPtips.com
This can be accomplished by clicking the button on the Agreement Overview screen.
In the resulting screen (see Figure 23), we can enter the accrual amount. A negative amount will
increase the total accrual amount; a positive amount will decrease it. Save the document and you
will receive the message that a manual accrual has been created. Invoice the credit memo
request to post it to FI. Go back now to the rebate agreement and check the sales volume. You
will see that the accrual amount matches the eligible payout amount.
Figure 23: Manual Accrual Payment Screen

www.SAPtips.com
Correction Documents
Instead of trying to figure out the manual accrual difference, you can also use the correction
document. When you have retroactive documents, billing documents and statistical data (the
accrual amount that is stored in SIS structure S060) might be out-of-sync. To see these
differences, run report RV15B002 (IMG Sales and Distribution>Billing>Rebate
processing>Compare Rebate Basis And Correct Accruals). Enter the agreement number, and
execute. Figure 24 shows that billing documents applied to the agreement in the amount of $450,
but the statistics (S060) only show $300 accrued. Instead of doing a manual accrual, just click on
the button, which will automatically create a “B2” correction document. After
invoicing this credit memo request, the billing document and statistic amounts are equal (see
Figure 25).
Figure 24: Statistics Before the Correction Document
Figure 25: Statistics After the Correction Document

www.SAPtips.com
You will also realize that the accrual amount in the rebate agreement was increased to $450.
Final Settlements
At the end of the rebate agreement, we finally can execute the final settlement to close the
agreement. As defined in the agreement type, we need to manually set the “Agreement status”
field on the Overview screen to “B” (Agreement release for settlement). This is a manual check
that prevents us from accidentally closing the agreement. Then select the
button from the Overview screen. We are using our first rebate agreement, for which we did not
create a manual accrual. Although we only have $500 accrued, the final settlement shows what
the customer is eligible for, including retroactive amounts (see Figure 26). At this point in time,
you could also pay out more than this amount. Nothing will stop you from doing that, but I wonder
what Sarbanes-Oxley would say to that. Make your adjustments and save.
You could also have used the “Create final settlement” button from the rebate agreement
overview screen, which would have created a credit memo request right away, without giving you
the opportunity to manipulate the final payment amount.
After the credit memo request is created, the agreement status is set to “C”, which prevents you
from creating any further settlements out of this rebate agreement.
Figure 26: Final Settlement Payment Screen

www.SAPtips.com
The final settlement credit memo request uses the last day of the agreement validity period as the
billing date. You can create it manually or via the same batch job (RV15C001) with which we can
create periodic partial settlements.
Invoice the credit memo request. Looking at the pricing screen of the credit memo (see Figure
27), you see that the payment amount is higher than the accrual amount, since we can’t reverse
more than what we accrued for. In a case in which we wouldn’t pay out anything (for example if
sales goals were not met), only the accrual amount would be reversed in a final settlement. Once
the credit memo is posted in FI, the agreement status changes to “D”. This effectively closes the
rebate agreement.
Figure 27: Pricing Screen of Final Settlement Credit Memo
After the final settlement is executed, no changes can be made to the rebate agreement
anymore. It can be reviewed in display mode only.
A Few More Tips and Tricks
By now you should have a good understanding of the standard rebate capabilities in SAP. In this
section you will find additional useful information that really didn’t fit into the previous sections.
If a rebate agreement already has invoices applied against it and you want to cancel the
agreement, select “Agreement-Delete” from the Rebate Agreement Overview screen. The
agreement will not be physically deleted, but set to a status of “C”, and it will automatically create
a final settlement credit memo request that will reverse all outstanding accruals. This can also be
done if partial settlements were already processed for this rebate agreement.
If you mark a payer relevant for rebates (see the Prerequisites section at the beginning of this
article) after the agreement was created, you should update the billing index for the invoice
documents that were created since the start date of the rebate agreement. Run report RV15B001

www.SAPtips.com
(accessible through IMG path Sales and Distribution>Billing>Rebate processing>Create Billing
Index).
In case you make changes to rebate relevant sub-totals in the pricing procedure, you need to
recalculate these sub-totals with report RV15B003 (IMG path Sales and
Distribution>Billing>Rebate processing>Recalculate Subtotals For Rebate Processing).
You might have noticed that I mentioned “in standard SAP” several times throughout the
document in regards to limited standard rebate functionality. OSS Note 105681 explains how you
can turn on SAP’s “new” rebate procedure (available since SAP Release 4.5A). In activating SIS
structure S136 (instead of the standard S060), the following features will be turned on:
• Exclusion indicator in rebate access sequences

• Additional fields in pricing procedure (Alternate condition type and Alternate condition base
value)
A great OSS note to supplement this white paper is 75778 (Consulting/troubleshooting for rebate
processing). It gives you an overview of the most common problems in rebate processing and
explains in more details why rebates work in SAP the way they do.
And last but not least, here are some examples of rebate scenarios that cannot be handled by the
standard SAP functionality:
• Apply a rebate condition only if the net price of the item is under $20.00.
• Calculate a rebate for all materials in a material grouping (for example volume rebate group),
except material A and B. In this case I would over-accrue for all items within the volume
rebate group, and, before payment, run a report of sales for the two items that should be
excluded. Calculate the rebate amount for these two items and deduct it from your payment
amount.
• Set up a scale for the sum of a random number of materials that are not grouped together in
a material grouping field.
• Pay customer rebate amount at the beginning of the year and track throughout the year if
they met their sales goal. If not, create a debit memo; otherwise, create additional
settlements.
Conclusion
Although I did my best to cover all features of the standard SAP rebate functionality, I’m sure that
you will have some scenarios that don’t fit in these standard settings. Just remember that SAP is
an integrated standard software and try to utilize it as best as you can. It might also be a good
idea for you to review your more complex rebate scenarios and ask yourself if they can be
simplified. If they are complicated for you, they are, for sure, complicated for your customers.
So, now I’m being treated to a “free lunch” by my client and have to wonder what the catch is.

www.SAPtips.com
Matthias Liebich, MLI Solutions, LLC. Matthias has over 12 years of SAP SD consulting
experience, acquired during numerous full life cycle implementations in the US and Germany. He
is SD certified and has extensive hands-on experience in new implementations, upgrades,
mergers, divestitures, and bolt-on integration. Beyond the core SD functionality, Matthias is an
expert in the areas of Pricing, Contracts, and Rebates. In addition to his cross-module functional
knowledge, he is also proficient in ABAP, enabling him to play a leading role as link between
functional and technical teams. He can be reached at Matthias.Liebich@SAPtips.com.
The information in our publications and on our Website is the copyrighted work of Klee Associates, Inc. and is owned by
Klee Associates, Inc.
NO WARRANTY: This documentation is delivered as is, and Klee Associates, Inc. makes no warranty as to its accuracy
or use. Any use of this documentation is at the risk of the user. Although we make every good faith effort to ensure
accuracy, this document may include technical or other inaccuracies or typographical errors. Klee Associates, Inc.
reserves the right to make changes without prior notice.
NO AFFILIATION: Klee Associates, Inc. and this publication are not affiliated with or endorsed by SAP AG. SAP AG
software referenced on this site is furnished under license agreements between SAP AG and its customers and can be
used only within the terms of such agreements. SAP AG and mySAP are registered trademarks of SAP AG.
All other company and product names used herein may be trademarks or registered trademarks of their respective
owners.

www.SAPtips.com

How To Efficiently Set Up and Manage Your Rebate Programs: Rebate Processing in SAP

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How To Efficiently Set Up and Manage Your Rebate Programs: Rebate Processing in SAP

Uploaded by

Copyright:

Available Formats

Rebate Processing in SAP:

How to Efficiently Set Up and Manage

Copyright © 2005 by Klee Associates, Inc. Page 1

Copyright © 2005 by Klee Associates, Inc. Page 2

Figure 1: Access Sequence for Rebates

Copyright © 2005 by Klee Associates, Inc. Page 3

Figure 2: Condition Tables in a Rebate Access Sequence

Copyright © 2005 by Klee Associates, Inc. Page 4

Figure 3: Rebate Condition Type Definition

Copyright © 2005 by Klee Associates, Inc. Page 5

Figure 4: Rebate Conditions in a Pricing Procedure

Configuring the Rebate Agreement

All field references in this section are made in regards to Figure 5.

Copyright © 2005 by Klee Associates, Inc. Page 6

Copyright © 2005 by Klee Associates, Inc. Page 7

Figure 5: Definition of a Rebate Agreement

Condition Type Groups

Copyright © 2005 by Klee Associates, Inc. Page 8

Figure 6: Definition of Condition Type Groups

Assigning Condition Types to Condition Type Groups

In this configuration step (IMG Sales and Distribution>Billing>Rebate processing>Rebate

Copyright © 2005 by Klee Associates, Inc. Page 9

Figure 7: Assigning Rebate Conditions to Condition Type Groups

Assignment of Condition Type Groups to Rebate Agreement Types

Copyright © 2005 by Klee Associates, Inc. Page 10

Figure 8: Assignment of Condition Type Groups to Rebate Agreement Types

2) Setting Up Rebate Agreements

• Define the payment method and validity of the rebate agreement.

Copyright © 2005 by Klee Associates, Inc. Page 11

Figure 9: Entering a Rebate Agreement

Copyright © 2005 by Klee Associates, Inc. Page 12

Figure 10: Rebate Agreement Overview Screen

Copyright © 2005 by Klee Associates, Inc. Page 13

Figure 11: Available Condition Types in a Rebate Agreement

Copyright © 2005 by Klee Associates, Inc. Page 14

Figure 12: Rebate Pricing Record Rates

Select the condition record and click on the “Details” button.

Copyright © 2005 by Klee Associates, Inc. Page 15

Figure 13: Rebate Condition Record Detail

Copyright © 2005 by Klee Associates, Inc. Page 16

Figure 14: Scale View of Rebate Condition Record

Copyright © 2005 by Klee Associates, Inc. Page 17

Figure 15: Applied Rebate Conditions on an Invoice

Copyright © 2005 by Klee Associates, Inc. Page 18

Figure 16: Condition Detail of a Rebate Condition on an Invoice

3) Managing Rebate Agreements and Payments

Copyright © 2005 by Klee Associates, Inc. Page 19

Figure 17: Verification Level of a Rebate Agreement

Creating Partial Settlements

Copyright © 2005 by Klee Associates, Inc. Page 20

Figure 18: Partial Settlement Amount Screen

An information message is displayed that a partial rebate settlement was created.

Copyright © 2005 by Klee Associates, Inc. Page 21

Figure 19: Pricing Screen of Partial Settlement Credit Memo

Copyright © 2005 by Klee Associates, Inc. Page 22

Figure 20: Rebate Documents of a Rebate Agreement

Copyright © 2005 by Klee Associates, Inc. Page 23

Figure 21: Payment Data for a Rebate Condition Record

Copyright © 2005 by Klee Associates, Inc. Page 24

Figure 22: Sales Volume Screen of a Rebate Agreement

Copyright © 2005 by Klee Associates, Inc. Page 25

Figure 23: Manual Accrual Payment Screen

Copyright © 2005 by Klee Associates, Inc. Page 26