Cash is king. Our systems should identify customers with bad payment behavior or with high financial risk before any harm is done. SAP Automatic Credit Management blocks activity at the right moment: before the goods have left.

I’ll explain the settings available for automatic credit management in the sales process in all releases since R/3 3.0. With these settings you can control system behavior for customers whose credit status you no longer trust. The automatic process determines the system reaction each time a sales order or delivery is created/changed. The system gives a warning, blocks the document, or allows further processing depending on the actual customer credit situation. It takes into account payment behavior, credit limits, and current total credit exposure (Figure 1).

Figure 1

Credit management in the sales flow

In this article I deal with the settings for automatic credit controls in the sales process. For information on credit management organization, credit limits, credit exposure calculation, and customer groupings in SAP Financials, see the article titlled "Make SAP Automatic Credit Management Work for You: Credit Limit Calculation."

Automatic Credit Management Basics

When all the settings are in place, a document gets a credit block when a customer is past its credit limit. When you save the sales order/delivery, the system displays a message (Figure 2).

Figure 2

Credit management in the sales flow

The blocked document line appears in a standard report for the credit manager (transaction VKM1). He or she must decide whether to release the document after analyzing the customer position in the credit master sheet (Figure 3). (To release the document click the green flag shown in Figure 3.) With this simple process you can prevent losses to known bad credit risks. You can make customers who mend their ways by paying all or part of their backlog eligible to order again immediately. You can capture new customers automatically and, at your discretion, they can undergo a review or receive a standard credit limit.

Figure 3

Checking report VKM1, analyzing the customer, and releasing the blocked line

I use the example of an organization producing components for other businesses to show you the process. Typically, the orders sit in the system for a long time, customer numbers are not large, and the damage done by a single defaulting customer is significant. A credit management design requires answers to a set of key questions. For each question I discuss business pointers plus the technical tools available in SAP:

• When does my system block activity?
  
  - General: sales order, delivery blocked
  
  - Specific: sales order type, document type blocked
• Why does my system block activity
  
  - Credit exposure
  
  - Payment behavior
  
  - Stochastic (random)

When Does My System Block Activity?

In sales flows when the delivery is triggered immediately after sales order creation, the moment of sales order creation involves credit risk. Once the sales order is through, you can do very little, so you might want to consider a credit block at that point. On the other hand, if sales orders sit in the system for a longer period with multiple lines that are scheduled for various dates, a credit block at sales order creation makes no sense. The credit status of a customer should be evaluated when a delivery is due. You could also make a preemptory check for some customers. Once the basic decision is taken (order or delivery) you can consider the decision further using document type as an additional criterion. For example, production orders should be checked but service orders should not.

In my business case, deliveries are the key process. Sales orders sit in the system for a long time and typically have large numbers of lines. Blocking an order at creation is not practical. However, for some (suspect) customers, I want the ability to review the order acceptance, so as not to overburden the planning systems. For this configuration, you need a group of sales orders (to support the check of suspect customers) and a group of deliveries (automatic credit check of all deliveries on creation).

For large consumer companies, this would not work. The focus there would be on the sales order, probably distinguishing different types of sales orders.

Customizing

In SAP Automatic Credit Management, the selection of “trigger moments” is realized by grouping document types in Credit Groups. You do this in two steps. First, give the groups names (Figure 4).

Figure 4

Naming the credit groups of sales documents

After creating groupings for your documents, assign document types to the groups (Figure 5). For my example, you could include a check on Standard Orders, but a check on credit notes makes no sense, because a credit note actually reduces the credit exposure of a customer. A credit check would only add to the workload of credit managers and hamper a speedy correction of earlier mistakes by sending a credit note to a customer.

Figure 5

Assign the documents where you want to control and select D (automatic credit control)

With this simple selection, you define when to trigger credit control. Creation of the documents in the credit groups activates credit management, as do changes in critical fields in these documents.

For my example I placed standard orders in group Z1 and all deliveries in group Z2. Don’t make the mistake of selecting all sales order types. Credit notes or service orders should normally be excluded. Credit notes lower the credit risk and service orders are often included in warranty or long-term contracts. Adding them to the credit exposure can create a distorted picture of the actual credit risk involved.

Why Does My System Block Activity?

You define the system’s reactions to credit issues in automatic credit control by credit control area and the type of customer (i.e., risk category). I will describe these in my second article. Figure 6 shows the area in finance customizing where these settings are made. For the moment, let’s focus on the control logic and assume it is the same in every situation.

Figure 6

Customizing risk categories and defining the organization of credit management

Automatic control looks at the credit limit and payment behavior. The check of amounts of customer exposure against the credit limit in the customer credit master (F-32) is well known, but many other checks are also possible. In each case, the system reacts with an on-screen warning or error message. With an error message, you cannot save the sales order or delivery, whereas you can with a warning. In addition to the warning, you can detail that a sales order or delivery be blocked for credit control. In that case, further processing is only possible after manual release by a credit manager.

Credit errors are an efficient way to deal with large quantities of low-value transactions, especially because error messages prevent the labor-intensive process of manual analysis and release. In the case of low volume and high value business, error messages preventing document creation are not used. With very large accounts, minor credit issues occur as a matter of course if large invoices are paid slightly late. Preventing documents from being created in this case frustrates the logistics process. Instead it makes more sense to have an on-screen warning combined with a credit block. A credit manager should then analyze the situation to decide what action is appropriate. Let’s take a close look at the tools available:

• The classic check is on the total of open sales orders plus deliveries and non-paid invoices. However, with large blanket orders in the system this can be a distorted figure. In that case a dynamic check is more appropriate. With this approach, you can decide to take only orders scheduled for certain times (e.g., the following month) into account. Another parameter is the type of reaction. This can be either a credit block or a warning. If orders sit in the system for a long time, a warning could be appropriate, with a block on the delivery.
  
  
• Another approach is to focus only on high-value orders. This would be wise if your business volume is very high with largely anonymous and often one-time customers. In such a business, the transaction size often is the sole ground for risk assessment. For example, you could stipulate that any retail order over USD 2,000 will be checked with the credit department.
  
  
• Tampering with sales orders (e.g., changing the agreed payment term) can also be monitored in automated credit control through a check on a critical field change. For example, you could stipulate that any change in payment terms would trigger a credit block. This use of credit control is often unhelpful, however. It is better to check sales desk behavior through dedicated reporting, leaving the sales process unhampered. If changes in payment terms need to be adjusted retroactively as part of a new deal with a customer, for example, this would only cause difficulty.
  
  
• Credit management may also be based on a review of data stored in the customer credit master. If the last planned review data is passed, credit control is triggered. This ensures that review dates are updated. However, I have never seen this in use, as it makes the key business process of sales dependent on the regularity of the financial administration.
  
  
• Control can also be made dependent on payment behavior. This makes sense in a lot of cases. For example, a provider with monthly service could stipulate that no more than 50% of all outstanding invoices can be open. This would translate to no deliveries to a customer that has left more than 50% of its invoices unpaid, regardless of which invoice has been left unpaid, creditworthiness, or credit limit. Another possibility is to limit the period of non-payment. For example, if any invoice is not paid within three months, you do no new business with the customer. Again, in an environment with high transaction volume and anonymous customers, these are highly effective settings to limit the overall risk in individual cases. Also, you can communicate these policies to customers easily.
  
  
• A variant on the above option is to set the oldest open invoice tolerated. For example, anything open for longer than three months triggers a temporary block on your services to a customer.
  
  
• If a company is automatically dunning its customers in SAP, the dunning level can translate in a credit block. Essentially this means that a customer that has received a summons, or is threatened with one, is automatically excluded from new business.

Apart from these standard settings, you have other programming possibilities in user exits RVKPRFZ1, RVKPRFZ2, and RVKPRFZ3. You can include any logic you wish in these user exits. A note of caution: During the design, over-control often is tempting. It should be weighed against the effort required to assess and manage the resulting credit blocks.

In my business case, I want the system to block sales orders for selected customers. I can achieve this by blocking any sales order over USD 0.01 for a specified credit group (sales orders), combined with a special customer risk category.

I also want to check deliveries against the credit limits of customers. If sales orders remain in the system for long periods, the actual risk should be assessed when the goods leave the company. Delivery creation triggers this process. Therefore, this is the logical moment to check if the transaction should be processed. This check is only valid for certain customers. Intercompany flows as well as major customers are serviced regardless of their credit situation. Intercompany flows should not be added to the credit management workload. If another division is not paying according to the agreed terms, that should be discussed at the management level.

For major customers, blocks are rarely used to prevent delay of critical deliveries (band-stop claims). For these customers, monitor the credit situation using the credit master sheet. If payment behavior deteriorates in general, a senior credit manager contacts the customer to discuss the situation.

Customizing OVA8

Transaction OVA8 controls the settings of automatic credit control (Figure 7). I dealt with a large number of the settings in the paragraph above. Make selections by checking a box in the Checks area. Define these settings for combinations of credit groups (sales and/or delivery types) credit control area, and the type of customer (i.e., risk category). I will describe the credit control area and the type of customer in a second article. Enter this information in the top section of the screen.

Figure 7

Set checks in automatic credit control

The reaction (warning or error) is selected in the Reaction column. It is also possible to add details to the warning or error message (Figure 8), such as the amount over the credit limit.

Figure 8

Possible warning or error message types

Apart from a warning or error, in the column Status/Block, select whether or not the system will block the document for credit. As you can see in Figure 8, further detailing is possible for seasonal effects, allowing deviations and exclusions for specific situations:

• For a seasonal effect, you can allow a percentage on top of the regular credit limit, as shown in the Credit limit seasonal factor section of Figure 7. This is a typical setting, for example, in the beer industry, where customers tend to stock up prior to the summer season. You cannot manage the sudden bulk with the regular credit limit.
  
  
• It is possible to prevent released documents from being blocked again if the deviation in value does not exceed a given percentage or if the change is within a number of predefined days. Make these settings in the top right corner of Figure 7, in the section Released documents are still unchecked.
  
  
• In some cases you do not want credit control to kick in. For example, you define free-of-charge items in sales orders on the item level and cannot exclude them via the document type. It is possible to include a requirement in the credit settings, which must, of course, be developed locally. Do that in the Document controlling section of Figure 7.

I propose two settings for my business case:

• For the sales orders of risk-category suspect customers, set a block on any order over USD 0.01. No warning or error is needed, as you do not want the sales desk to inform the customer by mistake that there is a credit problem.
  
  
• For deliveries, use a static check against credit limits. I’ll cover the calculation of this check in part 2.