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 you create or change a sales order or delivery. 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). With each setting it is essential to weigh the gain in control against the effect on the logistic process.

Figure 1

Credit management in the sales flow

In part 1 of this series, I’ll deal with the settings for automatic credit controls in the sales process. Part 2 will describe credit management organization, credit limits, credit exposure calculation, and customer groupings.

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

Example of a credit management warning message. The system saves the document with a credit block

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). With this simple process you can prevent losses to known bad credit risks. You can capture new customers automatically and, at your discretion, they can undergo a review or receive a standard credit limit. At the same time it should be clear that each time a document is blocked, no further logistic processing is possible until a credit clerk has found time to investigate the issue. The design should therefore always take into consideration that it must be possible to release blocked documents within a very short time span (organizational capacity), and that no excessive blocking takes place.

Figure 3A

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

Figure 3B

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

I will 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 will 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. Depending on the business process, it may make sense to have stronger blocking for sales orders. This is certainly the case when you are manufacturing or purchasing the goods to order. You don’t want to incur manufacturing costs, tie up production capacity, or place a purchase order with your vendor if you are concerned the customer’s credit might not be good. In this case a credit block at the time of delivery is much too late.

On the other hand, if sales orders sit in the system for a longer period with multiple lines that are scheduled for various dates, an excessive credit block at sales order creation makes less sense and can do damage. 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 or order value 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 and, in overly large numbers, hampers an efficient supply chain. However, for some (suspect) customers, I might want the ability to review the order acceptance, so as not to overburden the logistics 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 companies selling directly to large numbers of consumers, 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 4A

Name the credit groups of sales documents

Figure 4B

Name 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. A useful exercise is to make an estimate of the documents concerned and use this in the discussions with process owners. How many sales order lines are you talking about? What percentage do you expect to be for suspect customers? How many clerks do you need to evaluate that type of number with half a day from order creation?

Figure 5A

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

Figure 5B

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 a document with a document type included in a credit group activates credit management.

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 and will damage the supply chain efficiency.

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 settings 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

Customize risk categories and define the credit management organization

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.

It is even possible to restrict the system reaction to a simple warning without a credit block. This might be considered in the case of order changes to remind the order desk employee that the order is for a suspect customer. However, as the order was released already, the warning can be ignored if the change has only a minor impact from a financial point of view (pull in, push out, change to an agreed payment term). Finance could monitor these changes periodically through checking order changes to critical fields.

Credit error messages 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. Also you can reduce the possible damage done through scheduled production orders and claimed inventory.

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 leading to an excessive number of unrealistic credit blocks. In this case a dynamic check can improve the efficiency of both the logistic and the credit process. With this approach, you can decide to take only orders scheduled for certain time windows (e.g. the following month) into account. Another parameter is the type of reaction. This can be a credit block or a warning. If orders sit in the system for a long time, a warning could be appropriate, but a block, if any, should be 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. It is even worthwhile to consider using this setting in any case to improve efficiency. Even for risky customers the evaluation of low value orders probably will cost the organization more in terms of hampering logistics and administration than the possible gain in preventing the occasional nonpayment. You should consider a minimum value for any order before it is passed on to the expensive mechanism of credit control. If combined with a payment behavior check (e.g. no more then 50% of invoices unpaid) this should not represent a financial threat and it gets rid of at least part of the unwanted hampering of the logistic flow.

• Tampering with sales orders (e.g. changing the agreed payment terms) 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. A warning providing the person changing the order will often be sufficient. Dealing with this setting, you should realize that a credit block automatically deletes the schedule lines, even for confirmed orders. In general there is no clear business case to have all changes to an already released order checked again.

• 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. This is truly topsy-turvy. Credit reviews should be planned without creating a threat to the logistic process.

• 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 nonpayment. 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 up front.

• 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 into 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 never 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. The intercompany logistic flow should function unhampered at all times.

For major customers, blocks are rarely used to prevent delay of critical deliveries (band-stop claims). For these customers, monitoring the credit situation using the credit master sheet is by far the preferred solution. 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 previous section. Make selections by checking a box in the Checks area. Define these settings for combinations of credit groups (sales and 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.

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 7, further detailing is possible for seasonal effects, allowing deviations and exclusions for specific situations:

Figure 8

Possible warning or error message types

• 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. If you forget this setting you will do damage during the most profitable period.

• 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. This setting should preferably not be too low. If an order is already released by the credit department a 10% increase should not trigger the whole blocking process.

• 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.