Pricing
SD / O2Cbeginner

SD Pricing Part 1: The Condition Technique — How SAP Prices a Sales Document

Key takeaway

The big picture of SD pricing: the condition technique chain (pricing procedure → condition types → access sequences → condition tables → condition records), how the pricing procedure is determined for a document, and how prices, discounts, surcharges, freight and taxes build up to the net value.

What this complete series covers

Learn Pricing in a clear, practical sequence — from the basic idea to real project use, troubleshooting, and interview-ready understanding.

Who it is for
Best for SAP consultants, developers, and learners who want a practical understanding of Pricing.
Prerequisites
Basic SAP S/4HANA navigation and an understanding of the business process are helpful. Configuration or transaction steps require suitable access to a practice or project system.
Final outcome
By the end, you should be able to explain Pricing clearly, follow the main end-to-end flow, apply it in a project scenario, and troubleshoot the most common issues.
  1. Part 1: SD Pricing Part 1: The Condition Technique — How SAP Prices a Sales Document

    An introduction to why pricing exists in SAP SD, what business problems it solves, and how price determination fits into the order-to-cash cycle.

  2. Part 2: SD Pricing Part 3: Condition Types and the Pricing Procedure

    A deeper look at how pricing procedures are structured, how the condition technique determines which conditions apply, and how consultants configure and troubleshoot this at the intermediate level.

  3. Part 3: SD Pricing Part 4: Condition Records, Scales and Validity Management

    How condition records are created, scaled, and time-bounded, and how these design choices affect pricing accuracy, maintenance effort, and downstream document behavior.

  4. Part 4: SD Pricing Part 10: Enterprise Pricing Architecture — Governance, Extensibility and S/4HANA Migration

    Architect-level guidance on designing scalable pricing architecture for multi-country templates, governing condition master data and configuration changes, choosing extensibility a

  5. Part 5: SD Pricing Part 7: Pricing Routines — Requirements, Alternative Calculation Types and Base Values

    How requirement routines, alternative calculation type routines, and alternative base value routines extend standard condition technique logic to handle complex business rules that

  6. Part 6: SD Pricing Part 5: Header Conditions, Statistical Conditions and Subtotals

    Understand how pricing conditions behave at header and item level, how statistical conditions provide information without changing net value, and how subtotals feed downstream calc

  7. Part 7: SD Pricing Part 2: Condition Tables and Access Sequences — How SAP Finds a Price

    Trace price determination from condition type through access sequence and condition tables to the first valid condition record, including key fields, validity, scales and exclusive access behavior.

  8. Part 8: SD Pricing Part 9: Troubleshooting Pricing — Missing, Inactive and Wrong Conditions

    Troubleshoot pricing by using pricing analysis to distinguish condition not found, requirement not fulfilled, condition excluded, inactive calculation, invalid record and copy/repricing behavior.

  9. Part 9: SD Pricing Part 8: Manual Pricing, Price Updates and Change Governance

    Govern manual pricing overrides so exceptional commercial decisions remain auditable and do not silently replace contract or master-data pricing across orders.

  10. Part 10: SD Pricing Part 6: Condition Exclusion, Group Conditions and Scales in Depth

    Use condition exclusion, group-condition behavior and scales deliberately so discounts and surcharges are calculated from the intended competitive rule and aggregation base.

System and release assumptions: Examples focus on SAP S/4HANA. Exact apps, transaction codes, configuration paths, and field names can vary by release and deployment model.

Explanation

📌 KEY POINTS
✅ SD pricing uses the condition technique: pricing procedure → condition types → access sequences → condition tables → condition records.

✅ The pricing procedure is determined from sales area + document pricing procedure (document type) + customer pricing procedure (customer master) in OVKK.

✅ Condition types represent price elements: price, discounts, surcharges, freight, taxes, cost.

✅ Condition records hold the actual values (e.g. price per material and customer) and are maintained by business users (VK11 or Fiori).

⚠️ Most "wrong price" issues are data (records, validity) or determination (procedure, access), not bugs — pricing analysis shows which.

━━━━━━━━━━━━━━━━━━━━
▶ WHAT THIS SERIES COVERS

Part 1: The condition technique

Part 2: Condition tables and access sequences

Part 3: Condition types and the pricing procedure

Part 4: Condition records, scales and validity

Part 5: Header, statistical and subtotal conditions

Part 6: Exclusion, group conditions and scales in depth

Part 7: Pricing routines and alternative calculation types

Part 8: Manual pricing, price updates and change governance

Part 9: Troubleshooting pricing

Part 10: Enterprise pricing architecture and S/4HANA migration

━━━━━━━━━━━━━━━━━━━━
▶ 1. THE CHAIN

  • Pricing procedure: ordered list of condition types with subtotals and rules.
  • Condition type: one price element (price, discount, freight, tax).
  • Access sequence: search strategy for a condition type (most specific first).
  • Condition table: key combination (e.g. customer + material).
  • Condition record: value for a key and validity period.

━━━━━━━━━━━━━━━━━━━━
▶ 2. PROCEDURE DETERMINATION

  • Sales area + document pricing procedure (VOV8) + customer pricing procedure (customer sales area data) → pricing procedure (OVKK).
  • Different procedures for domestic, export, intercompany or rebate-relevant business.

━━━━━━━━━━━━━━━━━━━━
▶ 3. BUILDING THE NET VALUE

  • Gross price → discounts/surcharges → net value → freight → taxes → total.
  • Subtotals for reporting and credit (Part 5).

━━━━━━━━━━━━━━━━━━━━
▶ 4. WHO MAINTAINS WHAT

  • Configuration (consultant): tables, access sequences, types, procedures.
  • Master data (pricing team): condition records, scales, validity.

━━━━━━━━━━━━━━━━━━━━
▶ 5. WHERE TO LOOK

  • Item > Conditions tab: values; Analysis: why each condition was found or not.
  • Header > Conditions: header totals and header conditions.

━━━━━━━━━━━━━━━━━━━━
▶ STEP BY STEP

  1. Create an order and open item conditions.
  2. Use Analysis to see accesses for the price condition.
  3. Check which pricing procedure was determined (header > Sales tab / analysis).
  4. Change a condition record and reprice.

✅ CHECKPOINT: you can explain every line of an item's condition screen and where its value came from.

Code example

ABAP Code
===== STEP 1: the condition technique chain =====Pricing procedure (V/08)   RVAA01 / S/4HANA standard procedure └ Condition type (V/06)   PR00 (ECC) / PPR0 (S/4HANA) price, K007 customer discount, KF00 freight, MWST/TTX1 tax    └ Access sequence (V/07) PR02: 1 customer/material  2 price list/material  3 material       └ Condition table (V/03) e.g. A305 customer/material, A304 material          └ Condition record (VK11) customer 1000 / material M-100 = 95.00 EUR, 01.01.–31.12. ===== STEP 2: pricing procedure determination (OVKK) =====Sales org | DChl | Div | DocPricProc (VOV8) | CuPP (customer) | Pricing procedure1000      | 10   | 00  | A                  | 1               | RVAA01 ===== STEP 3: where to look =====VA03 > item > Conditions > Analysis     (accesses, found/not found, inactive reasons)S/4HANA: condition data of documents in PRCD_ELEMENTS (replaces KONV)

Real project scenario

A distributor's sales team complained that "the system prices randomly". Analysis of 50 examples showed three clear causes: customers without the customer pricing procedure maintained (so a different procedure without customer discounts was used), overlapping validity periods for price records created by two teams, and freight records missing for a new region. None was a configuration bug. The fix was data governance: mandatory customer pricing procedure in BP creation, one team owning price records, and a validity-overlap report.

Common mistakes

  • Treating pricing issues as bugs before checking pricing analysis.
  • Forgetting the customer pricing procedure in the customer master.
  • Confusing condition type and condition record.
  • Not knowing that document pricing procedure comes from VOV8.
  • Looking for KONV in S/4HANA instead of PRCD_ELEMENTS.

Best practices

  • Learn to read pricing analysis first.
  • Separate configuration from condition record ownership.
  • Keep the number of pricing procedures small.
  • Maintain customer pricing procedure consistently.
  • Document the pricing chain per procedure.

Interview angle

Questions: "Explain the condition technique", "How is the pricing procedure determined?", "Where do you look when a price is wrong?"
Strong answer: pricing procedure, condition types, access sequences, condition tables and condition records; OVKK with sales area, document pricing procedure and customer pricing procedure; pricing analysis in the item conditions; S/4HANA stores document conditions in PRCD_ELEMENTS.

Practice this lesson

Quick check

1. Which condition type is the standard price in SD?

2. Which transaction is used to maintain pricing procedure determination?

3. Which three inputs determine the pricing procedure of a sales document?

Interview questions

1. Online orders for a new sales channel pick up a generic base price instead of the channel price, although channel price records exist. How do you analyse it?

Answer it in your own words first, then compare.

2. What is the condition technique in SAP SD pricing, and what are its core building blocks?

Answer it in your own words first, then compare.

Practice more with Interview AI →

Reference-verified: the steps are checked against official SAP documentation and tutorials, and object and field names in the sample code are checked for consistency. The code has not been compiled or run on an SAP system by ERPClimb. Syntax marked release-dependent varies by SAP release, so check it in your own system.

More lessons in this topic

Interview questions on this topic

Related SAP topics