SAP Credit management

It tracks each customer’s credit exposure (open orders, deliveries and receivables) against an assigned credit limit, and performs credit checks at order/delivery. If the customer is over limit or has overdue items, the document is blocked for review, preventing further exposure to a risky customer.

• Credit limit per customer/credit account.
• Credit exposure: open orders + deliveries + receivables.
• Credit checks: at order and/or delivery.
• Blocked documents released by credit managers.

One term to be precise about: the credit account is not always the customer on the order. Where a group of companies buys under one credit arrangement, several customers can share a credit account, so the limit applies across all of them. That is why a customer with plenty of headroom of their own can still be blocked.

A credit limit is only meaningful against a definition of what is committed, and that definition is configurable, which is why two systems can treat the same customer differently.

Exposure typically includes open receivables, invoices posted and unpaid; open items in dispute, depending on configuration; open deliveries, goods shipped and not yet invoiced; and open orders, agreed and not yet shipped. Whether that last one counts is the decision that most changes behaviour, because including it means a large order book consumes the limit before anything has been sent.

The check then runs at defined points: at order creation, at delivery creation, and at goods issue. Each is a different question. Blocking at order tells the salesperson immediately. Blocking at goods issue stops the lorry, which is later and firmer.

The check can be static, comparing total exposure against the limit, or dynamic, considering only exposure within a horizon so that orders far in the future do not consume today's limit.

Beyond the limit itself, additional checks can block on oldest open item, so a customer with anything sufficiently overdue is stopped regardless of their limit, and on maximum dunning level.

Half an hour, and it covers the process as much as the configuration.

1. Set a low credit limit on a test customer.
2. Create a sales order that exceeds it. The order saves and carries a credit block.
3. Try to create the delivery. Refused, because the block sits on the order.
4. Open the credit release worklist, review the customer's exposure, and release the order.
5. Create the delivery. It now proceeds.
6. Now post a payment clearing part of the customer's open items and create another order. The exposure has fallen and the same order value passes.

Step four is where the design question lives: somebody in finance has to be looking at that worklist promptly, or sales orders sit blocked and the business routes around the control by raising them differently.

S/4HANA uses SAP Credit Management (FIN-FSCM-CR), a more capable successor to classic SD credit management, with credit scoring and centralised control. It integrates SD (orders/deliveries) with FI (receivables) to give a real-time credit picture and enforce limits across the order-to-cash flow.

The practical differences worth knowing: the credit master data moved to the business partner, limits can be derived from a scored risk class rather than set individually, exposure can be consolidated across several company codes into one credit account, and the classic tables and transactions are replaced. A system converted from ECC needs its credit configuration migrated rather than carried, and that is a real item on a conversion list.

• What counts as exposure. Including open orders is conservative and consumes limits early. Excluding them risks shipping against commitments already made.
• Where the block bites. At order, delivery or goods issue, and each moves the disruption to a different team.
• Who releases. Finance owns the risk and sales feels the delay, so the release has to be staffed rather than assigned.
• How limits are set. Individually by a credit controller, or derived from a risk class and a scoring rule, which scales and needs the scoring maintained.

Credit management decides whether to ship. Two related functions decide what happens when money does not arrive, and they share the same data.

Collections management gives collectors a prioritised worklist rather than an ageing report. Customers are scored by rules, so the list is ordered by who is worth chasing today, and each contact is recorded with a promise to pay and a follow-up date. The difference from working an ageing report is that the system remembers what was agreed.

Dispute management handles the case where a customer is not paying for a reason. A dispute case attaches to the open items, records why, routes to whoever can resolve it, and takes those items out of the collections worklist while it is open. Without it, disputed invoices are chased repeatedly by people who do not know they are disputed.

The link back to credit is that both feed exposure. An invoice in dispute is still owed, and whether it counts against the limit is a decision; a customer with a large dispute can otherwise be blocked from trading over an amount nobody expects them to pay yet.

Together these are the financial supply chain functions, and they are usually implemented after credit management rather than with it.

A credit limit is one instrument and a business exposed to real credit risk uses others alongside it, each of which the system can carry.

Payment terms are the first lever and the least used: shortening them reduces exposure more reliably than any check, because the money arrives sooner.

Prepayment or proforma removes the risk entirely for new or high-risk customers, at the cost of the sale being harder to make.

Letters of credit and documentary payments shift the risk to a bank, which is common in export business and adds document handling.

Credit insurance covers the loss rather than preventing it, and where it exists the insured limit per customer usually becomes the credit limit in the system.

Payment guarantee procedures in SD tie these together, deciding per customer and document type which form of security is required before an order can proceed.

The point for a consultant is that a request to "make credit management stricter" is often better answered by payment terms or by a guarantee procedure than by lowering limits, because lowering limits blocks good customers along with bad ones.

• No/weak credit checks, exposure to bad debt.
• Blocked orders not managed, delaying legitimate sales.
• Using classic credit mgmt instead of S/4HANA FSCM.

• A release worklist nobody works. Orders age, the business complains, and the usual resolution is raising limits rather than staffing the review.
• Limits set once at go-live. Customers grow and shrink, and a limit from three years ago is either blocking good business or exposing you.
• Checking at order only. See billing, delivery and SD configuration for the steps the block interrupts.

• Open orders excluded from exposure without deciding to. The limit then only counts what has shipped, and a customer can commit far beyond it before anything is checked.

Releasing a blocked order is the easy half, and configuring what counts as exposure and where the check runs so the control fits the business is the part you do in the course.

The design question that decides whether this works in practice is who looks at the release worklist and how often. A credit check with nobody staffing the release turns into raised limits, which is the control being removed by attrition.