Table Of Contents

1...............................................................................................................INTRODUCTION
........................................................................................................................................4

PROCESSING OF REBATES.................................................................................................4
REBATE SETTLEMENT........................................................................................................4

2...................................................................PRE-REQUISITES FOR REBATE PROCESSING

........................................................................................................................................5

3......................................................................................................REBATE PROCESSING
........................................................................................................................................7

3.1 CREATING A REBATE AGREEMENT - ELEMENTS OF REBATE PROCESSING................................8

3.2 REBATE AGREEMENT TYPE...........................................................................................8
3.3 REBATE CONDITION RECORDS......................................................................................9
3.4 ACCRUALS................................................................................................................9
3.5 MANUAL ACCRUAL......................................................................................................9
3.6 ACCESS SEQUENCE...................................................................................................10
3.7 MATERIALS FOR SETTLEMENT.....................................................................................10
3.8 STEPS TO CREATE A REBATE AGREEMENT.....................................................................10
3.9 STEPS TO EXECUTE A REBATE AGREEMENT....................................................................10

4................................................................................................SETTLEMENT OF REBATES
......................................................................................................................................11

4.1 AGREEMENT STATUS:................................................................................................11

4.2 FINAL SETTLEMENT:.................................................................................................11
4.3 PARTIAL SETTLEMENT:..............................................................................................12
4.4 PERIODIC PARTIAL SETTLEMENT.................................................................................12

5...............................................................................................ACCOUNTING OF REBATES
......................................................................................................................................13

5.3 HOW THE ACCOUNTS ARE PICKED?.............................................................................13

5.4 ACCOUNTING TRANSACTIONS:....................................................................................14
6................................................................................................REBATE CONFIGURATION
......................................................................................................................................15

6.1 DEFINE AGREEMENT TYPES........................................................................................15

6.2 DEFINE CONDITION TYPE GROUPS FOR REBATES...........................................................15
6.3 ASSIGN CONDITION TYPE /TABLES TO CONDITION TYPE GROUPS.....................................16
6.4 ASSIGN CONDITION TYPE GROUPS AND AGREEMENT TYPES.............................................16
6.5 DEFINE NUMBER RANGES FOR REBATE AGREEMENTS.......................................................16
6.6 CONDITION TECHNIQUE FOR REBATE PROCESSING.........................................................17
6.7 ACCOUNT DETERMINATION FOR REBATES......................................................................17
6.8 ACTIVATE REBATE PROCESSING..................................................................................18
6.9 DEFINE REBATE GROUPS...........................................................................................18
6.10 RECALCULATE SUBTOTALS FOR REBATE PROCESSING.....................................................19
6.11 CREATE REBATE PROCESSING INDEX..........................................................................19
6.11 COMPARE REBATE BASIS.........................................................................................19

7...................................................................................................ADDITIONAL FEATURES
......................................................................................................................................20

7.1. ..........................................................................................RETROACTIVE AGREEMENTS

..................................................................................................................................20
7.2. ..................................................................................................LUMP SUM PAYMENTS
..................................................................................................................................20
7.3...............................................................................................................DELETING RA
..................................................................................................................................21
7.4................................................................................................................LONG TEXTS
..................................................................................................................................21
7.5...........................................................................................ARCHIVING OF AGREEMENTS
..................................................................................................................................21

Appendices

APPENDIX A: GLOSSARY................................................................................................22

APPENDIX B: FREQUENTLY USED TRANSACTION CODES (FUTC)....................................23

APPENDIX C: REBATE TABLES........................................................................................24

APPENDIX D: REBATE PROGRAMS.................................................................................24

APPENDIX E: CLIENT JAPAN EXPERIENCE.....................................................................25

E1. AGREEMENT TYPES:.............................................................................................25

E2. REPORTS:............................................................................................................26
E3. SCENARIOS:........................................................................................................27
...............E3.1 Discrepancy Found After Issuing The "Rebate Credit Memo" To The
Customer...............................................................................................................27
 .............................................E3.2 Max-Min Goals (Overview Of Condition Records)
.............................................................................................................................27
........................................................................E3.3 Retroactive Rebate Agreement
.............................................................................................................................27

APPENDIX F: FEW DEMONSTRATIONS...........................................................................29

F1: REBATE ACCOUNTING..........................................................................................29

F2. AUTOMATIC ALLOCATION OF TEXT USING STANDARD TEXT
FUNCTIONALITY........................................................................................................37
F3. EFFECT OF RETURNS IN REBATE AGREEMENTS.............................................................40

Index of Figures

FIGURE 1. REBATE PROCESSING AND SETTLEMENT PROCESSING OVERVIEW

1. INTRODUCTION

A rebate is a special discount/deferred discount which is paid

subsequently to a customer. This means that the discount is not
given at the time of placing the order but given after sometime. This
discount is based on the customer's sales volume over a specified
time period.

To give rebates you have to create a REBATE AGREEMENT. In the

agreement you specify the following information

 who receives the rebate payment (Rebate Recipient)

 method of payment for rebate settlement (credit memo or
check)
 how long the rebate agreement is valid (validity period)
 name of the marketing scheme that this rebate agreement is
for (External Description
 condition records that are part of this agreement (customers,
customer hierarchy; materials, grouping of materials;
payment rate and the accrual rate)

Some rebate agreements have rebate conditions that are

independent of sales volume (that is the customer doesn’t have to
purchase any products to be eligible for the rebate). These are
known as performance based, independent of sales volume, or
“lump sum” rebates

PROCESSING OF REBATES is much the same way as other kinds

of pricing elements. Rebate data is saved in condition records.
Controlling for rebate processing is carried out via condition types,
pricing procedures and access sequences.
You can set up rebates at any level just like pricing. The following
rebates have been set up in the standard version of the SAP R/3
system:

 Rebate based on a material

 Rebate based on a customer
 Rebate based on a customer hierarchy
 Rebate based on a group of materials

Because rebates are always paid subsequently, the system keeps

track of all billing documents (invoices, credit and debit memos) that
are relevant for rebate processing.

The system can, if you wish, automatically post accruals so that the
accumulated value of a rebate is recorded for accounting purposes.
The accrual is posted to the financial accounts at the time of billing.
If the condition is independent of sales volume, all accruals are
entered manually.

REBATE SETTLEMENT is finally done when you issue a credit memo

to the customer for the accumulated rebate total. Settlement can be
partial or final. A partial settlement allows you to make a payment to
a customer and leave the rebate agreement active. A final settlement
will issue a payment and end the rebate agreement

2. PRE-REQUISITES FOR REBATE PROCESSING

You can process rebate agreements when the following prerequisite

conditions are met:
1. The sales organization in which you are processing sales
orders must be relevant for rebate processing.

Menu Path: SPRO->Enterprise Structure->Definition->Sales

and Distribution-> Define Sales Organization

OR,

Menu Path: SPRO->Sales and Distribution-> Billing->Rebate

Processing->Activate Rebate Processing->Activate Rebate
Processing for sales organizations

2. The payer must be relevant for rebate processing. In some

cases, the payer is different from Rebate Recipient. You
indicate whether a customer can receive rebates by marking
the Rebates field in the Billing view of the customer master
record.
 A PAYER/REBATE RECIPIENT can have more than one sold-to
customers associated with it.
When a customer is marked as relevant for rebate processing,
an internal SAP index called VBOX will track every invoice for
relevant materials for that customer.
3. The billing type (invoice, credit memo, and so on) you are
using must be relevant for rebate processing.

Menu Path: SPRO->Sales and Distribution-> Billing->Billing

Documents->Define Billing Types

OR,

Menu Path: SPRO->Sales and Distribution-> Billing->Rebate

Processing->Activate Rebate Processing->Select Billing
Documents for Rebate Processing

Some of the billing types relevant for rebates are as follows:

Billin Description
g
Type
B1 Rebate Credit Memo (Final
Settlement)
B2 Rebate Correction
B3 Rebate Partial Settlement
B4 Rebate Manual Accruals
F2 Invoice
G1 Credit Memo
G2 Credit Memo
L1 Debit Memo
L2 Debit Memo
RE Credit for Returns
S1 Cancellation of Inv
S2 Cancel of Credit Memo
S3 Cancellation of Inv

This is not the complete list.

3. REBATE PROCESSING

There are two basic phases in SAP’s rebate functionality:

i. Establishing and Maintaining the Rebate agreement, and

ii. Settling (payment) the agreement

The complete rebate processing is illustrated below:

 Figure 1: Rebate Processing and Settlement Processing
Overview

Rebate processing begins by creating a rebate relevant billing

document. The processing ends with the Updation of rebate basis and
accrual amount in the rebate agreement.

Settlement processing begins by creating a payment (partial or final).

The processing ends with crediting the rebate recipient.

3.1 CREATING A REBATE AGREEMENT - ELEMENTS OF

REBATE PROCESSING

1. Organizational data is proposed – SORG, DC, Div

2. Rebate Agreement Type
3. Condition Records ----- Elements of condition technique and
associated features (Condition records, Condition types,
Access sequence, Pricing procedure; Scales etc)
4. Accruals
5. Materials for Settlement

The two components of rebates are:

1. WHO ACCRUES?
This is determined by the condition records

2. WHO IS PAID?
This is determined by the rebate agreement
3.2 REBATE AGREEMENT TYPE

When you first create a rebate agreement, the system prompts you
to specify a rebate agreement type. The rebate agreement type
you specify determines which data the system automatically
proposes for the corresponding rebate agreement. For example, the
system can propose
 which condition types you can use in an agreement
 which validity period the system automatically proposes for an
agreement
 which status is required before an agreement can be
processed for payment.
 which rebate agreement types are defined in Customizing for
Sales and Distribution.

Agreement Types in the Standard Version

The standard version of the SAP R/3 System includes the following
rebate agreement
Types (the table also shows the corresponding condition types):

Agreement Basis of rebate condition

type type
0001 Customer/material (% BO01
rebate)
  Customer/rebate BO01
group(% rebate)
0002 Customer/material BO02
(quantity dependent)
0003 Customer (% rebate) BO03
0004 Customer hierarchy (% BO04
rebate)
  Cust. hierarchy/material BO05
(% rebate)
0005 Sales volume BO06
independent

Hence, the rebate agreement type determines the condition records

and the access sequences available.

3.3 REBATE CONDITION RECORDS

A rebate condition record allows you to store and retrieve information

regarding how a rebate accrues. The condition records are created in
the rebate agreement specifying the following:
a. Rebate rate, b. Accrual rate, c. Validity period, d. Scales
3.4 ACCRUALS

Rebate accruals allow your accounting department to keep track of

how much your company owes customers with whom you have
rebate agreements. Rebates accumulates using the accrual rate

You can enter Example

accrual rates based on accrual rate USD 2.00 for

sales volume every 10 pieces the
customer buys from you

accruals not based on lump sum payment of USD

sales volume 5000 for front of store
display

The accrual rate can be based on ‘total sales volume’ or ‘each units
sold’. You can enter an accrual rate manually in each condition
record.

Every time you process a rebate-relevant billing document (an

invoice, a credit or debit memo), the system automatically posts an
accrual to financial accounting (FI).

Within FI, the rebate accrual is posted to two accounts:

Debit: sales deduction account

Credit: accrual account.

The accrual account is cleared when the rebate agreement is settled

with a credit memo.

3.5 MANUAL ACCRUAL

Mostly, manual accruals are used in the Independent of Sales Volume

agreement type. But, it can be used in any of the agreement types
where the configuration of the agreement type allows it.

To create a manual accrual within the rebate agreement, go to the

step:
GO TO – Manual Accruals

Here, all the applicable conditions will be shown and you can enter
the amount to be accrued. The sign on the 'amount of money to
accrue' indicates whether it’s a regular accrual (NEGATIVE sign) or a
reverse accrual (POSITIVE sign). After saving the agreement, credit
memo request will get created. Then, go to VF01 and create the
rebate credit memo and post to accounting.
3.6 ACCESS SEQUENCE

The access sequences are the combination of customers and/or

materials that are eligible for rebates. For example:
 Customer/Material
 Customer/Volume Rebate Group

3.7 MATERIALS FOR SETTLEMENT

When condition records are established in a rebate agreement at a

material group level (e.g. volume rebate group, material group3
etc.), then you must provide a ‘Material for Settlement’. This material
is used whenever settlement (payment) is made. That is, the
material for settlement determines what product the rebate is
charged to.

Material for settlement is also used for independent of sales volume

rebate agreement type.

3.8 STEPS TO CREATE A REBATE AGREEMENT

1. Go to VBO1 (Alphabet ‘O’) and select the agreement type

2. Check the organizational data
3. Enter the customer who will receive the rebate (Rebate
Recipient)
4. Enter currency and payment method (usually blank)
5. Enter the External Description (which is usually the scheme
name or the program name)
6. Change the validity dates, if necessary. This will be defaulted
from the customizing settings
7. Status of the agreement is ‘OPEN’ and the verification level
will be defaulted from the customizing settings
8. Enter the condition information. For all rebate agreements
except independent of sales volume, a payable rate and an
accrual rate is entered.
9. If the condition does not include a material, then the material
for settlement has to be specified.
10.Save the agreement

3.9 STEPS TO EXECUTE A REBATE AGREEMENT

1. Create a sales order that meets the conditions in the rebate

agreement. If the requirement 24 is put in all the rebate
condition types in the pricing procedure, then the conditions
will be ignored in the sales order
2. Deliver the order
3. Create the billing document. The rebate condition should be
present for the appropriate line items. The rebate agreement
will be updated ONLY when the billing document is posted to
accounting. Automatic accrual will happen when the
accounting document is generated.
 4. Settlement can be initiated after the billing documents are
posted to accounting (Explained in detail below)

Rebates are completely integrated with other parts of the sales and
distribution module. Other transactions such as product returns will
influence agreement accruals. If product is returned by a customer
the system will adjust the accruals based on any open rebate
agreements.
 4. SETTLEMENT OF REBATES

The system uses the services rendered date (which is the billing
date, if the products are shipped) to determine whether a billing
document qualifies for rebate processing. To qualify, the date must
fall within the validity period of one or more rebate agreements.

Since it is possible for the billing date to be later than the services
rendered date, some time should be allowed after the end of a rebate
agreement's validity period before final processing of the rebate
agreements. If the volume of the sales rebate processing is high,
rebate settlements can be collectively processed as a background
task.

There are two types of rebate settlements – partial or final

Settlements are mainly carried out in three ways – a. manually, b.
automatically, c. Background

4.1 AGREEMENT STATUS:

Settlement is controlled by the “status” in the agreement screen.

Following are the different types of status possible in rebates:

(blank) Open
A Settlement is being checked manually for release
B Agreement released for settlement
A rebate must have a status of B to be final settled.
C Settlement has been created
Once the rebate is settled, the system will automatically
change the rebate status to C. A rebate status of C means
that the credit memo request has been generated.
The rebate can be changed up to this point.
A rebate with a status of C will change to a D status after the
credit memo has been created along with its accounting
document.
D Final settlement of agreement already carried out
A rebate with a status of D cannot be changed.
SAP considers rebates with a status of D completed and
closed.

4.2 FINAL SETTLEMENT:

The system automatically

 calculates the rebate based on the sales volume statistics or
the lump sum
 deducts any previously paid rebates
It then creates a credit memo request, and proposes the end date of
the agreement validity period as the billing date.

The system also reverses any accruals that have been posted.

4.3 PARTIAL SETTLEMENT:

The amount to be paid can be limited in Customizing for Sales.

Payments can be:
 limited to the cumulative accruals of the condition record
 limited to the amount that would be paid if final settlement
were presently carried out
 unlimited

The system will automatically create a credit memo request for the
amounts specified.
It will also reverse the accruals with the credit memo if the rebate
agreement type is configured accordingly.

The system always takes open documents into account when

determining the maximum amount which you can pay.

When the system carries out final settlement for a rebate agreement,
it takes all partial payments into account.

4.4 PERIODIC PARTIAL SETTLEMENT

In Customizing, assign a settlement period to the rebate agreement

type. Only the amount accumulated up to the settlement date is
taken into account.

Depending on Customizing, when the system creates a credit memo

request, the document is automatically blocked for billing.

5. ACCOUNTING OF REBATES

There are two processes where the accounting entries get generated.
They are ACCRUAL and PAYMENT. The accrual is posted to the
financial accounts at the time of billing. If the condition is
independent of sales volume, all accruals are entered manually.
These accruals may be interfaced to COPA for profitability.
Rebates are settled using a partial (also known as manual payment)
or final settlement. Partial payments may be made during the life of
the agreement. These may be limited to maximum of what has been
accrued so far or they may have no restrictions. Final settlement of
the agreement results in a credit to the customer and the end of the
agreement.

The account determination for rebates involves two account keys.

They are for
1. accrual postings
ERU is for accruals and points to two accounts. The first
account is the G/L accrual and the second account is the
rebate expense account. It should be assigned as the
ACCRUAL ACCOUNT KEY.

1. revenue postings
ERB is the revenue account for credit used only in the rebate
credit note. It should be assigned as the NORMAL
ACCOUNT KEY.

During the order to cash cycle, when a customer is billed, any related
rebate accruals are entered into an “expected” set of G/L accounts;
one is a reduction from revenue account, the other is an accrual
account. Manual accruals will also hit these accounts.

When a payment is made to a customer these accounts are reversed

and the “actual” revenue reduction is placed in another G/L account.
This is the actual amount that revenue is reduced by. That is, during
final settlement, the system uses the ERU accounts in order to
reverse the accruals originally posted. The expense accounts
specified in ERU and ERB can be different if there is a requirement to
post ‘expected’ rebate expenses and ‘actual’ rebate expenses to
separate accounts.

5.3 HOW THE ACCOUNTS ARE PICKED?

The Pricing Procedure (as shown below) contains a step for each
condition type in use. The conditions are placed before tax conditions
and be from a step that is the rebate basis. The rebate basis is a
single step in the pricing procedure that is the amount from which
the rebate is calculated. This rebate basis is given a sub-total value
of ‘7’ and this sub-total controls whether and in which fields
condition amounts are stored. The sub-total ‘7’ carries over the value
to KOMP_BONBA
The normal account key and the accrual account key is linked each of
the condition type to be used.

G/L accounts are attached to these account keys, which gets

determined automatically during billing using ‘Account Determination’
functionality in SAP.

5.4 ACCOUNTING TRANSACTIONS:

Following are the transactions which involves the posting of

accounting entries for the rebate processing:
1. Automatic Accrual (F2)
2. Manual Payment (Partial Payment) (B3)
3. Final Settlement (B1)
i. Automatic Payment
ii. Using Payment Screen
2. Manual Accrual (B4)
3. Correct Statistics (Retroactive Rebate Agreements) (B2)
 6. REBATE CONFIGURATION

6.1 DEFINE AGREEMENT TYPES

New agreement types are created and existing agreement types are
changed in this customizing option. This option is used to do
configure what are the default values which should appear while
creating the rebate agreement type using VBO1 like validity dates,
payment method, status etc. Manual payments allowed or not and
the settlement criteria are fixed here. The condition type group is set
in another configuration table but displayed here.

6.2 DEFINE CONDITION TYPE GROUPS FOR REBATES

The condition type group is the link between the agreement type and
condition types and tables. The condition type groups are defined
here.
6.3 ASSIGN CONDITION TYPE /TABLES TO CONDITION
TYPE GROUPS

The condition type groups are assigned to the condition types and
the tables in this customizing option. The ‘CNTR’ determines the
sequence in which they will appear in the rebate agreement.

** There is no exclusive indicator for rebate access sequences

Sales volume applies to all conditions

6.4 ASSIGN CONDITION TYPE GROUPS AND AGREEMENT

TYPES

Here the agreement types are assigned to the condition type groups.

6.5 DEFINE NUMBER RANGES FOR REBATE AGREEMENTS

Assign the number ranges for the rebate agreements

6.6 CONDITION TECHNIQUE FOR REBATE PROCESSING

The condition technique for rebate processing is similar to pricing

condition technique functionally but there are few differences.

There are two fields in the condition type which are directly related to
the rebate processing. The ‘Rebate Proc.’ Field indicates whether
the accruals should be posted automatically or not. This is dependent
on whether the condition is dependent on sales volume or
independent of sales volume.

The ‘Provision Con’ - accruals correction field controls the creation of

the B2 accruals correction document generated by the RV15B002
(Tcode: VOB3) program. This program may be invoked by the
system during final settlement when a rebate is created retroactively
and there are existing billing documents relevant for rebate or
manually by running the program through customizing (or by using
SA38) and selecting the ‘correct backlogs’ button.

The condition class in the condition type should be set to C for

expense reimbursement.

While configuring access sequence, if a different partner is desired,

then change the field definition because the standard access
sequences have the customer defined as the payer. For example, if
the rebate recipient and the payer is different.

The pricing procedure is very important for the rebate processing.

The rebate condition types must be included in the pricing procedure.
The account keys used in the pricing procedure control which G/L
accounts are updated. Rebate conditions use both the account keys
as you have seen above in the ‘Accounting of Rebates’ section. It is a
good practice to include requirement 24 for best performance and a
rebate basis with a sub-total of 7.
6.7 ACCOUNT DETERMINATION FOR REBATES

The account determination procedure is the standard functionality

which is explained above for the rebates processing. The expense
and the accrual accounts must be defined and set up for the two
account keys.

6.8 ACTIVATE REBATE PROCESSING

This is explained above in the ‘Pre-requisites of Rebates’ section.

6.9 DEFINE REBATE GROUPS

These rebate groups are linked to the material numbers in the

materials master – Sales: Sales Org – Data2 view which is
exclusively used for rebate processing. These groups are used in the
condition records.
6.10 RECALCULATE SUBTOTALS FOR REBATE
PROCESSING

This executes the program RV15B003. It is used when the sub-

totals on the billing documents need to be recalculated due to pricing
changes or the sub-totals need to be created on the billing
document. Then, the billing index must be re-created

6.11 CREATE REBATE PROCESSING INDEX

This executes the program RV15B001. It is used when something

has changed such as a customer having rebates activated on its
master record after billing documents exist or configuration changes
such as activating a certain billing type. It re-creates VBOX which is
the billing index.

6.11 COMPARE REBATE BASIS

This executes the program RV15B002. This is used to generate a

rebate basis B2 correction document.

IF we create a rebate agreement using the agreement type we just

created, it will look like this:
 7. ADDITIONAL FEATURES

Following are few of the additional features in the rebate functionality

provided in the standard SAP R/3:

7.1 Retroactive Agreements

7.2 Lump sum payments
7.3 Deleting RA
7.4 Long texts
7.5 Archiving of agreements

7.1. RETROACTIVE AGREEMENTS

A rebate agreement can be created for which the validity start date
lies in the past. The system then takes into account all the rebate-
relevant billing documents that were created between the validity
start date and the date the rebate agreement was created.

However the accrual amount is not posted automatically for

previously created bills. It must be entered manually.

Following two cases may occur when you wish to create a retroactive
rebate agreement:
a. The necessary settings have been made in Customizing and in
the relevant payer master record.
b. The necessary settings have not been made in Customizing,
and the payer for whom billing documents should be relevant
for rebate has not been classified as relevant for rebate.

7.2. LUMP SUM PAYMENTS

A lump sum payment is a special condition which does not depend on

sales volume but on a promotional performance such as a front of
store display or a local advertisement.
Creating a Lump Sum Condition Record
A lump sum condition record can be created within a rebate
agreement following the same procedure used to create other rebate
conditions. When the system asks for the condition type, then the
condition type for lump sum has to be selected.

The system will not display the Accruals rate field since the record
does not depend on sales volume.

Settlement of lumpSum RA
Lump sums can be settled:
 with the partial settlement carried out during the rebate
agreement period
 with the final settlement carried out at the end of the rebate
agreement period

7.3. DELETING RA

When the rebate agreement is deleted, it receives status as C. The

system uses a credit memo request to remove the accruals created
on the basis of the rebate agreement. the credit memo request for
the rebate agreement via Payment -> Rebate documents.

7.4. LONG TEXTS

Long texts for rebate agreements can be maintained. If there is a

requirement, then the long texts in the rebate agreement can also be
transferred into documents (e.g. into the credit memo request for a
rebate payment and from there into the rebate credit memo).
Transferring to documents is not supported for the texts maintained
in price conditions. And the texts are not copied over when creating
rebate agreements with references.

The following text types are set up in the standard system:

 0001: Opening comments
 0002: Licenses
 0003: Closing comments
 1000: Bonus payment

7.5. ARCHIVING OF AGREEMENTS

Archiving object for archiving agreements is SD_AGREEM. When this

archiving object is used, the system archives data from the tables –
EBOX, EKBO, KONA, KONH, KONAIND, SDKONDARCH, and
WAKHIND.
To archive agreements, the menu path is Logistics -> Sales &
Distribution -> Master Data -> Agreements -> Archiving -> Create
Archive (VKA4)

Appendix A: Glossary

Rebate Basis
Rebate basis is the amount from which the rebate is calculated. It is
a single step in the pricing procedure. It can be a discounted billed
value or the undiscounted billed value depending on the requirement.

Payable Rate
The rate at which the payment is given to the rebate recipient is
known as payable rate. Payable rate may be scaled based on sales
volume

Accrual Rate
The rate at which the accrual will happen in the G/L account is known
as accrual rate. Only one accrual rate can be specified.

Materials for Settlement

The material for settlement is used whenever settlement (payment)
is made. That is, the material for settlement determines what
product the rebate is charged to.

Settlement Period
Settlement period is the period which is used when periodic partial
settlement is carried out for a rebate agreement. This is carried out
at the relevant settlement dates.

Payment Method
The payment method determines how payments are to be made to
the rebate recipient. E.g. by check, by wire transfer, by credit memo
etc.

External Description
The external description is used to identify the scheme name or the
program name. E.g. CI 2000 98 KICS 5%

Arrangement Calendar (This is a CLIENT customization)

The arrangement calendar defines the end of the validity period of
rebate arrangements and controls their extension. E.g. this calendar
is used in the rebate agreements where the settlement happens at
the fixed interval like weekly, monthly, quarterly or yearly

Appendix B: Frequently Used Transaction Codes (FUTC)

Sl.No. Transaction Transaction Code Description

 Code
1 VBO1 Create rebate agreement
2 VBO2 Change rebate agreement
3 VBO3 Display rebate agreement
4 VB(D Extend rebate agreement
5 VB(7 Rebate settlement
6 VB(8 List of Rebate agreements
7 VOB3 Compare Rebate Basis: Billing
documents vs. Statistics

Appendix C: Rebate Tables

Sl.No. Table Table Description

Name
1 KONA
2 KONH
3 KONP
4 S060
5 VBOX
6 VBRP
7 KOTExxx
Rebate Agreement Header
Condition Record Header
Condition Record Details
Condition Record Totals
Index between KONP and VBRP
Billing Line Items
Rebate Conditions where xxx is
600,601, etc.

Table S060: Stores the payment and accrual information

This table is updated from when billing documents are created and
the posting to accounting is complete. When looking at a rebate
agreement using VBO2 or VBO3 and are displaying the condition
records, this table is accessed

Appendix D: Rebate Programs

Sl.No. Program Program Description

Name
1 RV15B001
2 RV15B002
3 RV15B003
4 RV15B004
Create new index for rebate
processing (table VBOX)
Compare Rebate Basis: Billing
documents vs. Statistics
Re-determination of sub-totals
Copying rebate agreements
 5 RV15C001 Settlement of Rebate
Agreements
6 RV15C002 List of Rebate Agreements
7 RV15C005 Extend Rebate Agreement

Appendix E: CLIENT Japan Experience

E1. AGREEMENT TYPES:

In CLIENT, the payer is different than the rebate recipient and there
is a separate partner function created for the rebate recipient.

There are more than 10 agreement types created for use in the
CLIENT Global Template but the most frequently used are described
as follows:

AGREEMENT TYPE 1:
This agreement type is for all SOLD-TOs linked to the rebate
recipient. Conditions types exist for independent of sales volume, and
volume based conditions for, % accrued based on a $ value, and $
back for each unit purchased. This agreement type is configured to
only allow manual payment upto what’s been accrued.

This agreement is most frequently used.

AGREEMENT TYPE 2:
This agreement type is for all SOLD-TOs linked to a customer
hierarchy node for a rebate recipient. It is identical to Type 1 but will
accrue for sold-tos linked to a node rather than all sold-tos linked to
the rebate recipient.

AGREEMENT TYPE 3:
This agreement type is for all specific SOLD-TOs linked to a rebate
recipient. It is identical to Type 1 but will only accrue for the specified
sold-tos identified in the conditions of the rebate agreement.

AGREEMENT TYPE 4:
This agreement type is a performance based rebate agreement type
similar to 0005 standard agreement type. This is an agreement that
pays a customer for performance considerations unrelated to sales
such as preferred shelf space or in-store advertising.

AGREEMENT TYPE 5:
There are three agreement types which uses the Agreement Calendar
functionality. CLIENT has developed 4 calendars – Weekly, Monthly,
Quarterly and Yearly. These agreements are created for a specific
period of time and can be activated for automatic extension. This
feature is used for time based cash-out agreements where an open
 agreement is final settled (cash out) and agreement is extended for a
new time period.

There is no manual payment option in these agreement types.

AGREEMENT TYPE 6:
This is a volume related agreement type for rebates to broker
companies. This is an agreement where rebates are paid to a broker
or agent based on sales to customers linked to that broker or agent.

E2. REPORTS:

There are lots of custom developed reports in the CLIENT Global

Template. Few of the important reports are described below:

1. Rebate Simulator
The rebate simulator is developed so that it allows to:
 Forecast accruals for an agreement that has not been
established.
 Forecast what the accruals would have been for a
customer if they had been included in a rebate
agreement.
 Validate the accruals for an existing agreement.
 View the invoice details for an agreement

2. Customers for a Partner

 Customers for a Partner is an SAP report that lists all
customers with the same Rebate Recipient, Broker,
Payer, or Sold-to customer number
 This report is used to view the relationships between
the different partner functions for a CLIENT customer.

3. Dealer Performance Report

This report is given to the dealers and the corresponding sales
representative and acts as a monthly report of progress
towards their quarterly goals.

4. Mass Manual Payment

This report helps in doing the mass partial settlement based
on the ‘External Description’ of the agreement. This is
required because in some cases, there are schemes which
cashes out 200 customers per month. Using the available SAP
functionality, these rebates would need to be maintained one
by one.

5. Mass Status Change

This report will provide a list of all open agreements by
external description. Using this function a rebate processor
can select a rebate agreement, view the rebate agreement's
details from the list, and use the list to set the status to 'B"
(Agreement released for settlement)
 6. Program Summary
This is an agreement summary report where the data is listed
by a program (External Description) or by rebate recipient.
That is, this report lists all agreements setup under a
particular program or it lists all agreements for one rebate
recipient number.

7. Payment Register
This report lists all the payments that were entered and
issued during a period of time that the user has defined. This
is used to:
 Verify the accuracy and changes made before the credit
memo requests become credit memos
 Ensure that all credit memo requests became credit
memos

8. Agreement Change History

This report gives the change history for an agreement. This
report lists for an agreement:
 What was changed or established
 When a change was made
 Who made the change

E3. SCENARIOS:

Following are the typical scenarios for the rebate scenarios:

1. E3.1 Discrepancy found after issuing the "Rebate credit memo" to the
customer

Part Settlement
- Cancel the CM (new document will get generated with S2
billing type) and then the money will automatically go back
into the agreement
- Do a VA02 for the CMR and put a ‘reason for rejection’
- Make another partial payment from the agreement

Final Settlement
- Cancel the CM and a new document will get generated with S2
billing type
- Do a VA02 for the CMR and change the payment amount by
going to the ‘conditions’ tab for each line item
- Bill the CMR and a new billing document (CM) will get
generated

(In case of partial payment, you cannot change the value on the CMR

2. E3.2 Max-Min goals (Overview of Condition records)

 Minimum Goal Definition is the minimum amount of purchases
made by the customer. E.g. A customer must purchase
1million JPY of product to be eligible, then 1Million JPY is the
minimum goal
This is only used in reports. When dealer performance report
is run, it looks at the customer purchases and determines how
close they are to the goal. This is not used to prevent rebate
payments to a customer.

Maximum Goal Definition is the maximum rebate basis to be

used for determining the amount to pay a customer. It is the
maximum value to be used when determining a payment
amount for final settlement. This is NOT the maximum
amount to pay a customer.

3. E3.3 Retroactive rebate agreement

A rebate agreement (for a particular rebate recipient) is

created on 15th of the month but the validity start date is 1st
of the month. The sold-to’s attached to that rebate recipient
has already been billed from the 1 st of the month. Then the
accrual will happen ONLY for the billing documents generated
on or after 15th of the month but the payment to be made
(shown in the sales volume report) will be from 1st of the
month.

In this scenario, the program RV15B002 or the transaction

code VBO3 is executed to correct the accrual amount. This is
illustrated below:

BEFORE CORRECTION:

AFTER CORRECTION:
After executing the transaction code VBO3, a Zero value credit memo
(B2) is generated, as shown below:

This is of zero value because it is only to correct the accrual amount.

The rebate recipient is not receiving any payment.

Appendix F: Few Demonstrations

F1: REBATE ACCOUNTING

There are two processes where the accounting entries get generated.
They are ACCRUAL and PAYMENT. The accrual is posted to the
financial accounts at the time of billing. Following are the two
scenarios illustrated to show the accounting entries posted in
Financial Accounting

SCENARIO I: Sales Accrual – Manual Payment – Final

payment

An agreement type 1 is created for the rebate recipient with the

accrual and payment percentage as shown below:
1. AUTOMATIC ACCRUAL (using OTC cycle)

When the order to billing cycle is done for a customer and a material
(whose VRG is 99), then the pricing procedure in the billing
document shows the rebate entries as shown below:

The accounting document created shows the accrual entries as

shown below:

The account codes 3010300 and 1052100 is linked to the account

key ERU for the accrual entries
3010300 is the rebate expense account
1052100 is the G/L accrual account, which goes to the Liability

Following is the sales volume report from the option VBO2 – Rebate
Payments – Sales Volume:
Actual payment to be made to Rebate recipient = 4500JPY (Rebate
Basis * 3%)
Accrual made for the Rebate Recipient = 6000JPY (Rebate
Basis * 4%)

Where Rebate Basis = 150,000JPY

2. MANUAL PAYMENT (PARTIAL PAYMENT)

(Menu path: VBO2 – Rebate Payments – Pay) [Billing Type = B3]

When a partial payment (2000JPY) was done for this agreement,

credit memo request (VA01) has been generated automatically and
then subsequently credit memo (VF01) is created. You can see below
that the material which is used for credit memo is the 'material for
settlement’:

The accounting document generated is shown below:

The account codes 3010300 and 1052100 which is linked to the
account key ERU is used now for the reversal of accrual entries

The account code 3010301 is linked to the account key ERB for the
actual revenue reduction.

Tax amount is refunded to the customer.

Following is the sales volume report from the option VBO2 – Rebate
Payments – Sales Volume:

Here, you can see that the actual payment to be paid to the Rebate
Recipient has been reduced to 2500JPY after the partial payment of
2000JPY.

Also, the accrual amount has been reduced.

3. FINAL SETTLEMENT
[Billing Type = B1]

The final settlement for a rebate agreement can be made in one of

the following two ways:
i. Automatic Payment (No option to change the
amount)
ii. Using Payment Screen (Option to change the final
amount)
Final settlement of the agreement results in a credit to the customer
and the end of the agreement.

Using Payment Screen

When a final settlement (928JPY) was done for this agreement, credit
memo request (VA01) has been generated automatically and then
subsequently credit memo (VF01) is created. You can see below that
the material which is used for credit memo is the 'material for
settlement’:
The accounting document generated is shown below:

Here, the entries are as follows:

- Pending accrual amount of 4000JPY is reversed.
- Actual revenue is reduced further for the amount 2500JPY.
- Tax amount is refunded to the customer
- Customer gets the payment plus the tax amount

Following is the sales volume report from the option VBO2 – Rebate
Payments – Sales Volume:

Both the accruals and the amount to be paid to the customer is

ZERO.

SCENARIO II: Sales Accrual – Manual Accrual – Manual

Payment – Final payment

An agreement type 1 is created for the rebate recipient with the

accrual and payment percentage as shown below:
Automatic Accrual through sales is shown below from the sales
volume report:

The verification level is shown below:

4. MANUAL ACCRUAL (menu path: VBO2 – Extras – Manual

Accrual)
[Billing Type = B4]

Manual accruals are done from within a rebate agreement. The sign
on the 'amount of money to accrue' indicates whether it’s a regular
accrual or a reverse accrual.
A regular accrual (to put money into the agreement)
should have a NEGATIVE sign.
A reverse accrual (to take money out of the agreement)
should have a POSITIVE sign.
Manual accrual is recommended only for the condition BO06. By
adding money via a manual accrual into other condition types (like
BO01), the money is only available when doing a manual payment
and not when doing a final settlement. Only the sales accruals are
utilized for final settlement. This type of arrangement was there in
CLIENT Global Template.

When a manual accrual (5000JPY) was done for this agreement,

credit memo request (VA01) has been generated automatically and
then subsequently credit memo (VF01) is created. You can see below
that the material which is used for credit memo is the ACTUAL
MATERIAL because the rebate agreement is created for the key
combination ‘Rebate Recipient/Material

The accounting document is shown below:

Following is the updated sales volume report from the option VBO2 –
Rebate Payments – Sales Volume:

MANUAL PAYMENT (PARTIAL PAYMENT)

(menu path: VBO2 – Rebate Payments – Pay) [Billing Type = B3]
When a partial payment (2000JPY) was done for this agreement,
credit memo request (VA01) has been generated automatically and
then subsequently credit memo (VF01) is created. You can see below
that the material which is used for credit memo is the ACTUAL
MATERIAL:

The accounting document is shown below:

Program Summary report shows as follows:

This was the customized report in the CLIENT Global Template.

Sales volume report shows as follows:

Customer was supposed to get 127JPY but we had paid 2000JPY, so
customer owes the company 1873JPY. It is an OVERPAYMENT case.

FINAL SETTLEMENT [Billing Type = B1]

i. Using Automatic Payment option

The final settlement (JPY1873-) was done automatically for this

agreement. A credit memo request (VA01) has been generated
automatically and then subsequently credit memo (VF01) is
created manually. But, actually a Debit Note got created
because of the overpayment case.

The accounting document generated is shown below:

Here, the entries are as follows:

- Pending accrual amount of 3191JPY is reversed.
- Actual revenue amount is increased by 1873JPY
- Customer has to pay CLIENT 1966JPY.

The Program Summary report shows as follows:

F2. AUTOMATIC ALLOCATION OF TEXT USING STANDARD TEXT

FUNCTIONALITY

In CLIENT Global Template, all text on Credit Memos and Checks are
passed to those documents by manually placing text on the credit
memo request (prior to creation of the credit memo) or by utilizing
the auto text creation extension (customized program) by external
description. These automatic text templates are stored within SAP as
standard text by external description of the rebate
agreement/program-id and in the language of the customer.

The automatic allocation of text for the rebate documents is

applicable ONLY for the document types B1 (Final Settlement) and B3
(Partial Settlement)

The automatic allocation of text is achieved

 By making the Rebate ‘External Description’ exactly same as
the Title of the Standard Text Template
 Language in the standard text template should be the same
as the language maintained for the rebate recipient

Illustration is as follows:

1. Create a Rebate Agreement

2. Create TEXT NAME in SO10

 - Check the ‘Text Name’, which is same as the ‘External
Description’ in the rebate agreement.
- Language ‘EN’ should be same for the rebate recipient
613499

The text created using SO10 is shown below:

2. Do a partial payment for this rebate agreement

3. Display the partial payment (VA03)

GOTO – HEADER – TEXTS as shown below

 The text which is maintained as the standard text template is
copied automatically to the credit memo request as shown
below:

4. Create the credit memo & then Display the credit memo
(VF03)

GOTO – HEADER – HEADER TEXTS as shown below

The text which is maintained as the standard text template is

copied automatically to the credit memo as shown below:

5. Output

The same text message should appear in the output also.

Message could not be checked in the output as the print
preview and the output is not configured
 F3. EFFECT OF RETURNS IN REBATE AGREEMENTS

Rebates in SAP are integrated with other parts of the Order to Cash
cycle. Other transactions such as product returns will influence
agreement accruals. If product is returned by a customer the system
will adjust the accruals based on any open rebate agreements.

Scenario1: Sales Accrual – Complete Return

1. Agreement type 1 is created.

2. OTC Cycle done and Billing Document is generated
Sales Accrual = 306JPY

3. Return order created and PGR done

4. Effect on accrual
 Accrual (306JPY) got reversed with the same amount as
shown below:

Scenario2: Sales Accrual – Partial Payment – Complete Return

1. OTC Cycle done and Billing Document is generated

Accrual amount = 128JPY

2. Partial Payment (of 100JPY)

Pending accrual amount is 28JPY, whereas customer actually
owes 4JPY (because of OVERPAYMENT of 100JPY)

3. Complete Return (of 128JPY)

4. Effect on Accrual
Accrual is totally reversed as you can see in the ‘Verification
Level’ report.
But, now the customer owes us 100JPY as seen in the sales
volume report. This is due to the partial payment already
done.
5. Reversal of Partial Payment
 Cancel the CM (new document will get generated with S2
billing type) and then the money will automatically go back
into the agreement
 Do a VA02 for the CMR and put a ‘reason for rejection’

6. Check the sales volume report

No accrual pending and no payment amount shown