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.

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.
Step 2) In the next screen, enter the following.
- Enter the customer ID of the customer whose credit limits are to be maintained.
- Enter the credit control area.
- Select the Central data checkbox in the data selection block.
The entry screen with all three entries made looks like the screenshot below.
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.
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.
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.



