JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 6, 2026 · 12 min read

SAP Service Pricing Condition

The Pricing Condition is the master data record produced by SAP’s Condition Technique — a rule-based lookup engine, shared across SD, Service, and other sales-facing modules, that resolves a price, discount, surcharge, or tax value for a document line item from a combination of key fields such as Service Product, Customer, and Sales Organization. In SAP S/4HANA Service, this is the mechanism that sets the price of a Service Product (Material Type DIEN) once the Service Product itself has been defined. This article first covers the Condition Technique as a general concept (Part 1), then the Service-specific configuration and field detail (Part 2).

Part 1: Pricing Condition — Core Concepts (All Modules)#

1.1 What Is the Pricing Condition?#

A Pricing Condition (commonly called a “Condition Record”) is not a price typed directly onto a document — it is a maintained master record that the system looks up at runtime, using a defined sequence of key-field combinations, to calculate the value that applies to a specific line item. Rather than hard-coding a number, business users maintain Condition Records against Condition Types, and SAP resolves the applicable record following an Access Sequence and a Pricing Procedure assigned to the document type.

1.2 Condition Categories and Types#

Every Condition Type is assigned a Condition Class that governs how its value behaves in the pricing procedure’s running total — whether it adds to net value, is purely informational (statistical), or feeds a separate tax calculation. Getting the class wrong is a common configuration mistake: a discount configured with the wrong class either fails to reduce net value or silently disappears from the invoice.

Design principle: Choose the Condition Class based on how the value must behave in the running total (add to net value vs. statistical/informational only) — not by what the value is called in a business conversation.

1.3 Organizational Levels and Data Hierarchy#

The diagram above crops Zone D — Service Product & Template (Client-Level) from the Service module’s Master Data Landscape, showing where the Pricing Condition sits relative to the Service Product it prices and the templates that consume it.

Data hierarchy with a concrete example

Material Master "SRV-001" (Type DIEN · UoM H)
   │
   └── ── based on ──> Service Product "SRV-PM-01" (Preventive Maintenance · UoM H)
                              │
                              ├── ── priced by ──> Pricing Condition "PR00" — Base Price, JPY 15,000 / H
                              │
                              └── ── used in ──> Service Contract Template "SCT-001" (Item Cat. SCN)

Note: Sales Organization and Distribution Channel are not shown as separate hierarchy nodes here — in this client-level zone they are key fields carried within the Condition Record itself (see 2.3), not standalone org-level nodes.

1.4 Integration with Other Master Data Objects#

A Pricing Condition never stands alone — it is only meaningful in combination with the object it prices and the organizational context in which it was maintained.

Part 2: SRV-Specific Field Details#

2.0 Scope of SRV Ownership#

Legend: ◎ = Owner / Critical, ○ = Direct involvement

2.1 Condition Type Definition#

Condition Type is the Customizing object (transaction V/06) that defines how a given kind of price, discount, or surcharge behaves before any actual value is ever entered.

2.2 Condition Table & Access Sequence#

The Access Sequence is the ordered list of Condition Tables the system checks, from most specific to least specific, to find a valid Condition Record for a line item.

2.3 Condition Record Maintenance#

The Condition Record is the actual maintained data — the specific price or discount value tied to a specific key combination — created via VK11 or the Fiori “Manage Pricing Conditions” app.

2.4 Pricing Procedure Determination#

The Pricing Procedure determines which Condition Types are even searched for on a given Service Order or Service Contract, and in what sequence they are calculated.

2.5 Variant / Configurable Service Pricing (VASE)#

When a Service Product is configurable (Material Type KMAT under Advanced Variant Configuration), a standard single Condition Record cannot capture every possible characteristic combination — VASE exists precisely for this case.

Prerequisite: Configurable Service Products require AVC (Advanced Variant Configuration) mode; the Classic Variant Configuration mode is not supported for this scenario.

What to Read Next#

L1) Big Picture

L2-A) Master Data