SAP Pricing Procedure Not Determined in a Sales Document

The determination table maps sales organisation, distribution channel, division, document pricing procedure and customer pricing procedure to a procedure. If the specific combination in your order has no row, nothing is determined and the item stays empty. Check OVKK and look for the exact combination — not a similar one. New sales areas created for a rollout are the classic case: everything else was copied and this table was not.

The indicator lives on the sales area view of the customer master and is stored in KNVV-KALKS. A customer created by a data load or replicated through an interface frequently arrives with the field empty, because it is not mandatory at the technical level. The result is a lookup with a blank key that finds nothing. Confirm the value in XD03 or the business partner sales area data, compare it with a customer that works, and correct the master record rather than adding a blank-key row to the determination table.

Each sales document type carries its own document pricing procedure indicator, maintained in VOV8. Copied order types keep the indicator of the source, which is fine until someone changes one deliberately — free-of-charge, returns and credit memo types often use a different indicator on purpose. If pricing works for a standard order and fails for a return, this is almost certainly the cause, and the fix is a determination entry for that indicator rather than a change to the order type.

A determined procedure with no values is a different problem, and confusing the two costs the most time. Here the procedure is found, but the access sequence returns nothing: condition records do not exist, they lie outside their validity period, they were created for a different key combination, or a requirement routine on the condition type is suppressing the access. The pricing analysis on the item condition tab states this explicitly per condition type and per access — read it before touching configuration.

1. Open the sales document, go to the item conditions tab and open the analysis. Confirm first whether a procedure name is shown at all. This single fact splits the problem into determination versus condition records.
2. If no procedure is shown, note the sales area from the header, the order type, and the customer pricing procedure from the payer or sold-to sales area data.
3. Check OVKK for that exact five-part combination. A missing row is your answer.
4. If the row exists, verify the indicators actually in use: VOV8 for the document indicator and the customer master for the customer indicator. A mismatch between the row you found and the values in the document is common after a rollout.
5. If a procedure is shown but values are missing, read the analysis per condition type. It names each access and why it failed, including inactive requirements.
6. Validate the record in VK13 using the same key and the pricing date from the document, not today's date. Backdated and future-dated orders fail on validity constantly.
7. Re-run pricing on the item with the update option after any correction, or recreate the document. Existing items do not re-determine the procedure by themselves.

Fix at the level where the data is wrong. A missing determination row is a configuration change and belongs in a transport through the normal path. A blank customer indicator is a master data correction and should also be fixed at the source system or load template so it does not recur across the next thousand customers. A missing condition record is a business action for whoever owns pricing, not something to invent in production.

After the fix, re-price an affected document and confirm the analysis now shows both the procedure and the expected condition values. If the order was already delivered or billed, check whether downstream documents need re-pricing or a credit or debit memo — correcting the order alone leaves the invoice wrong.

Escalate to the SD configuration owner when the required determination entry does not exist in any environment and someone must decide which procedure the new sales area should use. Escalate to development when the pricing analysis points at a requirement or formula routine, since changing routine logic affects every document that uses the condition type. Escalate to the business when the correct condition record simply has not been maintained — that is a commercial decision about price, and support should not fill it in.

Paste your pricing analysis output into the ERPClimb AI Debugger for an ordered root-cause path against your own sales area and document type.

• IDoc status 51 application errors — where a pricing gap surfaces as a failed inbound order.
• GR/IR mismatch: how to find and clear it — the equivalent diagnostic on the procurement side.
• SAP MM vs SD: which module to choose — if pricing work is the kind of problem you want to own.