How to use the CHECK_CM report in SAP Credit Manag...

edina_j0zs4 · ‎2025 Feb 28

Report CHECK_CM can be used to analyze the credit management relevant information of a particular sales document in one step. It gives an overview of customizing settings and values stored in the relevant database tables. On S/4HANA the old ECC version could be used with limitations. In 2025 a new FSCM specific version of the report has been published by SAP. The blog explains how to use the report to investigate credit management related problems.

Disclaimer: The information is relevant for SAP S/4HANA Private Cloud (On-Premise) releases, specifically the processing of SD Sales documents. The focus is on the FSCM version of CHECK_CM report.

Content

Report availability
Executing the report
Interpreting the information in CHECK_CM report
Additional tips for troubleshooting

Report availability

Up to SAP S/4HANA 2023 release the classic ECC version of report CHECK_CM is pre-delivered in standard. This CHECK_CM report can still be used with SAP Credit Management (FSCM) for a general check, however, due to design changes some data are missing or marked red. The credit status VBAK/LIKP-CMPS_CM is not shown. VBAK/LIKP-KNKLI and VBAK/LIKP-CTLPC are marked red as the KNKK table is obsolete. When executing the report pop-up information messages occur (F4899) which can be ignored.

With SAP Note 3546203 an FSCM specific version of CHECK_CM report has been released for S/4HANA systems. It is advised to implement this note and start using the FSCM version for easier troubleshooting.

Executing the report

The report can be executed from SA38/SE38 transaction in foreground. (Background execution of the report is not meaningful, the report only contains information for analysis purposes for the user.) Input a sales order or delivery number and execute the report.
The ‘More Explanations’ flag just gives field descriptions.
The ‘Display Individual Status’ flag ensures that the different credit check statuses are listed. With FSCM this changed according to the new design. See KBA 2207394.

Interpreting the information in CHECK_CM report

The following section explains the information available in CHECK_CM report on the example of a sales order. There are some differences in case of deliveries, which are pointed out.

General FSCM settings:

In this section the implementation of BAdI UKM_R3_ACTIVATE can be checked. Also shows information whether FSCM is on local system or multi-system setup.
Implementation of the BAdI is not necessary on S/4HANA, the standard implementation is running per default. Improper implementation of the BAdI can cause missing data, see KBA 3520203.

Settings for credit check:

This part contains information on the credit check relevant master data in the sales document and configuration.
Also shows the active implementation of BADI_SD_CM.
Implementation of the BAdI is not necessary on S/4HANA, the standard implementation is running per default.

Type of Credit Check: TVAK-KLIMP = D – Automatic Credit Check >> Only supported credit check type!

Transaction OVAK: Credit check activation at sales order level
or
Transaction OVAD: Credit check activation at delivery and/or goods issue level

Requirement for Subseq.Functs: Standard requirement 101 in transaction OVB8 ensures that confirmed quantities are set to zero if the credit block is set. (Different behavior can be achieved by custom routine, see KBA 2306970.)

Key fields for Automatic Credit Check = Check here what is the relevant combination for the sales order/delivery. With this information go to transaction OVA8 and see the customizing settings for the credit check activation.

For SAP Credit Management the OVA8 entry is still required. Activate the credit check type, choose a reaction (A/B) and flag Status/Block indicator to get CMGST status determined.
To maintain the credit check steps that will be executed go to configuration of Check Rule. See KBA 2761313.

Settings for determining the credit control area of a document:
Credit Control Area determined in the sales document is stored either in VBAK-KKBER or LIKP-KKBER. From SD side the CCAr is still the organizational unit relevant for credit management. The CCAr is mapped to Credit Segment on FSCM side.
When report CHECK_CM is executed, function module SD_DETERMINE_KKBER runs in the background and compares the credit control area from the sales document with the current customizing settings (active at the time of CHECK_CM execution, so the report can be used to debug after configuration changes).

The KKBER field is shown either in green color or in red.
Green means: the credit control area which was determined at the time of sales order creation (VBAK-KKBER) matches with the actual customizing setting of the credit control area determination.
Red means: since the sales order creation the customizing setting for credit control area determination was changed as with current date a different credit control area would be determined.

Credit control area determination is based on different configuration options. The same logic is valid for S/4HANA releases. On SD side the KKBER is determined, and it is mapped to Credit Segment per configuration. See SAP Note 355242.
To reflect the customizing changes in existing sales documents run report UKM_RFDKLI20. See KBA 3444618.

Risk category:
Transaction OB01: Definition of the risk category for each credit control area
FSCM Transaction UKM_BP: Assignment of risk class to Business Partner on Credit Profile tab = UKMBP_CMS-RISK_CLASS

On FSCM side in SPRO the risk class must be created with matching values. There is no mapping table to convert risk category to risk class, the values need to be identical (e.g. risk class A means risk category A, this can be assigned on BP and in OVA8 transaction).

If OVA8 entry with the risk class maintained on BP doesn’t exist, then VBAK-CTLPC and VBAK-KNKLI fields will not be filled on the sales document. See KBA 3164215.

The risk category found during sales document processing is stored in the field VBAK-CTLPC/LIKP-CTLPC.
When report CHECK_CM is executed, a test runs in the background for the field UKMBP_CMS-CTLPC which reads the actual risk class from the master data.

Green means: The risk category which was determined at the time of sales document creation (VBAK/LIKP-CTLPC) matches with the actual risk category assignment in the credit master data (UKM_BP).
Red means: When sales document was created, risk category 'A' was maintained in UKM_BP for the relevant credit account. Since the sales order/delivery creation this setting for risk category was changed and with current date risk category = 'B' would be determined (FSCM_MD-CTLPC).
If no other configuration was changed except the risk category, just use the RVKRED09 report. See SAP Note 510034.

Credit group:
01 -> setting for Sales order in transaction OVAK
02 -> setting for Delivery in transaction OVAD
03 -> setting for Goods issue in transaction OVAD
Using custom credit group is possible. Corresponding OVA8 entry is necessary.

Credit Segment Data:

This section shows the Credit Segment assigned to the Credit Control Area and the determined Credit Account (VBAK/LIKP-KNKLI). The current credit limit and the current credit exposure – at the time of executing report CHECK_CM. Attention: This is not historical credit exposure data from the time of credit check/sales document creation.

Also, the BAdI implementation of UKM_CONV_TO_PARTNER is shown. This BAdI is required if the Business Partner number (FSCM side) and Customer number (SD side) are not matching.

Credit Status from VBUK (VBAK/LIKP):

If the entry under ‘Credit Status from Table VBUK’ is red this means that this check failed.
Overall credit status (VBAK/LIKP-CMGST) is determined from the SAP Credit Management check status (this is the actual credit check), FSCM technical error status, the Financial Document, Export Credit Insurance and Payment Card Authorization status. If one of the checks has a result 'Not OK', the overall status will be also 'Not OK' = Credit blocked.

For SAP Credit Management the individual credit check steps which failed are not shown in the report. This is due to the design changes with FSCM. Check the DCD or transaction UKM_LOGS_DISPLAY for further details.

The overall credit status can be Released (VBAK/LIKP-CMGST = D) and the individual statuses in the report will still show the previous failed state. That is per design to keep a record of the failed checks.

For further information on credit status determination and changes with SAP Credit Management (FSCM) see KBA 3196063.

Settings for Credit Update:

Update of the credit values is required for the limit check (static or dynamic credit limit check).
The overall design of credit exposure update and moving credit values with sales processing is described in KBA 2501945 and SAP Note 377165.

Transaction OMO1 - Update type of S066 is legacy data. Complete deactivation via OMO1 transaction is not advised on S/4HANA FSCM. The updates to the infostructures have been deactivated on code level.

Key Fields for Credit Master Data = for which customer and credit control area the values were updated.
Credit account - KNKLI:
The credit account in sales documents is always determined based on the PAYER (VBPA-KUNNR) partner function.
In case of parent-child relationship the credit account is always the lower-level (child, subordinate) partner. The higher-level partner is known only on FSCM side. See KBA 2706299.

If the credit account was changed since the sales document creation the field VBAK/LIKP-KNKLI and Business Partner appears in red and contains different numbers.
If the credit account was deleted since document creation, field Business Partner is empty.
In some cases the credit account VBAK/LIKP-KNKLI is missing. Check the following KBAs to investigate why credit account could be missing: 3164215 (risk class related), 3242488 (customer to BP number mapping).

In the Fields from Table VBAP (ETTYP from Table VBEP) section check in one step if the customizing was done correctly at the time of document creation regarding the credit value update.

These are:

CMPNT = Update of the credit value must be active for the corresponding item type. This field corresponds to field ‘Active receivable’ in transaction VOV7 or OVA7. See KBA 2786413.

FKREL = The item must have a billing relevancy to update the credit values. If an item is not relevant for billing or relevant for pro forma billing, no update occurs.

CMPRE = Credit price per unit. Credit price needs to be determined for the item. With zero credit price the credit value of the item will be zero also. In the pricing procedure used for pricing in the sales document, subtotal ‘A’ must be entered in a condition line for determining the credit value. This way the system is determined to use this subtotal for credit pricing. It does NOT necessarily have to be the same as the net value. See KBA 2708680.
In case of delivery document check the credit price on the corresponding sales order.

KBMENG = Confirmed quantity / Delivery quantity (LFIMG)
For the credit value calculation and update a confirmed quantity must exist in the delivery-relevant position. For order-related billing the order/target quantity is considered. For blocked sales orders the confirmed quantity is reset to zero (see KBA 2306970 how to keep the quantity).

In the most typical scenario, for sales orders the credit value of an item is the credit price (CMPRE) * confirmed quantity (KBMENG). For deliveries the credit price from the sales order is multiplied with the delivered quantity (LFIMG).

Additional tips for troubleshooting

The CHECK_CM report is the best place to start analysis on a credit management related problem. In many cases missing configuration is the root cause for no credit check or credit exposure update. The above description explains what are the prerequisites.

If everything looks correct in CHECK_CM report, then look at the sales document and its changelog. What is the current credit status? Was it created with the expected credit status and changed later? Note the time of creation/change and look at the DCD or the UKM_LOGS_DISPLAY entry to find out more about a past credit check.

OVA8 configuration needs to be confirmed as well in case of credit check related problems. Is the SAP Credit Management activated with Reaction and Status/Block setting? Is there a ‘No check’ routine which might bypass the credit check?

Then looking up the business partner in UKM_BP to check to confirm if it is correctly maintained with risk class, check rule, credit segment data. On the credit segment level, a Credit Check Simulation can be triggered. However, the simulation only reflects the credit check outcome for the current time, not for past cases.

In SPRO the check rule and maintained credit check steps can be further analyzed if even the simulation is not showing the expected outcome.

A quick check on the liability category configuration can help to see whether these are set to statistical (so not included in credit exposure for credit check). Also confirm that the Check/Grid setting is not set for any SD liability categories (100, 400, 500).

For credit exposure update troubles looking at the BADI_SD_CM and UKM_FILL implementations can help as well. Is there coding in the methods (empty methods lose the data)? Is that coding correctly handling the liability updates?

There are some complex scenarios where the credit exposure update ends with inconsistency, these require further expert analysis.

For SAP to successfully find the root cause of a credit check or credit exposure update problem a reproducible example is necessary, but the above information can help with the initial troubleshooting.

The following blogs also provide further information:

References:

SAP Note 3546203 - CHECK_CM report for FSCM Credit Management
KBA 1479897 - How to use report CHECK_CM - ECC version
KBA 3565384 - How to use report CHECK_CM - FSCM version
KBA 2788718 - Configuration checklist for SAP Credit Management (FSCM)
SAP Note 355242 - Determination of Credit Control Area
SAP Note 510034 - Changing the risk category in Transaction FD32
KBA 3520203 - Missing credit master data causing no credit check or credit value update (FSCM)
KBA 3444618 - UKM_RFDKLI20 - Recreating SD Credit Master Data in FSCM
KBA 3164215 - Credit account and risk category missing from sales documents (FSCM)
KBA 2706299 - Parent-child relationship of business partners for credit check in SAP Credit Management (FSCM)
KBA 3242488 - Conversion of customer nr. to BP number in SAP Credit Management (FSCM)
KBA 3196063 - Credit check results and credit status of a sales document
KBA 2761313 - Maintain Credit Checks for SAP Credit Management (FSCM)
KBA 2207394 - FSCM less credit checks in OVA8
KBA 3352931 - Unexpected credit block due to missing authorization
SAP Note 377165 - Update open credit values for credit management
KBA 2501945 - How credit value is calculated and moved across credit exposure categories
KBA 2742707 - Correction and frequent causes of inconsistent SD credit values (liability cat. 100, 400, 500) - FSCM
KBA 2786413 - Role of 'Credit active' indicator in credit management
KBA 2708680 - How to configure the pricing procedure for credit value update (VBAP-CMPRE)
KBA 2306970 - How to keep the confirmed quantity when the sales order is credit blocked
KBA 3491054 - How to find reproducible example for credit exposure inconsistency