FD32 in SAP: Credit Control Area Tutorial

⚡ Smart Summary

Credit control in SAP limits exposure to bad debt by assigning each customer a credit limit inside a credit control area, and transaction FD32 is the classic screen where that limit is maintained.

  • 🔘 Scope: One credit control area can serve every company code, or each company code can carry its own area.
  • ☑️ Transaction: FD32 opens the customer credit master, where the customer, the credit control area and the data sections are selected first.
  • Central data: Total amount caps credit across all areas, while the individual limit caps credit inside any single area.
  • 🧪 Status data: The credit limit, risk category and review dates on the status screen drive the automatic credit check.
  • 🛠️ Configuration: OB45, OB38, OVFL, OB01 and OVA8 create the credit control area and the checks that use it.
  • 📈 S/4HANA: FD32 is not available in SAP S/4HANA, where the business partner role UKM000 replaces the classic credit master.

Maintaining a customer credit limit with FD32 in SAP

Multiple outstanding receivables or bad debts can have a considerable impact on a company’s performance. Credit control reduces that risk by defining a credit limit for each customer and by checking every new order against it.

What Is a Credit Control Area in SAP?

In SAP, credit and risk management takes place in the credit control area. If credit management is centralised, one credit control area can be defined for all company codes. If the credit policy requires decentralised management, a credit control area can be defined for each company code or for each group of company codes.

A credit control area is therefore the organisational unit that defines and controls customer credit limits. It carries its own currency, and every receivable posted in accounts receivable raises the credit exposure recorded against it.

The credit control area governs three things in particular.

  • Limit: The maximum receivable value a customer may hold at any time within that area.
  • Exposure: The running total of open items, open orders, open deliveries and open billing documents.
  • Reaction: Whether an order that breaches the limit is warned about, blocked, or allowed through.

Credit control area master data is maintained per customer, and the walkthrough below shows how.

How to Maintain Customer Credit Limits in FD32 (Step by Step)

Step 1) Enter transaction code FD32 in the SAP command field.

The command field sits at the top left of the SAP GUI screen, as shown below.

SAP command field with transaction code FD32 entered

Step 2) In the next screen, enter the following.

  1. Enter the customer ID of the customer whose credit limits are to be maintained.
  2. Enter the credit control area.
  3. Select the Central data checkbox in the data selection block.

The entry screen with all three entries made looks like the screenshot below.

FD32 initial screen with customer, credit control area and Central data selected

Step 3) In the next screen, maintain the credit management data for the customer.

The central data screen holds the total amount and the individual limit, as the screenshot shows.

FD32 central data screen showing the total amount and individual limit fields

Step 4) Press the Save button on the SAP standard toolbar to save the changes made to the credit limits.

The Save button is the disk icon at the left of the toolbar, highlighted below.

Save button on the SAP standard toolbar

A message in the status bar confirms that the changes have been made. The new limit applies from the next credit check onward, so an order that is already blocked has to be released separately.

Credit Control Area Configuration and Related SAP T-codes

FD32 only maintains master data. The credit control area itself, and the checks that consult it, are set up in Customising, so a limit that appears to have no effect is usually a configuration gap rather than a master data error.

T-code Purpose
OB45 Define the credit control area, its currency and its update group
OB38 Assign a company code to a credit control area
OVFL Assign a sales area to a credit control area
OB01 Define the risk categories available in a credit control area
OVA8 Configure automatic credit control for a credit control area, risk category and credit group
FD32 / FD33 Change and display customer credit master data
F.31 / F.35 Credit overview and credit master sheet reporting
VKM1 / VKM4 List and release sales documents blocked by the credit check

Two prerequisites are worth confirming before FD32 is opened: the customer must already exist in the company code, and the company code must be assigned to the credit control area being entered. Where the exposure figure looks wrong rather than the limit, the SD side of the configuration is covered in the SAP SD credit management guide.

Key Fields on the FD32 Credit Management Screens

FD32 is a multi-screen transaction, and the data selection block on the entry screen decides which screens open. The fields that matter most are listed below.

Screen Field Meaning
Central data Total amount Overall credit the customer may receive across every credit control area
Central data Individual limit Maximum credit the customer may receive inside any single credit control area
Central data Currency Currency in which the central limits are held
Status Credit limit Limit granted in the credit control area that was entered on the first screen
Status Risk category Key that decides which automatic credit check from OVA8 applies
Status Credit representative group Group of employees responsible for monitoring the account
Status Last and next internal review Dates on which the limit was last reviewed and is next due for review
Payment history Payment data Cleared items, average days in arrears and the largest outstanding amount

The total amount and the individual limit work together: the individual limit caps any one area, while the total amount caps the sum of all areas. Setting an individual limit above the total amount is accepted but has no practical effect. Review dates feed the credit review worklist, so leaving them blank quietly removes the account from that list.

Credit Management in SAP S/4HANA: What Replaces FD32

Classic SD credit management is not available in SAP S/4HANA. It is replaced by SAP Credit Management, part of Financial Supply Chain Management, and the transaction codes change accordingly.

  • Master data: Credit data moves onto the business partner in role UKM000, maintained with transaction BP or UKM_BP instead of FD32.
  • Segments: The credit control area is replaced by a credit segment, and limits are held per segment rather than per area.
  • Blocked documents: Documented credit decisions in UKM_MY_DCDS replace the classic release lists.
  • Tables: The classic KNKA and KNKK credit master tables give way to the UKMBP_CMS tables, and the S066 and S067 exposure structures are replaced as well.
  • Conversion: Existing credit master data is migrated during a system conversion, so limits do not have to be keyed again.

Anyone still running SAP ERP Central Component keeps FD32 exactly as described above, and the concepts carry across cleanly: a limit, a risk category and an exposure figure exist on both sides. A worked description of the business partner role is published in this SAP Community article on SAP Credit Management. Downstream, the same customer balances drive dunning and the clearing corrections covered in resetting cleared items.

FAQs

The automatic credit check reacts with a warning, an error or a delivery block, depending on the setting for that risk category. Blocked sales documents stay in a release list until a credit representative approves or rejects them.

A static check compares the limit against total open items, orders, deliveries and billing documents. A dynamic check adds a credit horizon, so orders scheduled beyond that horizon are ignored. Both are configured per risk category.

Exposure is held in summary structures that can drift out of step after an update error. Reorganisation report RVKRED77 rebuilds the credit values for the affected customers and credit control areas, after which the figures match the open items again.

Classic credit data lives in its own tables rather than in the general customer master views: KNKA holds the central data and KNKK holds one record per credit control area. That is why the data is maintained through FD32 and not through the customer create screens.

Machine learning models score payment behaviour, days in arrears and external ratings to propose a limit or a risk category, and they rank collection worklists by likelihood of payment. The proposal still needs human approval before it reaches the credit master.

Yes. Assistants such as GitHub Copilot draft the ABAP, batch input or scripting code behind a mass credit limit load and the queries behind an exposure report. Test every generated program in a sandbox client first.

The limit is held in the currency of the credit control area, which is fixed when the area is defined. Documents posted in other currencies are translated into that currency before the exposure is compared with the limit.

Every change to the credit master is logged, and the change documents can be listed for a customer and credit control area. The log shows the old value, the new value, the user and the date, which is what an audit of credit decisions normally asks for.

Summarize this post with: