The SAP SD pricing procedure is the template that defines in which order, and by which rules, every price element of a sales document is calculated. Base price, discounts, freight, tax and cost lines are all defined here. Because pricing errors translate directly into lost margin, it is one of the areas an SAP SD consultant spends the most time on.
The five building blocks of the condition technique
SAP pricing is built on a generic mechanism called the condition technique. The same mechanism drives output, text and material determination, so understanding it well pays off many times over.
- Condition table: defines the key fields a price is maintained for (for example sales organisation + customer + material).
- Access sequence: defines the order in which the system searches the condition tables, usually from most specific to most general.
- Condition type: defines how each element (price, discount, freight) is calculated (amount, percentage, quantity-based) and how it behaves.
- Pricing procedure: orders condition types by step number; subtotals, requirements and calculation formulas live here.
- Procedure determination: selects the procedure based on the sales area plus the customer and document pricing procedures.
Condition records and VK11
Once configuration is done, actual prices are entered as condition records (created with VK11, changed with VK12). Every record has validity dates; when a price changes, creating a new dated record instead of overwriting the old one preserves the price trail of past orders. Quantity or value scales handle volume discounts without any code.
What a good procedure looks like
- Readable subtotals: gross price, net price, net value and margin appear as separate subtotals.
- A statistical cost line: cost (for example VPRS) is carried as a statistical condition, so margin is visible on the order and flows to CO-PA.
- Controlled manual changes: only a few conditions can be changed by hand, and changes are reported.
- Correct account keys: every revenue and discount line posts to the right G/L account, the foundation of SD–FI integration.
What happens to prices when documents are copied?
Whether pricing is recalculated or copied as-is from order to invoice is controlled by the "pricing type" in copy control. Type B carries out new pricing, type C keeps manually entered elements and redetermines the rest, and type G copies elements unchanged and redetermines only taxes. The wrong choice is the most common reason an invoice shows a different price from the order. See the copy control article for details.
Common mistakes
- Creating a new condition type for every new requirement until the procedure becomes unreadable
- Placing a general record before a specific one in the access sequence
- Misconfiguring group conditions (discounts spread across the whole document)
- Testing only the happy path and skipping returns, credit memos and price-difference invoices
What is different in S/4HANA?
The logic of the condition technique has not changed, but the data model has been simplified (price elements are stored in a single table) and some condition type names were renewed in the standard templates (for example PPR0 instead of the classic PR00 for the price condition). Fiori apps also make mass maintenance of condition records easier. In migration projects, custom pricing routines and reports need to be adapted to the new table structure.
Pricing is where the sales process turns into profit. Keeping the procedure lean, documenting the purpose of every line and tracking the outcome in CO-PA is the approach that pays off most in the long run.
