REBATES

Rebates functionality in SAP uses the concept of condition technique as is used

in Pricing (but with rebate specific features), which is explained below:
Let’s see how rebates work in SAP first.
• Glen wants to give customer a 3% discount on everything he or she buys (conditio
n type ZB03).
• In addition, Glen provides another 1% discount if the customer reaches a certain
amount of gross sales for the year which (turnover discount), for a specific gr
oup of products (ZB01).
After all these rebates are set up, the rebate conditions will apply on applicab
le invoices as accruals instead of off-invoice discounts. The rebate agreement t
racks the applied amounts, which can be reviewed at anytime in the rebate agreem
ent. Once pay out of any rebate amount to the customer is decided, there will be
a rebate settlement represented by a credit memo request. This reverses accrued
amounts and pays the actual amount to the customer either in form of a check or
a credit memo.
Rebate process in SAP is separated into three components:
1) Configuring Rebates
2) Setting up the Rebate Agreements
3) Managing Rebate Agreements and Payments
1) Configuring Rebates
Prerequisites
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 Distri
bution>Billing>Rebate processing>Activate Rebate Processing>Select billing docum
ents 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 rebat
e processing for sales organizations).
The system will issue respective messages when you are trying to process any reb
ate-related transactions with any of these settings missing.

Condition Technique for Rebates

To create rebate-related access sequences
IMG path Sales and Distribution Billing Rebate processing Condition technique for reba
te processing>Maintain access sequences.

Access Sequence for Rebates

Condition Tables in a Rebate Access Sequence

Rebate-related condition types are identified by condition class “C” (Expense Reimbu
rsement). When you create a new rebate condition type (IMG path Sales and Distri
bution>Billing>Rebate processing>Condition technique for rebate processing>Defin
e condition types) and you change the class to “C
If the “Rebate proc.” field is blank, accruals will be posted on each applicable inv
oice. 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 gi
ve the customer a $5000 rebate if he displays your product at the entrance of hi
s 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.

Rebate Condition Type Definition

Now that we defined our rebate conditions, we can add them to our regular pricin
g procedure (IMG path Sales and Distribution>Billing-Rebate processing>Condition
technique for rebate processing>Maintain Pricing Procedures. Alternate conditio
n type “AltCTy” and Alternate condition base value “AltCBV” will not let you do any mani
pulations 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 ta
ke 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 t
he account keys. At Invoice creation, accruals are being created that post to ac
counting, 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 doc
ument (in form of a credit memo) uses the accounts assigned to the account key i
n column ‘ActKy’ (Account key), which reverse the accrued amounts and credits the cu
stomer.
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 BO
NBA in column “SubTo”). If you are using multiple pricing procedures, you want to ke
ep the sub-total designations common (i.e., 1 for gross price, 2 for net price).

Rebate Conditions in a Pricing Procedure

Configuring the Rebate Agreement

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.
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 da
te of the agreement. The default start date is important in regards to whether o
r not you want to allow retroactive rebates. For example, if you set the start d
ate of a rebate agreement to today’s date, all invoices from that moment on are el
igible for the rebate and will apply on the invoice itself. However, if your def
ault 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 f
reely 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 che
ck, it will carry this flag forward to FI, to later let you cut a check. Of cour
se, all of these defaults can be overwritten during creation of the actual rebat
e agreement.

Control data
The “Condition type group” is linked to the rebate agreement type in a different con
figuration transaction, which we will get into a little bit later. This conditio
n type group defines which rebate condition types are allowed for the rebate agr
eement type.
The “Verification levels” field is also a default that defines the level of detail y
ou see when you review the applied invoices within a rebate agreement. You can c
hange this default while reviewing the verification level in the rebate agreemen
t.
The “Different val. period” option lets you define whether or not the rebate conditi
on records you create out of the rebate agreement can have validity dates outsid
e 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 interv
als 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 cale
ndar, or your own defined one, to schedule the automatic creation of rebate agre
ements. In a separate step, schedule job RV15C005, which can also be accessed vi
a transaction “VB(D” (yes, that’s the left parenthesis in the transaction code), to au
tomatically extend your agreements.
Manual payment
The “Manual payment” section of the rebate agreement defines how much can be paid ou
t 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 a
mount, 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 (access
ible through transaction “VB(7”) to schedule your payment runs. This will create aut
omatic 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 cu
stomer did not reach their sales goal, you might want to pay only half that amou
nt or nothing at all. No matter what the payment amount is going to be, the tota
l 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 final
ly be settled. This will become more clear when we cover the actual settlement o
f a rebate agreement later in this paper.
The standard correction order type “B2” is needed if the statistical and actual accr
ual amounts are getting out of sync. This is mostly the case for retroactive reb
ates.

Definition of a Rebate Agreement

Condition Type Groups

I mentioned the assigned condition type group in the definition of the rebate ag
reement. With IMG menu path Sales and Distribution>Billing>Rebate processing>Reb
ate agreements>Condition type groups>Define condition type groups, you can freel
y define your rebate condition type group (see Figure 6). Make sure that you lea
ve the “Cat.” (Category) field blank. This defines the Condition Type Group as relev
ant for rebates. Sales deals share this configuration transaction and would be i
dentified with a category of “A”.

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 Condit
ion Type Groups), you define which condition tables, of which rebate condition t
ypes, you allow for a specific Condition Type Group, and in which order they app
ear in the rebate agreement (see Figure 7). Since the standard SAP rebate functi
onality 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.

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 Ty
pe through the IMG menu path Sales and Distributions>Billing>Rebate Processing>R
ebate Agreements>Condition Type Groups>Assign Condition Type Groups to Rebate Ag
reement Types

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 m
ain 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 appl
y. NOTE: You cannot create rebate condition records with the regular pricing tra
nsaction VK11 or VK31. (This is due to the condition class of “C” as indicated in th
e 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 er
ror. The reason for this is the same as the one for the condition types. In orde
r to track all payments within the rebate agreement, they have to originate from
that rebate agreement.

To create a rebate agreement execute transaction VBO1

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 p
ayment 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 ac
count group you are using for the sold-to (“0001” in standard SAP). As we can see la
ter, the rebate recipient becomes the sold-to in the rebate settlement credit me
mos.
The payment method defaults from the rebate agreement type configuration setting
and can be overwritten here. The same applies to the validity period. Originall
y 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 informa
tion, we need to back-date the start date to the first of the year. We assume th
at 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 ‘Conditions’ button to create rebate condition records.

Rebate Agreement Overview Screen

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 pe
riod) would result in an error. However, you can change the validity period to o
ne within the range of the agreement period. For example, if you set up the agre
ement for the whole year and you pay out on a monthly basis with different amoun
ts, it makes sense to create multiple condition records with monthly validity da
tes.
If you enter a rate in Figure 12 and hit Enter, the same amount applies in the “Ac
cruals” 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 i
nvoices. This becomes very clear when you are using scales. Although you are abl
e to maintain different rates based on different scale levels of sales achieveme
nts, you can only maintain one accrual rate.
The accrual rate applies on each invoice, at which time you don’t know if a custom
er will reach the next scale level over the time of the agreement. You might wan
t 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 you
r 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 payme
nt) and can take out the accrual rate entry. However, if you are trying to creat
e 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
.

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), y
ou 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 materi
al 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 combinat
ion 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 materi
als 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 de
faults 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 reb
ate 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 di
fferent condition types to be maintained within agreement type “ZSRB”, it does not m
ean 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 a
ll the items a customer purchases throughout the duration of the rebate, a secon
d can be created for the performance based (scale). and a third agreement for th
e material promotion.

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 p
erformance 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 agreem
ents (for example, yearly renewals), clients just extend the validity end date o
f the agreement. The problem with that scenario is that when you want to look on
line to see which invoice line items applied to the rebate, the system has to lo
ok back at two or more years worth of data. Get your mocha latte while the progr
am is running. When you come back, you will realize that you timed out of the tr
ansaction. Instead of increasing the validity period, it takes the same amount o
f time to create a new rebate agreement with reference by clicking the button (s
ee Figure 9). You can also use the automated rebate agreement renewal transactio
n “VB(D”.

Rebate Condition Record Detail

Figure 14 shows you our condition record for condition type BO01 for which we wa
nted to set a sales goal. The customer needs to buy $100,000 worth of Health Foo
ds (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 sin
ce 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 wit
h the scale value. If the threshold is not met, nothing will be paid out, but al
l accrued values will be reversed.
NOTE: The scale levels are always only applicable to the condition record they w
ere 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.

Scale View of Rebate Condition Record

After we have created our rebate agreement, we can check an invoice that has reb
ate 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 recor
d. All rebate conditions are line item conditions, so go to the “Conditions” tab of
one of your invoice line items.

You see in Figure 15 that two rebate conditions applied. BO02 for our material p
romotion with a $1.00/EA allowance and the 3% of condition type BO03 for everyth
ing the customer buys. It is possible that the same rebate condition type applie
s 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 custo
mer (for example, a new store promotion). This is also set up as a BO03 conditio
n record. You would see both BO03 records, one with 3% and one with 1%.

Applied Rebate Conditions on an Invoice

Next, select one of the rebate condition types and click on the “Details” button.
You can see that, although not specified explicitly in the rebate condition type
configuration, the rebate condition is automatically an accrual. The rebate agr
eement number to which the condition record belongs to is also shown in the reba
tes section of this screen (see Figure 16). It is also indicated if the conditio
n is retroactive or not.

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 ite
ms applied, select the “Verification level” button shown in Figure 10. Items that sh
ow accruals of 0 are invoice line items that applied retroactively. Since the re
bate agreement did not exist when they were created, no accrual could be made. Y
ou 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 “V
erification Level” screen shown in Figure 17. Remember that we set the verificatio
n 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 l
ike to just see totals by customer) to select verification level “D”. One annoying t
hing to note is that the month displayed is always the calendar month, even if y
ou set up your condition records by your fiscal month. This can lead to misinter
pretation of the data. This issue was addressed with SAP, but the answer was tha
t 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 inv
oice line items). In this case, use transaction “VB(8”, which lets you run a verific
ation report in background

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 com
plexity, if this option makes sense. For example, it makes sense to schedule reg
ular payments for rebates where the customer gets a certain percentage for every
thing 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 cr
eate manual settlements.

In order to create any kind of settlement, you need to be in change mode (Transa
ction VBO2) of the rebate agreement. Clicking the ‘Pay’ “Create Manual Rebate Payment” b
utton will open the partial settlement screen as seen in Figure 18. All conditio
n records of this agreement are displayed (in our example just one). In the “Max a
mount” field you see the accrued amount as of today, which, by our configuration s
etting, 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.

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 ar
e posted to accounting. The reason for that is the actual payments are updated i
n the rebate agreement only at accounting time, to determine what is left to pay
.

You can process the settlement request with transaction VA02. You need to releas
e the credit memo billing block before the request can be invoiced. Looking at t
he line item pricing screen (see Figure 19), you see that only the rebate condit
ion 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 Figu
re 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, yo
u 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.

Pricing Screen of Partial Settlement Credit Memo

Going back to the rebate agreement itself, you can see which settlements were al
ready created for this agreement. Select Rebate Payments>Rebate Documents and se
lect the type of document you would like to see. Partial and full settlements ca
n be accessed separately. Since we only created a partial settlement so far, thi
s is the only option that is available. Click the check mark and you will see al
l (in our case just one) partial settlements that were created for this rebate a
greement. Figure 20 shows the settlement amount (what was credited to the custom
er) 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 ha
ve 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” settl
ement documents for this rebate agreement.
Rebate Documents of a Rebate Agreement
Another view of payment data can be accessed from within the rebate condition re
cord. Go into the “BO03” condition record for your customer specific rebate and sele
ct “Goto-Payment data”. This view (see Figure 21) shows you the total accrued dollar
s, how many accrual dollars were reversed, and how much money was paid to the cu
stomer already. In the lower section of the screen, it is indicated how much acc
rued money is left to pay out. From here you can also initiate a partial settlem
ent 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.
Payment Data for a Rebate Condition Record
Manual Accruals
As I mentioned before, sometimes manual accruals need to be made in order to inc
rease 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 ret
roactively 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 accr
ual. In order to know how much we need to accrue in addition, click the “Sales vol
ume” 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 accrue
d amount ($102.48). We need to create an accrual for the difference of $178.77.

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 ne
gative amount will increase the total accrual amount; a positive amount will dec
rease it. Save the document and you will receive the message that a manual accru
al has been created. Invoice the credit memo request to post it to FI. Go back n
ow to the rebate agreement and check the sales volume. You will see that the acc
rual amount matches the eligible payout amount.

Manual Accrual Payment Screen

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 se
t the “Agreement status” field on the Overview screen to “B” (Agreement release for sett
lement). This is a manual check that prevents us from accidentally closing the a
greement. Then select the button from the Overview screen. We are using our firs
t rebate agreement, for which we did not create a manual accrual. Although we on
ly have $500 accrued, the final settlement shows what the customer is eligible f
or, including retroactive amounts (see Figure 26). At this point in time, you co
uld also pay out more than this amount. Nothing will stop you from doing that, b
ut I wonder what Sarbanes-Oxley would say to that. Make your adjustments and sav
e.
You could also have used the “Create final settlement” button from the rebate agreem
ent 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.
Final Settlement Payment Screen
The final settlement credit memo request uses the last day of the agreement vali
dity period as the billing date. You can create it manually or via the same batc
h job (RV15C001) with which we can create periodic partial settlements.
Invoice the credit memo request. Looking at the pricing screen of the credit mem
o (see Figure 27), you see that the payment amount is higher than the accrual am
ount, 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 accr
ual amount would be reversed in a final settlement. Once the credit memo is post
ed in FI, the agreement status changes to “D”. This effectively closes the rebate ag
reement.

Pricing Screen of Final Settlement Credit Memo

After the final settlement is executed, no changes can be made to the rebate agr
eement anymore. It can be reviewed in display mode only.