Billing Block That Will Not Clear on a Sales Order

Reported as: I took the billing block off the order, saved it, and it is still there when I open it again. Or: the field is grey, I cannot even click into it. Or: the block disappeared for a minute and came back after I saved. Billing or collections raises it because an overdue invoice cannot be generated and the customer is asking for the document. Sometimes it surfaces as a difference between two people looking at the same order - one person in customer service sees the block cleared, someone in billing running VF01 still gets the blocked message. Nobody initially frames it as configuration; it is reported as the system not accepting the change, or the change 'not saving', which is the language that usually points a support ticket at the wrong team first.

Pull VBAK-FAKSK and VBAP-FAKSP for the order before and after the user's save to show the field actually reverted rather than never having changed. Cross-check against change documents (CDHDR/CDPOS) for the sales order to see who or what process changed the field back, and at what timestamp relative to the user's save. If a customer master origin is suspected, compare the customer's sales area billing block flag against the order value at the same point in time.

If it is an authorization group restriction, this is not a config transport - it is a security fix, either granting the requesting user the role that includes change access to that block reason's authorization group, or routing the removal to someone who already has it. If it is a header/item mismatch, it is a data fix on the order itself: clear the block at both levels, item by item, which can be done individually in VA02 or in bulk through a mass change tool for multiple orders sharing the same stuck reason. If a requirement routine or custom exit is reapplying the block, this is a development and config change requiring a transport - the routine logic or the exit needs to stop reapplying the block once the business condition that triggered it (credit review, minimum value, rebate hold) has actually been resolved. If the field is locked because it is not flagged changeable in that document status, that is a customizing change to the block reason definition, again transportable, and it needs a business decision about whether that restriction should be lifted for that scenario. If the block is being repulled from the customer master, the fix is at the customer master level - remove or correct the sales area billing block flag there, which is a data change, not an order-level one.

The reflex is to keep clearing the field and saving repeatedly, sometimes escalating to a mass-change transaction or asking a technical resource to update the field directly in the table via a debug session or direct table maintenance. Neither addresses why the block reapplies. A direct table update bypasses the update logic that would normally revalidate the order, can leave document status and change history inconsistent, and does not touch whatever routine or authorization restriction reapplied the block in the first place, so the same order gets blocked again on the next change.

SD functional consultant owns the initial diagnosis - header versus item, incompleteness, and reference document checks. Security or role owners handle the authorization group fix. A developer with an SD functional spec is needed if a routine or exit is reapplying the block. Credit and customer master data owners handle a customer-master-driven block. The handover note should state the order number, the block reason code, whether it reverts at header or item level, and whether the field is even editable for the requesting user.