Credit Management/Risk Management
The payment guarantee for the value to be billed plays a central role within Sales. Credit management effectively
allows you to minimise the credit risk.
Risk management for receivables is another useful tool for setting a payment guarantee to cover the credit risk.
Note
The functionality of the simple credit limit check is covered fully by credit management which is available from
Release 2.2. In the simple credit check you can only set one system reaction (warning, error, delivery block) when the
credit limit is exceeded. Other functions in credit management are not available.
It is planned that credit management should be used exclusively at a later date.
Enter Settings
Credit management is directly related to functions in Sales and Distribution and requires certain settings (for example,
in partner determination, output determination).
This section describes how to set defaults for Customizing functions related to Credit Management.

Pricing
Enter the subtotal "A" to specify the credit value in the pricing procedure which you use in pricing during
credit processing (Pricing procedure detail screen, 2nd view). With this, the system calculates subtotals for
the credit price during pricing and stores them in a certain field (KOMP-CMPRE = credit price of the item).
The calculated subtotals are used in credit functions.

Sending Mails in credit processing
You can define credit representatives in Customizing for FI. They must also be assigned to an HR human
resources master. Credit representatives can be copied into the partner function during sales order and
delivery processing. Internal mails concerning credit processing are directed to these representatives, that is
once you have maintained the the mailing address in the human resources master.
o
Partner determination
The standard system contains the partner functions credit representative (KB) and credit
manager (KM) for credit processing.
Both partner functions are allocated to partner type "PE". The credit manager is one level higher
than the credit representative.
Enter these partner functions in the partner determination procedures of the sales document
header and the delivery header so that the partners involved in credit processing (for example, for
forwarding mail messages) can be allocated and identified. Assign value "A" to the partner
functions in the Access field.
o
Output determination
For the condition types for output determination, the output condition type KRML is set up. To
create and use corresponding condition records for credit management, maintain the output
determination procedures for sales documents and deliverie concerning condition type KRML.

Reports
Define the list layout of work lists for Credit Management. The section "Work lists" in IMG describes how to
proceed.

Authorizations
Two authorization objects were created for Credit Management:
o
V_VBUK_FRE
o
V_KNKK_FRE
Authorization objects are included in the standard SAP profiles. If you want to use the authorization objects
in a different way than in the standard version, you must adapt them using authorization maintenance and
enter them in individual user profiles if necessary.

Subsequent functions in Shipping
The result of credit checks can influence the shipping due date, picking and goods issue of sales orders or
individual items. This is why you must take the subsequent requirements for Shipping into account when
configuring credit processing.
Take the following three requirements into account for Shipping:
o
requirements for creating a delivery due index from the sales order
o
requirements for picking from the delivery
o
requirements for goods issue from the delivery
Note that you can change the copying routines in the "Requirement" field, or create your own FORM
routines using requirement maintenance. You cannot change the specifications in the field "System
requirement".
The section "Routines" in the IMG describes how to create copying routines. If you create your own
requirements, you have to take into account the name range that SAP reserves for customer enhancements.
The same applies to the subsequent functions for the availability check and transfer of requirements
explained below.

Subsequent functions for availability checks and transfer of requirements
As a result of credit checks, the system may block or release sales orders or individual items. For this
reason, take into account subsequent requirements for the availability check and for transfer of requirements
when configuring credit processing.
Consider the following for the availability check and transfer of requirements:

o
You can define requirements for creating a purchase requisition from an order.
o
The R/3 system does not yet support tying transfer of requirements to requirements.
o
You can tie the creation of a confirmed quantity to requirements for the availability check.
Logistics Controlling update
Maintain the SD update in Logistics Controlling. In the standard R/3 System, the information structure
"S066" is set for monthly update of outstanding order values in Credit Management. You can change the
parameters of the information structure and change the period type from monthly to daily update, for
example.

Updating credit control areas
To update credit control areas, define for each credit control area the range of the credit update in the
organizational structure (Customizing -> Configuration -> Org.structure -> Setup -> Accounting -> Financial
accounting -> Credit control area).
Keep in mind that the system determines the next higher credit update if a transaction cannot be processed
with the required credit update. For example, update "18" is carried out in the planned range if "12" is not
possible.

Assigning credit control areas to company codes
In the organizational structure (Customizing -> Configuration -> Org. structure -> Mappings -> Accounting ->
Financial accounting -> Comp.code - cred.cont.area) you have to assign the credit control areas to company
codes.
Actions
1. Enter subtotal "A" for the credit value in the detail screen of the pricing procedure.
2. Maintain the partner determination procedures of the sales document and delivery header by entering the
partner functions KB (credit representative) and KM (credit manager).
3. Maintain the output determination procedures for sales documents and deliveries concerning the
condition type KRML.
Make sure that the output condition records contain all necessary specifications for Credit Management (see
note below).
o
maintain output determination procedures for sales documents
o
maintain output determination procedures for deliveries
4. Define the display variants for Credit Management.
5. Enter the authorization objects in the composite profiles or into the user-specific profiles. If necessary,
change the standard values of the activities for each authorization object according to individual points of
view.
6. Define the condition for creating a delivery due index from the sales order.
7. Specify the condition for goods issue from the delivery.
8. Specify the condition for picking from the delivery.
9. Specify the condition for creating a purchase requisition from the sales order.
10. Specify the condition for creating requirements for the availability check from the sales order.
11. If necessary, change the parameters of the information structure in Logistics Controlling when
configuring the update for sales and distribution "S066".
12. Define the type and scope of the update for each credit control area by choosing an update that meets
your requirements from the updates contained in the standard system.
13. Allocate allowed company codes to the credit control areas.
Note on condition records
Output condition records which you create using the application menu for credit management must be allocated to
the condition type KRML. Make sure that the condition records contain all necessary data:
o
credit representative group
o
risk class
o
partner function (KB or KM)
o
do not enter output partners
o
output medium ("7")
o
time of output processing ("4")
o
language
o
Maintain the following entries in the message processing area on the communication screen:
Transaction code Parameter ID
Sales order: VKM3 VBAK-VBELN AUN
Delivery: VKM5 LIKP-VBELN VL
Transport
Initiate transport for partner functions and authorizations using the menu in the initial screen.
Determine Active Receivables Per Item Category
In this menu option, you specify for each item category whether an item of the respective item category is to be
included in the credit functions (check and update of open credit values).
The system proposes all valid item categories for the corresponding selection.
Actions
Select the "Active receivable/credit relevant" field for each item category which is to be taken into account for the
credit check.
Maintain Authorizations
In this step, you make settings for authorization checks in Credit Management.
Define Document Value Classes
Document value classes provide a means of assigning sales order and sales and distribution documents depending
on their document value.
Using the document value classes, credit representatives, for example, can be given different authorizations for credit
allocations depending on the document value. A credit representative, for example, can edit all transactions involving
credit up to the value of $1000.-, another representative can edit transactions involving credit over $1000.-.
Actions
1. Create document value classes according to your requirements by entering a three-character
alphanumeric key and a textual description.
2. Make sure that the credit representatives are allocated to the document value classes.
Assign Document Value Classes
In this IMG activity, you assign document value classes to the credit control areas.
Actions
1. Enter a credit control area and allocate a credit value to it in a relevant currency.
2. Allocate a document value class.
3. Make sure that the credit control area was entered in the corresponding customer master records.
Maintain Authorizations
In this step, the system proposes SD authorization objects for Credit Management.
The objects V_KNKK_FRE and V_VBUK_FRE are available in the standard system.
Note
There are three FI authorization objects for maintaining a customer's credit data.
F_KNKA_KKB
F_KNKA_MAN
F_KNKA_AEN
Receivables Risk Management
Payment guarantees of values to be billed play an important, central role when selling goods. Alongside credit
management, risk management for receivables provides another efficient tool for guaranteeing against credit risks.
The following payment guarantee procedures are available in risk management:

Documentary payment guarantees

Payment cards

Export credit insurance (external link).
Define Forms Of Payment Guarantee
In this IMG activity you define the form of payment guarantee.
The form of payment guarantee controls how an item in a sales document is guaranteed (e.g. personal guarantee,
payment card, unconfirmed letter of credit, export credit insurance (external link), confirmed letter of credit).
The following forms of payment guarantee are available:

Payment cards

Export credit insurance (external link to Open FI)

Documentary payment guarantees (for more information, see Documentary payment guarantees in the
IMG.
Activities
1. Define forms of payment guarantee.
Further notes
The following rules determine how the system accesses forms of payment guarantee, according to the category of
payment guarantee:

Payment cards are first activated, if a payment card has been entered in the document.

Documentary payment guarantees are activated immediately.

Export credit insurance is activated if a valid contract exists.
Define and Assign Payment Guarantee Schemas
In this IMG activity you define payment guarantee procedures. You can also assign payment guarantee procedures
to transactions by defining the following dependencies:

to the customer

to sales document type.
The form of payment guarantee controls how an item in a sales document is guaranteed (e.g. personal guarantee,
payment cards, export credit insurance, confirmed and unconfirmed letters of credit). The payment guarantee
procedure contains the permitted forms of payment guarantee for payer and document type. It also controls the
sequence in which the the system assigns sales document items to payment guarantee procedures.
The payment guarantee procedure is determined according to the following factors:

Customer payment guarantee procedure
This determines which payment guarantee procedure the system automatically uses if you enter a sales
document for the customer.

Document payment guarantee procedure
This determines which payment guarantee procedure the system automatically uses for a sales document
type.
To determine the procedure, you assign the customer and document procedures to the payment guarantee
procedure.
In Risk Management for Receivables, the system determines the payment guarantee procedure using procedure
keys. It uses the document payment guarantee procedure key in the header for the sales document type, and the
customer payment guarantee procedure key in the customer master.
You can use requirements to control when there should be no payment guarantee in risk management for the
specified form of payment guarantee (e.g. item values under $10, a certain product hierarchy, or product group do not
need any payment guarantees).
Activities
1. Create your payment guarantee procedures.
2. Define your customer determination procedure for determining the payment guarantee procedure.
3. Define your document pricing procedures for determining the payment guarantee procedure.
4. Assign the document procedure to the order types.
5. Assign the document pricing and customer determination procedures to the payment guarantee
procedure.
Credit Management
Credit management enables you to monitor, evaluate and control credit situations and credit allocations. The
integration of current information from FI and the simultaneous access to the credit and sales information system
provide a broad information basis for evaluating critical credit situations and credit allocation.
Credit management includes the following functions:

Carrying out credit checks according to different criteria and at different points in time

Automatic notification of the responsible employees in critical credit situations by means of an interface to
the mail system and therefore rapid processing of urgent credit problems

Support in critical credit situations concerning credit allocation by means of an interface to the Sales
Information System and FI

Allocation of different authorizations to credit representatives according to certain criteria (for example,
authorizations according to the level of the credit limit used or according to document value classes)

Monitoring credit allocation (for example, by creating overview lists)
Carrying out a credit check is controlled by several settings:

The credit group determines the group of transactions for which a credit check is carried out.

The type and the scope of the credit check can be defined at the level of the sales document types (with
separate control of the delivery types at the time of delivery and goods issue).

You specify at item level for each individual item category whether or not the item category is included in the
credit functions.
To configure credit management according to your requirements, you must edit the following points:

Defaults in various Customizing menus:
o
Pricing ( pricing procedure)
o
Partner determination ( partner determination procedure for sales and delivery header)
o
Output determination (output determination procedure for sales documents and delivery)
o
Reports (display of lists)
o
Authorization maintenance
o
Subsequent functions in shipping (delivery due index, picking, goods issue)
o
Subsequent functions for availability check and transfer of requirements
o
Update in Logistics Controlling
o
Update of credit control areas
o
Allocation of the credit control areas to company codes


Settings in the Customizing for sales and distribution in the step "Credit management":
o
Define credit groups
o
Set sales documents and delivery documents for credit management
o
Set sales and distribution document items for credit management
o
Define type and scope of the credit checks
o
Specify document value classes and credit control areas for the authorization check and assign
them to each other
Setting in credit management for Financial Accounting:
o
Define groups for each credit control area
o
Define risk classes
o
Define credit representative groups
o
Define credit representative
Note
Please refer to the section "Credit management" of the FI Implementation Guide for further details of the settings
which
Define Credit Groups
The credit group groups together different business transactions which should be dealt with in the same manner with
regard to the credit check.
You enter the credit groups when you configure the sales document types for credit management and define the
automatic credit check.
Default settings
The following credit groups are contained in the standard SAP R/3 System:

01 = credit group for sales order

02 = credit group for delivery

03 = credit group for goods issue
Actions
1. Check whether you can use the credit groups in the standard system.
2. If you need to create new credit groups, enter an alphanumeric key with two characters and a descripion
for the credit group.
Assign Sales Documents and Delivery Documents
Credit checks can run at different times during order processing.
For delivery creation, you can additionally specify whether the automatic credit check occurs at the time of delivery
creation and/or goods issue.
In this menu option, you specify the sales document types for which a credit check should be carried out. Here,
delivery types can be controlled separately and specifically at the time of goods issue.
At the same time, you specify the system responses if credit checks are set. The system can respond in the following
ways:

Warning message
The document can be saved.

Error message
The document cannot be saved.

Setting a delivery block (credit status)
The document can be saved. However a block is automatically set in the credit status.
Actions
1. Define for each sales document type whether a credit check should be carried out. Enter "D" if an
automatic check should be carried out.
2. Specify a credit group.
3. Specify a credit group for the delivery type for which you want to carry out a credit check.
4. Specify a goods issue credit group for the delivery type for which a credit check is to be carried out for
goods issue.
Define Automatic Credit Control
The automatic credit check can target certain aspects during a check and run at different times during order
processing. In this activity, you can define your own credit checks to correspond to your requirements in the area of
Credit Management.
You can determine an automatic credit check for any combination of the following:

Credit control area

Risk class (classifying attribute for your customers from the viewpoint of credit risk which is maintained in FI
Customizing)

Credit group
Example
You can define a credit check for a certain credit control area and for all sales orders in which the customer
has risk class 2 (RK2).
It is possible to define a system response for each credit check (for example, warning message). In the case of a
warning message, a block can be set in the credit status of a document.
When you define automatic credit checks, you can also freely define requirements which cause a document or the
forwarding of the material requirements to MRP to be blocked. This is described in the IMG section "Make default
settings for Credit Management".
If you define your own credit checks, proceed as follows:

specify type of check

specify scope of check

specify system response to check

allocate credit control areas

define and allocate risk classes if necessary

allocate credit group

assign description to the credit check
Types of credit check in integration with SAP Credit Management
If you have activated integration with SAP Credit Management in Financial Supply Chain Management (FSCM), you
can perform the following credit checks in this activity:

Credit check on basis of maximum document values
The order or delivery value must not exceed a value defined in the credit check. The value is saved in the
currency of the credit control area. This check is very useful for new customers for whom no credit limit has
yet been defined. This check can be controlled by a risk class that is reserved for new customers.

Credit check for changes to critical fields
The credit check is triggered by changes to credit-relevant document fields compared to the default values
from the customer master record (payment conditions, value date days, fixed value date).

SAP Credit Management
If you select this field, you can perform your own credit checks in an implementation of BAdI Connecting to
SAP Credit Management (BADI_SD_CM)
Types of credit check when SAP Credit Management is not activated
If you just have SD/FI credit management, that is, do not have Integration with SAP Credit Management (FSCM)
activated, you can execute the following types of credit checks:

Static credit limit check
Credit allocation depends on the total value of open orders, deliveries, billing documents and open items.

Dynamic credit limit check
The dynamic check includes both a static part which checks all open items, deliveries and billing documents
and a dynamic part which checks all outstanding order values, that is, all orders not yet delivered or partially
delivered. The value resulting from the checks is accumulated up to the shipping date in the information
structure "S066" in freely definable time units or periods (day, week, month). This information structure is
entered in Logistics Controlling and described in the section "Carry out default settings for credit
management" under Basic functions.
To define the credit check, you specify a certain number of relevant periods from which a date in the future
can be calculated (for example, 10 days or 2 months depending on the selected period). This ensures that
sales orders which lie further in the future are not used to determine the credit exposure.
The total of the static and dynamic part of the check must not exceed the granted credit limit.

Credit check on the basis of the maximum document value
The sales order value or the value of goods to be delivered must not exceed a certain value defined for the
credit check. The value is stored in the currency of the credit control area. In particular, this check is useful if
the credit limit of new customers has not yet been specified. This check can be accessed explicitly by a risk
class reserved for new customers.

Credit check when changing critical fields
The credit check is started when changes are made to credit-relevant document fields so that they differ
from the default values proposed from the customer master record (terms of payment, value days and fixed
value date).

Credit check at the time of the next internal check
The credit check is started automatically on a certain date. All sales orders entered up to this time are
regarded as not critical.

Credit check on the basis of overdue open items
The ratio between open items, which are overdue by more than a certain number of days, and the customer
balance must not exceed a certain percentage.

Credit check on the basis of the oldest open items
The oldest open item may only be a certain number of days overdue.

Credit check against maximum allowed dunning levels
The dunning level of the customer may only assume a certain maximum value.

Customer-specific credit checks
If you require further checks to those defined in the standard system, you can define them in the
corresponding user exits (LVKMPTZZ and LVKMPFZ1).
Requirements
In the No Check field, you can enter the number of a requirement with which you can control when credit checks are
not carried out. You can deactivate some or all checks. This allows fine tuning on an individual basis for defining
credit-relevant transactions and when credit checks do not need to be carried out.
For example, you could deactivate the credit check for the following sets of circumstances:

As long as a document contains no items, no check will be carried out.

No check will be carried out during order creation, but rather 14 days before delivery using a background
program.

A check should be made to see whether the payment guarantee form has changed (letter of credit, payment
card). If the payment guarantee form has not changed and if the old net value does not exceed the new net
value, then no credit check is carried out.
You can also reset the credit document status. The following example demonstrates when this is necessary:
You are working with risk management and have specified payment card as the payment guarantee form in the
payment guarantee procedure. You create a sales order but do not enter a payment card and the credit check is
carried out. You then change the sales order and enter a credit card. Since the credit card is a secure means of
payment usually for an unlimited amount, you do not want to carry out another check. You can now use a
requirement to have the system bypass all checks and reset the status.
Requirements are stored as routines. For further information on routines, see the IMG of SD under Routines. The
two following example routines are supplied in the standard system. You can display and edit them using transaction
VOFM:

1 Order

2 Delivery
You can copy and change these routines according to your own requirements. The routines contain different example
scenarios in which credit checks would not be carried out.
Caution:
Make sure that the coding in your routines is consistent with the coding in risk management and the import and
export parameters for the example routines supplied with the standard system.
Check financial accounting/old A/R summary
In distributed systems (central financial accounting, decentral sales and distribution), the FI data from the central
system is needed for the credit check (see also: Release note Credit management in distributed systems). At the
payer level or credit account level, for example, the following data would be needed for a check: Total of open items,
detail information on open items (i.e. oldest open item), maximum dunning level, etc. Using the A/R summary, the FI
data in the central system can be collected and then transmitted to the decentral SD system using the distribution
function. The data is then evaluated in the SD system. The A/R summary represents compressed FI information for
the credit check.
In check financial accounting/ old A/R summary, you can specify the allowed change rate for the A/R summary using
allowed days and allowed hours. This is where you define how old the A/R summary can be for a check to be carried
out. If the age rate for the A/R summary is exceeded during a credit check, the document is blocked.
Tip:
If you have set up credit management so that credit checks are only carried out for certain, comparatively rare orders,
then you can enter an age rate of 0. You should also activate RFC in FI Customizing for credit management
(preparatory configurations). This ensures that the A/R summary is always determined if a credit check is to be
carried out. Because credit checks are carried out relatively rarely in this case, system performance will not be
significantly influenced.
Note:
Fields allowed days and allowed hours are only available for entry if you have entered an X in field Read A/R
summary in FI Customizing. The path is:Accounts Receivable and Accounts > Credit Management > Credit Control
Account > Make basic settings for credit management.
Actions
1. Enter a combination of credit control area, risk class and credit group as well as a description for the
credit check you want to define.
2. On the detail screen of credit control, specify the type of checks required (for example, static, dynamic),
the scope of the check as well as the system response according to your requirements.
3. If necessary, enter the general data for the credit check.
Simple Credit Limit Check
Note
Credit management, available as of Release 2.2., contains all credit limit check functions.
During the simple credit limit check, you can only configure one system reaction ('A' warning, 'B' error, 'C' delivery
block) when the credit limit is exceeded. You cannot use the remaining credit management functions.
It is planned to implement only credit management in a later release.
Simple credit limit check
A credit limit check can be carried out when sales documents are created or changed. The check is carried out within
one credit control area. When changing a document, the check is repeated if changes regarding quantity or value
are made. A credit control area consists of one or more company codes. A sales document belongs to one credit
control area depending on the allocation of the sales organization to a company code. The SAP System checks the
credit limit which was granted to the customer in this credit control area. The credit control areas and the credit limit
of a customer are defined in financial accounting and entered in the customer master record. During the check, the
SAP System totals the receivables, the open items from special G/L transactions and the net value of the sales
order for every item of a sales document. The open items take into account obligations bound by contract which are
not recorded for accounting purposes but which involve expenses through diverse business transactions. The total is
compared with the credit limit. If the limit is exceeded, the system responds in the way defined by you in the
configuration menu.
Requirements
The sales document types must already be defined. The SAP System automatically proposes the defined sales
document types for maintaining the credit limit check.
Actions
Define whether a credit limit check should be carried out for the individual sales document types. Also define how the
system should respond if the limit is exceeded. The following system responses are possible:

Warning

Warning and delivery block
The document can be saved but is automatically blocked for delivery.

Error message The document cannot be saved.