What happens to SAP credit management (FI-AR-CR) in an S/4HANA migration?

Why classic credit management does not survive the conversion

Most of what ECC does keeps working in S/4HANA, which is why so many teams are surprised that credit management does not. SAP lists classic FI-AR credit management as a simplification item with a hard successor: SAP Credit Management, the FSCM component that existed as an optional add-on in ECC and is now the only credit engine in S/4HANA. The old credit master data per credit control area, the risk-category-driven automatic credit control in sales, and the customer-level credit limit maintenance are not carried across by the technical conversion. If the source system uses credit checks at all, the migration has to happen, and the pre-checks will tell you so.

The reason is architectural rather than arbitrary. Classic credit management was a sales-and-receivables feature bolted onto the customer master. FSCM credit management is a Business Partner role, which fits the S/4HANA master-data model, and it is built to consume exposure from more than one system and to express credit policy as rules rather than a single number in a table. That design is what lets S/4HANA support scoring, documented credit decisions, and a credit profile that moves with the partner instead of being re-keyed per control area.

What changes: the objects and the vocabulary

The migration is easier to plan once the mapping between old and new is explicit. Most of the concepts have a direct counterpart, but the counterpart usually carries more capability than the original, which is where the policy decisions creep in.

• Credit control area becomes credit segment. A credit segment is the unit against which a limit and an exposure are held; the common pattern is one segment per former control area, plus a main segment that aggregates them.
• Risk category becomes risk class. Risk classes are assigned to the Business Partner's credit profile and drive which checks apply and how strict they are; they are also where a scoring rule can assign the class automatically instead of a credit analyst keying it.
• The customer credit master becomes the credit-management role on the Business Partner (the FSCM credit role, on top of the customer role created by the CVI conversion). Limits, risk class, and credit profile live there.
• Automatic credit control in sales becomes the credit check configured per credit segment and check rule, integrated with sales documents through the same blocking and release mechanics order managers already use.
• Fixed limits gain formulas. Limit and scoring formulas are maintained as rules, so a policy such as 'limit equals a multiple of average monthly billing, capped by risk class' can be expressed in configuration rather than a user exit.

How the migration actually runs

SAP delivers a guided sequence in the IMG for migrating from classic to FSCM credit management, and it separates the work into configuration, master data, and exposure. Configuration first: create the credit segments, define risk classes, set up the check rules and any formulas, and assign the segments to the sales areas and company codes that previously pointed at a control area. Master data next: the migration reads the classic credit records and creates the credit-management role on each Business Partner, carrying over limits and mapping risk category to risk class. Exposure last: open orders, deliveries, and receivables are recalculated into the new exposure tables so the first credit check after go-live is working from real numbers rather than zero.

Two dependencies decide the schedule. The Business Partner conversion must be complete first, because the credit role hangs off the BP, and the credit migration therefore cannot start until CVI is synchronized. And the exposure rebuild is only as good as the open-item data underneath it, which is why credit management is one of the first places a data-readiness problem in receivables shows up after conversion. Plan the credit migration as a late-stage activity in the sandbox conversions and run the exposure rebuild more than once, comparing totals per segment against the ECC control area balances before you trust them.

The part nobody budgets for: custom credit logic

Credit is one of the most heavily customized corners of a mature ECC estate. Teams wrote logic in the sales-order user exits and in the credit-check exits to do things the classic engine could not: a limit that flexes with seasonality, an exemption for a strategic account, a hold that fires on overdue days rather than total exposure, a manual override that emails the credit manager. In S/4HANA those exits still execute, but the credit engine they were compensating for is gone, and most of what they did is standard capability in FSCM: formulas, risk classes, documented credit decisions, and workflow-based release.

This is the same chain we describe for MV45AFZZ: read the business rule in the exit, ask whether FSCM delivers it as standard, and retire the exit if it does. On a reference estate — a live ECC system used to validate this method, not a specific customer's result — a where-used analysis across the custom code that touched the credit tables and the sales-order exits was part of an assessment in which roughly 44% of 356 inventoried custom objects were assessed as retirable because S/4HANA already delivers the capability. A customer's numbers come from their own system, but credit is consistently one of the richest sources of retirable code, because the ECC engine was thin and the business rules were real.

The decision belongs to the credit manager and the order-management process owner, not to the developer who owns the exit. Retiring a credit exit is a decision to adopt FSCM risk classes and formulas as the credit policy, and it should be made with evidence of what the exit does today and how often it fires, not from a code listing.

Where agents help today, and where they do not yet

The analytical front of this work is well suited to an agent reading the live system through governed, read-only tools: count credit records by control area and risk category, profile how many customers actually carry a limit and how many limits have been touched in the last two years, and trace which custom objects and exits read or write the credit tables. That produces the finite, evidenced list that a fit-to-standard workshop needs, and it is available now.

Where the resulting configuration has to land — credit segments, risk classes, check rules — the agent drafts a governed customizing transport and the customer's change board decides whether it lands; development systems only, never touching production on its own. Our functional-testing agent, which would take migrated credit profiles through order entry, delivery, and billing to prove that blocks and releases fire as intended, is in build and design preview, not shipped. SAP describes its own direction as agent-led transformation with a claimed reduction of more than 35% in migration effort (SAP News, Sapphire 2026); that is SAP's figure. Credit management is a fair place to test it, because the technical migration is small and the effort is dominated by policy decisions and custom-code disposition, which is exactly the work that evidence from the live system shortens.