SAP SD Pricing Procedure: Complete Configuration Guide
For SAP S/4HANA · Updated for 2026
The Pricing Procedure is the most powerful — and most misunderstood — configuration object in SAP SD. It controls how every price, discount, tax and surcharge is calculated on a sales order or invoice. This guide walks you through the complete configuration, from determination logic to the hidden power of routines, with S/4HANA-specific changes called out where relevant.
Whether you are preparing for an SAP SD interview, troubleshooting a pricing bug on a live project, or configuring a new implementation, this guide covers what you need to know.
What You Will Learn
- 01What is a Pricing Procedure in SAP SD?
- 02Pricing Procedure Determination — the 3 keys
- 03Condition Type Control — the 5 flags that matter
- 04Account Keys and Revenue Account Determination (VKOA)
- 05Requirement and Calculation Routines (VOFM)
- 06How to read a Pricing Procedure table
- 073 common Pricing bugs on real projects
- 08What changed in S/4HANA pricing
What is a Pricing Procedure in SAP SD?
A Pricing Procedure in SAP SD is a sequential list of condition types that SAP evaluates when a sales document is created or changed. Each row of the pricing procedure represents one condition type — the base price (PR00), customer discount (K007), material discount (K004), freight (KF00), tax (MWST), and so on — along with configuration that controls how that condition behaves.
The Pricing Procedure determines: the order of calculation, which conditions are mandatory vs optional, which are informational (statistical), which step each condition uses as its base, how each condition posts to FI via account keys, and which ABAP routines control its evaluation.
In short: if pricing goes wrong on a sales order, the root cause is almost always in the Pricing Procedure — either the determination (wrong procedure chosen) or the configuration (wrong condition behaviour).
Pricing Procedure Determination — The 3 Keys
When a sales order is created, SAP needs to decide which Pricing Procedure to use. It does this by looking at three keys:
Derived from the sales order header. Every sales document belongs to exactly one sales area.
Maintained on the customer master: Sales Area → Sales tab → Pricing statistics group. Classifies customers by pricing behaviour (domestic, export, intercompany, etc.).
Configured on the Sales Document Type in VOV8. Classifies documents by pricing needs (standard, credit memo, free-of-charge, etc.).
These three keys are mapped to a Pricing Procedure in transaction OVKK. If the combination exists, that Pricing Procedure is used. If no match exists, pricing determination fails silently — the order can still be created, but no prices will be calculated.
Condition Type Control — The 5 Flags That Matter
Every condition type in a Pricing Procedure has a row of flags that control its behaviour. Five flags matter most in real-world configuration:
Order cannot be saved if this condition has no value. Used for base price (PR00). Classic go-live issue: mandatory set but no condition records maintained → order entry completely blocked.
Condition is displayed but does not affect the net value. Must be set on cost conditions like VPRS — otherwise cost posts as revenue and margin reporting breaks.
Controls whether users can override the condition on the order. Values: A = manual not possible, B = manual possible, C = header condition only.
Controls whether the condition prints on output documents (invoice, order confirmation). Critical for tax and legal compliance.
Controls user override rights at runtime. Misconfigured, it either locks users out of legitimate pricing or exposes pricing to manipulation in live systems.
Account Keys and Revenue Account Determination (VKOA)
Account Keys are the bridge between SD pricing and FI accounting. Each revenue-relevant condition type in the Pricing Procedure is assigned an Account Key (e.g. ERL for revenue, MWS for tax, ERS for discounts, EIN for cost of goods sold). The Account Key is then mapped to a specific G/L account in transaction VKOA.
VKOA allows fine-grained mapping using combinations of: chart of accounts, sales organisation, customer account assignment group (defined on the customer master), and material account assignment group (defined on the material master). The most specific match wins.
| Account Key | Used For | Typical G/L |
|---|---|---|
| ERL | Revenue account — base sales posting | Revenue G/L |
| MWS | Output tax (VAT/GST) | Tax payable |
| EIN | Cost of goods sold (statistical) | COGS account |
| ERS | Sales deductions / discounts | Discount account |
| ERF | Freight / surcharges | Freight revenue |
Critical rule: Without a valid VKOA entry for the account key + chart combination, billing release to accounting will fail with a hard error. Always test billing-to-FI release in every development and QA cycle — not just at UAT.
Requirement and Calculation Routines (VOFM)
Routines are small ABAP programs assigned to individual condition types in the Pricing Procedure. They give you precise control over when and how a condition is evaluated. Three types of routines matter:
Returns true/false. If false, the condition is skipped silently with no error. Example: Rqt 002 = "Only activate this condition if item category is TAN (standard item)".
Replaces the standard condition value derivation with custom ABAP logic. Used when the value cannot be derived from a condition record alone. Example: Intercompany price derived from purchasing info record.
Changes what the condition percentage is applied against. Critical for tax-on-tax scenarios, freight on specific items, and tiered pricing logic.
Standard routines (numbered 1–999) are SAP-delivered. Custom routines (600+) are created via transaction VOFM. Always document custom routines — they are invisible to consultants joining a project mid-flight, and undocumented custom logic is a leading cause of production incidents.
How to Read a Pricing Procedure Table
A typical Pricing Procedure looks like the table below. The key columns are: Step (calculation order), Condition Type, From/To (which step range to use as the base), Statistical flag, Account Key, and Subtotal (which KZWI field to store the intermediate value in).
| Step | Cond Type | From / To | Stat | Acct Key | Subtotal |
|---|---|---|---|---|---|
| 10 | PR00 | — | — | ERL | 1 |
| 20 | K004 | 10 | — | ERS | — |
| 30 | K005 | 10 | — | ERS | — |
| 40 | NET1 | 10–30 | ✓ | — | 2 |
| 50 | VPRS | — | ✓ | EIN | — |
| 60 | MWST | 40 | — | MWS | — |
Key insight: Step 40 (NET1) sums steps 10 through 30 into KZWI2. Step 60 (MWST) has From = 40 — meaning tax is applied on the net value after discounts, not the gross price. Getting the From/To columns wrong is the #1 pricing bug on real SAP projects.
3 Common Pricing Bugs on Real Projects
Root cause: the "From" step on the tax condition type (MWST) pointed to the base price step (PR00) instead of the net subtotal step.
✓ Fix: Correct the "From" column to reference the net subtotal step. Validate with a test order that includes a discount.
Root cause: account key on a condition type had no G/L mapping in VKOA for the relevant chart of accounts + sales org combination.
✓ Fix: Add the missing G/L mapping in VKOA. Make billing-to-FI release a standard part of every dev/QA cycle — not just UAT.
Root cause: CuPP on the customer master did not match the OVKK entry, so a different Pricing Procedure was determined — one without the discount condition.
✓ Fix: Align CuPP on the customer master with OVKK. Use Condition Analysis (display mode in VA02 → Item → Conditions → Analysis) to trace determination.
What Changed in S/4HANA Pricing
The core Pricing Procedure logic is unchanged in S/4HANA — the configuration you learn here applies to both ECC and S/4HANA. However, several architectural enhancements surround it:
Rule-based pricing using BRFplus decision tables. Business users can maintain complex pricing rules through Fiori apps without needing VK11 or ABAP development.
Replaces legacy rebate agreements (BO01/BO03). Settlement documents replace credit memos. More flexible accrual and settlement workflow.
Account keys in the pricing procedure now map directly to ACDOCA line items — a single source of truth for margin reporting. The old costing-based vs account-based CO-PA split is largely obsolete.
Condition analysis previously done inside VA01/VA02 is now available as a dedicated Fiori app. Faster diagnostics for pricing issues in production without requiring SAP GUI access.
Frequently Asked Questions
What is a Pricing Procedure in SAP SD?
A Pricing Procedure in SAP SD is a sequential list of condition types (e.g. base price, discounts, taxes, freight) that SAP evaluates when a sales document is created. It defines the order of calculation, how each condition interacts with others (via From/To steps), whether conditions are mandatory or statistical, which account keys they post to in FI, and which ABAP routines control their behaviour. The Pricing Procedure is the central control object for pricing in SD.
What is the transaction code OVKK used for?
OVKK is the transaction where Pricing Procedure determination is configured. It maps a combination of Sales Area (Sales Org + Distribution Channel + Division), Customer Pricing Procedure (CuPP) and Document Pricing Procedure (DoPP) to a specific Pricing Procedure. If any of these three keys are missing or mismatched, pricing determination fails.
What is the difference between CuPP and DoPP?
CuPP (Customer Pricing Procedure) is a 1-digit indicator maintained on the customer master in the Sales Area → Sales tab. It classifies customers by pricing behaviour — e.g. standard, domestic, export. DoPP (Document Pricing Procedure) is a 1-digit indicator configured on the Sales Document Type in VOV8. It classifies documents by pricing needs — e.g. standard order, credit memo, intercompany. Together with Sales Area, they determine the Pricing Procedure via OVKK.
What is VKOA in SAP SD?
VKOA is the transaction for Revenue Account Determination — the configuration that maps SD Account Keys (from the Pricing Procedure) to FI G/L accounts. The mapping can use combinations of chart of accounts, sales organisation, customer account assignment group, and material account assignment group. Without a valid VKOA entry, the billing document cannot be released to accounting and will throw a hard error.
What changed in SAP SD pricing with S/4HANA?
Key S/4HANA pricing changes: (1) Advanced Conditions — rule-based pricing via BRFplus, enabling business-user maintenance without VK11, (2) Condition Contract Management replaces classic rebate agreements (BO01/BO03), (3) ACDOCA (Universal Journal) simplifies margin analysis by merging FI and CO postings, (4) Pricing Analysis is available as a dedicated Fiori app (F3047) instead of only within VA01/VA02. Core pricing procedure logic remains unchanged — the architecture around it has evolved.
What is a Statistical condition in SAP SD?
A Statistical condition is calculated and displayed on the sales document but does NOT affect the net value or post to FI via account determination. The classic example is VPRS (cost condition) — it must be Statistical, otherwise it would reduce revenue and post incorrectly. Statistical conditions are used for informational purposes — cost, margin calculations, expected rebates, and comparison values.
Put this into practice — with real scenarios.
Pricing Procedure is one of 30+ topics covered inside The SD Vault. Get 230+ interview questions, 38 hands-on scenarios, and 30 Ready Reckoner topics — all with lifetime access.
Get Lifetime Access →Or read our SAP SD Interview Questions guide for interview preparation.