Credit Limit Block Not Releasing on a Sales Order

Sales rejects that an order is stuck because the customer is a good payer, or has already sent the payment, and the order still shows a credit block in VA02 or on the blocked order list. Shipping cannot create a delivery because the order is on hold. Finance is asked to confirm the customer is fine and confirms it, but the block does not disappear on its own. Sometimes the same customer had an identical order go through cleanly last week, which makes the business assume the system is randomly malfunctioning rather than reacting to a specific change in exposure, limit, or configuration. The complaint usually arrives as 'this customer is not even close to their limit, why is the order blocked' rather than any mention of credit management settings.

Start on the blocked order list to see exactly which check flagged the order and at what level, using the release worklist transactions. Then look at the customer's credit master or business partner credit segment to compare the actual limit and used amount against what the business believes is true. Cross-check the open items on the account in the customer line item display to see if a cleared payment is still showing as open. Review the checking rule setup for the sales document type, credit control area, and risk category combination to see which check (static, dynamic, or open item) is firing and what horizon it uses. Pull the document flow for the order to confirm nothing is being double counted between the order, an already-invoiced delivery, and the receivable.

Pull the credit exposure breakdown for the customer from the credit master or business partner credit segment and list every open order, delivery, and invoice contributing to the used amount. Compare that list against the actual open items in the customer line item display. Any document appearing in both the exposure breakdown and as a cleared or invoiced item in finance is the double-count or stale-clearing evidence the business needs to see.

If the cause is a cleared payment still showing open, this is a data fix on the finance side: run or correct the clearing, and the exposure drops without touching config. If the limit increase was agreed but never entered, update the credit segment or FD32 record directly, also a data fix, but confirm who is authorized to change it since it is often outside SD's control. If the customer or order sits in the wrong credit control area, correcting the master data assignment is a data fix, but if the underlying determination logic itself is wrong, that is a configuration change to the assignment rules and needs a transport. Risk category and checking rule adjustments (OVA8) are configuration and always need a transport through the normal change path, since they affect every customer in that category, not just the one complaint in front of anyone. A one-off release with justified reason belongs in the release transaction as a manual action, not as a workaround for a systemic exposure or limit problem.

The habitual fix is to manually release the order in the worklist every time it appears, treating it as a one-off nuisance. This clears the immediate symptom but leaves the underlying exposure miscalculation, stale limit, or wrong risk category in place, so the same customer's next order blocks again and the manual release becomes a permanent workaround. A close second is raising the credit limit arbitrarily to make the block stop, which removes the control's purpose entirely and hides a real exposure or data problem instead of correcting it.

Day-to-day releases belong to the credit management or credit control team, who action the worklist. The underlying exposure calculation and checking rule configuration belong to the SD or FSCM credit consultant. The handover note should state which check fired, whether the cause was data (cleared item, missing limit update) or configuration (checking rule, risk category, control area assignment), and whether a transport is pending.