VK13 — Display Condition Records for Pricing

VK13 shows the value stored in a condition record: a rate, discount percentage, surcharge, freight amount, or tax rate tied to a condition type and a specific combination of key fields, such as sales organization plus customer plus material, or just material, or price list plus customer group. It is display-only, matching the create (VK11) and change (VK12) pair. The structural fact that causes most confusion is that a single condition type is not one record but potentially many, spread across multiple key combinations and access sequence steps. A user checking the material-only combination will see nothing even though a valid record sits under customer/material, or under a price-list combination that takes priority. VK13 only shows what is asked for; picking the wrong combination on the initial screen produces a misleading empty result.

VK13 is reached for whenever a price, discount, surcharge, or freight amount in a quotation, sales order, or billing document looks wrong or missing, and the investigation has already confirmed the pricing procedure and access sequence are configured to look for that condition type. It sits below the configuration layer, in master data, and answers the question of whether the actual record exists, is valid for the relevant date, and holds the expected value. It is preferred over VK12 during investigation because display access carries no risk of an accidental overwrite while diagnosing. It is also used before and after data loads or migrations to confirm condition records were created with the right key values and validity, and during cutover checks comparing legacy price lists against what landed in the target system.

Identify the condition table number behind the condition type and key combination in question (visible from the pricing configuration or from the 'key combination' chosen on the VK13 selection screen). Open that access table (Annn) via SE16N, filter on the exact key values from the document - customer, material, sales organization, distribution channel - and on a validity range covering the document's pricing date. Note the KNUMH value returned. Look up KONP by KNUMH to get the rate, unit, and currency, and KONH by the same key to confirm validity dates and check the deletion indicator, which can leave a record technically present but excluded from pricing.

The condition record structure and the VK11/VK12/VK13 transaction pair are unchanged on S/4HANA; the underlying tables and access-sequence logic behave the same as in ECC. A Fiori app for managing sales pricing conditions exists for simpler condition maintenance scenarios, but complex condition tables with many key fields or scales are commonly still handled through the classic transactions. No functional behavior difference to account for during troubleshooting.

Functional SD, specifically the pricing/order management consultant, owns interpretation of key combinations, access sequences, and record validity. Master data or pricing administration teams own actual record maintenance authorization. Basis involvement is rare, limited to table display authorization issues. A good handover states the condition type, the exact key combination and values checked, the document pricing date, and the KNUMH found (or confirmation none was found).

VK11 and VK12 are the create and change counterparts of the same condition record object and are the next stop once VK13 confirms what exists or is missing. VOV8 defines which pricing procedure a document type uses, which determines which condition types are even eligible to search for a record, so a missing price sometimes traces back to VOV8 rather than to VK13 at all. VKOA governs revenue account determination, a separate but frequently confused condition-technique-based lookup that consultants sometimes check by mistake when the real issue is a pricing condition.