How to do an SAP credit limit mass update
PostNow.ai does an SAP credit limit mass update on ECC by replaying a recording of FD32 for each Excel row: customer, credit control area, the new credit limit and, if your review sets them, risk category and next review date. With PostNow.ai Mass Change you first download the current values from table KNKK into the sheet, edit the limits in Excel, and post only the rows you changed, after a review screen lists the old and new value of every change. A recording is the route because SAP ships no BAPI that writes classic credit limits, and SAP's own credit mass change (F.34) resets review dates, not limits. On S/4HANA, FD32 is gone: the limit sits in a credit segment of the business partner (role UKM000, transaction UKM_BP), SAP's mass change UKM_MASS_UPD3 recalculates limits by rule, and the released interface for explicit values is the Credit Management Master Data OData API.
- The key is customer plus credit control area, not company code. One credit control area can serve several company codes, and its limit covers all of them.
- Saving a lower limit blocks nothing by itself. The next credit check on an order, delivery or goods issue does. Put current exposure next to every reduction before you run the file.
This page covers credit limits only: the classic FD32 data in ECC and the credit segment data of SAP Credit Management in S/4HANA. The customer records the limits hang on are covered in customer master upload (XD01), and what a credit block means for an uploaded order is in VA01 mass upload. For choosing a method across all SAP objects, see SAP mass upload from Excel.
How PostNow.ai mass-updates credit limits in FD32
PostNow.ai treats an FD32 change as a recorded-transaction template with a Mass Change binding: a designer builds it once against your ECC system and publishes it, and the credit team runs each review cycle through it under their own SAP login.
1. Record FD32 once
Press Record, enter one customer and credit control area on the FD32 initial screen, select the Status view, change the credit limit (and the risk category or next internal review date, if your review sets them) and save. PostNow.ai records through SHDB and replays with CALL TRANSACTION, so FD32's own field checks run on every row. Recording mode needs PostNow.ai's ZPOSTNOW_* objects in the SAP system, installed once per system. How to record so a recording replays is in the BDC recording guide.
2. Map the columns and lock what should not vary
Customer and credit control area go to RF02L-KUNNR and RF02L-KKBER on the first screen; the new limit goes to KNKK-KLIMK and the risk category to KNKK-CTLPC on the Status screen. Give the credit control area and the risk category a value list and switch on Restrict, so Validate refuses an area your team does not own or a risk category that does not exist. Set the date format on the review-date column.
3. Bind Mass Change to KNKK
In the Mass Change designer, bind the template columns to KNKK: customer and credit control area as keys, limit and risk category as download columns. Criteria such as credit control area, risk category or credit representative group decide which customers come down. Max Rows starts at 100, and PostNow.ai asks for confirmation above 500. Publish the template; operators then fill in criteria values only and cannot change the binding.
4. Download, edit, review
Download from SAP writes the current values into the sheet and keeps a hidden copy of what came down. The credit team edits limits in Excel. Review changes shows "N changed of M rows" with the old and new value of each changed column, and Update changed rows posts those rows and no others. A value retyped as 250000 where SAP had 250000.00 does not count as a change.
5. Debug, Simulate, approve, run
Debug replays a row in SAP GUI in the foreground, so you see each FD32 screen. Simulate on a recording without a Simulate OK-code runs the screens with the save removed; PostNow.ai's full-check Simulate codes cover FI posting transactions such as FB50; on FD32, Simulate proves the screens and field checks, and Run, or Debug on a test client, proves the save. If an approval policy covers the template, the post waits until someone other than the submitter approves exactly these changed rows.
6. Read the Run Log, retry what failed
Each row gets SAP's message in the Run Log. Retry Failed re-posts only rows whose Run Log starts with ERROR, scanning from the Start Row down. Every row's outcome also goes to PostNow.ai's central audit with template, SAP system, client and SAP user.
Unlike the free SAP upload templates, the credit limit template is built in your own system, because the recording is specific to your FD32 screens. The general Mass Change pattern (download, edit, post changed rows) is explained in SAP mass change.
Which BAPIs and SAP tools change credit limits: ECC vs S/4HANA
PostNow.ai uses an FD32 recording on ECC because SAP releases no BAPI for this job; on S/4HANA it reads and reviews credit data, and posting goes through one of SAP's own routes. This is what SAP offers for a credit limit mass update, release by release:
| Route | Release | What it changes | Use it when |
|---|---|---|---|
| PostNow.ai: FD32 recording with Mass Change | ECC | Any field on the FD32 screens you recorded, one row per customer and credit control area | A review file with explicit new limits; the route this page builds |
| PostNow.ai: SAP Query on the credit segment tables | S/4HANA | Read-only: it reads current credit segment limits into Excel for the review | Preparing and signing off an S/4HANA review before one of the S/4HANA routes below posts it |
| F.34 (Credit Management - Mass Change) | ECC | SAP Help documents the credit mass change for moving the next review date for a group of customers; practitioners report the limit itself is not offered | Overdue review dates are blocking postings; not for new limit values |
| XD99 / MASS mass maintenance | ECC | KNKK-KLIMK is not available for change in XD99 (KBA 2637811) | Not for limits |
Function module CREDITLIMIT_CHANGE | ECC | KNKA and KNKK, controlled by flags UPD_KNKA / UPD_KNKK, as practitioners describe it | Only after SE37 shows it remote-enabled in your system; it is not a BAPI |
UKM_BP | S/4HANA | One business partner's credit profile and credit segments, by hand | Single changes |
UKM_MASS_UPD3 (Mass Changes › Credit Limit) | S/4HANA | Re-evaluates the rule for scoring and credit limit calculation for the selected partners; test run, simulation or update run | Limits that follow a formula, not a list of values |
OData API Credit Management Master Data (API_CRDTMBUSINESSPARTNER) | S/4HANA Cloud (SAP_COM_0740); on-premise from 2022 | Entity CreditManagementAccount per partner and credit segment, including CreditLimitAmount and CreditLimitValidityEndDate | Explicit values from another system, usually set up by your integration team |
SOAP service interfaces of SAP Credit Management, such as CreditManagementAccountChangeNotification_In and the CreditLimitChangeRequestERP services | S/4HANA | Change credit account data, or create and change credit limit requests that go through approval | System-to-system integration set up by your integration team |
| Migration Cockpit object "Customer - extend existing record by credit management data" | S/4HANA | Adds credit management data to customers that already exist | A migration project's one-off load |
Recording of UKM_BP | S/4HANA | SAP states that batch input in transaction BP is not supported (KBA 1951318); the business partner dialog runs on BDT | Do not build on it |
Why not a BAPI? On ECC no BAPI writes KNKK, and SAP's mass tools stop short of the limit itself, which is why a recorded FD32 is the standard answer. On S/4HANA there is no BAPI for credit segment data either; projects that load it by program wrap function module UKM_DB_UKMBP_CMS_EXECUTE in their own code. The general trade-off is in BAPI vs BDC in SAP.
Credit control area, not company code: what FD32 is keyed on
In ECC a credit limit belongs to a customer in a credit control area (table KNKK). A credit control area can monitor customers across several company codes, and each company code belongs to exactly one area, so PostNow.ai's template keys every row on customer plus credit control area.
| Field in the credit file | Table-field | FD32 view | What it does |
|---|---|---|---|
| Credit limit | KNKK-KLIMK | Status | The value the credit check compares exposure with |
| Risk category | KNKK-CTLPC (check table T691A) | Status | Selects which automatic credit checks run (OVA8) |
| Credit representative group | KNKK-SBGRP (T024B) | Status | Carried into orders; used to select blocked documents for release |
| Customer credit group | KNKK-GRUPP (T691B) | Status | Grouping for reports and release lists |
| Next internal review | KNKK-NXTRV | Status | The date F.34 resets |
| Total credit limit / individual limit | KNKA-KLIMG / KNKA-KLIME | Central data | Ceiling across all areas, and the most any one area may get |
- Ask for the area map first. Which credit control areas exist and which company codes feed each one decides the row count. A customer trading through three company codes in one area has one limit, not three.
- Central data can cap the area limit. If a customer carries a total or individual limit in central data, an area limit above it is refused; practitioners raise the central limit first. Record central data too, or run it as a separate template.
- Amounts are in the area's currency. SAP manages the credit limit in a credit currency set per credit control area, not in the company code currency. A file column labelled "EUR" against a USD area is a wrong limit, not an error.
- Sales orders find the area by derivation. SAP Help lists the sequence: user exit, distribution channel (sales area assignment), customer master, then the company code of the sales organisation. Load the limit in the area your orders actually derive.
What a lower credit limit does to open orders
PostNow.ai changes the limit through FD32, and saving a lower limit there is a master data change, so no order is blocked at that moment. The block comes from the next credit check that runs on a document, so a reduction lands on the order book over the following days, in whatever order documents get checked.
- What counts as exposure. Open orders, open deliveries, billing documents not yet passed to accounting, open items in receivables and special liabilities.
KNKKcarries receivables (SKFOR), special liabilities (SSOBL) and a sales value (SAUFT); FD33's Status view shows the total the check uses. - When the check runs. OVA8 sets the checks per credit control area, risk category and credit group, and the credit groups decide whether orders, deliveries or goods issue are checked. A new order for a customer now over the limit is saved and blocked, not rejected.
- Orders released earlier. They keep their release until something checks them again: a change to the order, a delivery or goods issue check, or a re-check job such as
RVKRED09, which SAP describes as re-checking released documents once their release validity has expired. - Where the blocks land. Blocked documents carry credit status
Band wait in the release lists, in ECC usually VKM1. Each one is work for someone in credit control.
Put the exposure in the sheet. PostNow.ai's Report Library has Credit Management 360 (SD-05), which brings total limit, area limit, receivables, special liabilities, risk category and next review date per customer and credit control area into Excel; operators can run it under their own SAP login. It reads KNKA and KNKK, so it has no open order or delivery values. Run it next to the Mass Change download, look up receivables per row, and flag every new limit that is below what the customer already owes.
Worked example: annual review for credit control area 1000
PostNow.ai handles this with one published FD32 template with a Mass Change binding, run by a credit analyst. Credit control area 1000 serves company codes 1010 and 1020 and holds limits in USD. The review covers every customer in risk categories 001 and 002.
- Download. The analyst enters credit control area 1000 and the two risk categories as criteria, raises Max Rows to 400. 312 customers come down with their current limit and risk category.
- Add the exposure. SD-05 for the same area goes into a second sheet. An
XLOOKUPon customer and area puts receivables and special liabilities next to each row. - Edit. The analyst raises 41 limits and lowers 9. Customer
200371goes from 150,000.00 to 90,000.00 against receivables of 112,400.00. Customer200388moves to risk category003. Two of the other lowered limits are also below receivables. - Decide the cuts. Credit control phases
200371: 120,000.00 now, 90,000.00 next quarter. The other two stand, and their account managers are told. - Review and approve. Review changes shows "50 changed of 312 rows", each with old and new limit. The template has an approval policy, so the credit manager approves these 50 rows in the portal; the analyst cannot approve their own run.
- Pilot, then post. Debug replays
200371so the analyst sees the Status screen take 120,000.00. Update changed rows posts the 50. One row ends in ERROR: a colleague had customer200402open in FD32, and SAP's lock message is in the Run Log. After they close it, Retry Failed posts that row. - Prove it. The Change Documents report (G-01) filtered on object class
KLIMand today's date lists 50 changes toKLIMKand one toCTLPC, with old value, new value and user.
Checklist before an SAP credit limit mass update
PostNow.ai enforces formats and allow-lists in the template; this list covers the business decisions credit control makes before the run.
- You know which credit control areas exist, which company codes feed them and which currency each area uses.
- The file has one row per customer and credit control area, and its amounts are in the area's currency.
- Central total and individual limits are high enough for the new area limits, or a central-data run goes first.
- Every reduction has been compared with receivables and special liabilities, and credit control has signed off the ones below exposure.
- Risk category changes have been checked against OVA8: a new category can switch on checks the customer never had.
- The Mass Change download is from today, so nobody's FD32 change since then gets overwritten.
- Two rows have been replayed in Debug in a quality client and checked in FD33.
- An approver is named for the template, and someone owns the blocked orders the cuts will produce.
Credit limit upload errors and what they mean
PostNow.ai writes SAP's message into the Run Log of each row; these are the problems a first credit limit mass update most often meets.
| What you see | What it usually means | Fix |
|---|---|---|
| An authorisation message when FD32 opens the area | The user lacks F_KNKA_KKB (credit control area) or F_KNKA_MAN; field groups under F_KNKA_AEN can also protect single fields | Ask security for the area; PostNow.ai runs under the operator's own SAP authorisations |
Dump DYNPRO_FIELD_CONVERSION in SAPMF02C | The documented FD32/FD33 dump (KBA 2647311); in a batch run, a value that does not fit the screen field is the first suspect | Replay the row in Debug and check the amount as it lands in the Credit limit field |
| The limit field cannot be changed in XD99 | By design: KNKK-KLIMK is not offered there (KBA 2637811) | Use the FD32 recording |
| F.34 runs but limits are unchanged | F.34 is documented for moving the next review date, not for setting limits | Use the FD32 recording for limits, F.34 for review dates |
A UKM_BP recording behaves differently in replay | Batch input in the BP dialog is not supported (KBA 1951318) | Use a released interface on S/4HANA, see below |
UKM_MASS_UPD3 leaves a limit unchanged, or changes it to a calculated value | It re-evaluates the credit limit rule; it does not read values from a file | Run the test or simulation run first; for explicit values use the API |
| PostNow.ai: "No rows in the Run Log column (A) are marked ERROR" | Retry Failed found nothing to re-post from the current Start Row down | Set Start Row back to 2 after a pilot |
For a failed row, AI Review in the run diagnostics explains SAP's messages in plain language. By default it receives the messages, the transaction and the field structure, never the cell values.
Audit and approval of credit limit changes
PostNow.ai puts the control before the change: with an approval policy on the template, Run is blocked until someone other than the submitter approves, and the approval is tied to a fingerprint of the exact data, so an edited sheet needs a new one. A Mass Change post is gated the same way, scoped to the changed rows. Plan for portal availability: if the portal cannot be reached, the approval check lets the run through.
- PostNow.ai's record. The Run Log line per row, and the central audit with template, SAP system, client, SAP user, result and message for every row.
- SAP's record on ECC. FD32 changes write change documents under object class
KLIMinCDHDR/CDPOS, with fieldKLIMK, old and new value. SAP's reportRFDKLIABdisplays credit master changes across accounts; PostNow.ai's Change Documents report (G-01) puts the same tables into Excel, filtered by object class, user or date. - Authorisations.
F_KNKA_KKBlimits users to credit control areas. On S/4HANA, SAP Credit Management controls access per credit segment withF_UKM_SGMT, with activities such as change (02) and display change documents (08).
How approvals, roles and the template library work for a whole team is covered in Excel to SAP automation.
SAP credit limit mass update in S/4HANA: UKM_BP and credit segments
On S/4HANA, PostNow.ai pulls current credit segment limits into Excel and builds the review there, and the post goes through one of SAP's own routes. Classic credit management (FI-AR-CR) is replaced by SAP Credit Management (FIN-FSCM-CR), so FD32 and its recording are gone. The data model changes too:
- Business partner, role UKM000. Credit data is an enhancement of the business partner in role SAP Credit Management (
UKM000), maintained inUKM_BP: the Credit Profile tab holds the rule for scoring and credit limit calculation, the check rule and the risk class; the credit limit sits in the credit segment data. - Credit segment instead of credit control area. Customizing assigns each credit control area to a credit segment, and the main credit segment can add up the exposure of the others. A converted file keys on business partner and credit segment.
- Limits can be calculated. The rule can derive the limit from a formula. SAP's base licence covers limits set by hand; automatic calculation needs an additional licence. If your system calculates limits, a file of fixed values works against the rule.
- Mass tools.
UKM_MASS_UPD5assigns roleUKM000,UKM_MASS_UPD2recalculates the score andUKM_MASS_UPD3re-evaluates limits for the selected partners, optionally creating missing credit segments. The Fiori job "Update Credit Limit for Business Partners" does the same from the Schedule Credit Management Jobs app.
What PostNow.ai does for an S/4HANA credit review
- Read the current limits. A designer builds an SAP Query on the credit tables (
UKMBP_CMSfor the credit profile,UKMBP_CMS_SGMfor credit segment data) joined to the business partner, and saves it for the team. The credit analysts run it from My Reports or Team Reports under their own SAP login; they don't build queries. The Credit Management 360 report (SD-05) reads the classic tablesKNKA/KNKK, so on S/4HANA the query on theUKMtables is the source of record. - Build the review in Excel. One row per business partner and credit segment, current limit next to the proposed one, every cut flagged, and the agreed list signed off by credit control before anything posts. Check each cut against the partner's exposure in
UKM_BPor your credit exposure report, as in the ECC worked example above. - Post through the route your system supports. Rule-based limits go through
UKM_MASS_UPD3(run the simulation first). Explicit values go through SAP's Credit Management Master Data OData API, where a PATCH onCreditManagementAccountfor one partner and segment changesCreditLimitAmount, usually built by your integration team.
A BAPI-mode route. PostNow.ai's BAPI mode can call a remote-enabled function module in your system. SAP releases none for credit segment data, so this route means a custom Z wrapper your team writes and keeps working through every upgrade. Weigh that against the OData API before you build it.
If the limits are part of a conversion or a first load, the Migration Cockpit object for credit management data is the planned route; see SAP Migration Cockpit.
What to plan for in a credit limit upload
PostNow.ai posts credit limits through FD32's own screens, so SAP's own credit rules apply to every row.
- Compare each cut with exposure in the sheet. Put the SD-05 lookup next to every new limit, so each reduction is checked against exposure before the run.
- Download fresh before you edit. Mass Change compares your sheet with its own download. A limit someone changed in FD32 after your download is overwritten by your row if you changed that row, so download again just before the review.
- Prove the save with Run or Debug. On FD32, Simulate checks screens and fields; Run, or Debug on a test client, proves the save.
- Use a single-record or flat-row template. Mass Change works with both, and a designer builds the binding.
- Restore limits from the download. Stop cancels the rows not yet sent; to put a changed limit back, post its old value from the download.
- Plan the run with the analyst. Recorded runs start from the user's own SAP login on their own computer, when the user starts them.
- On S/4HANA, post through SAP's route. PostNow.ai reads S/4HANA credit segment data and builds the review; the post goes through
UKM_MASS_UPD3, the Credit Management Master Data API via your integration team, or a custom function module.