KONP table — KONP Condition Item Table
KONP stores the rate, percentage, or scale value of a pricing condition record, one row per scale line (KNUMH plus KOPOS). It holds the amount (KBETR), currency, pricing unit, and calculation type. The condition type and validity dates that identify what the record is for sit in KONH; KONP only holds the value side of the record.
KONP is the item-level condition record table underlying SAP pricing master data, holding the actual rate or amount for each scale line of a condition record. This page covers how it joins to KONH and document-level condition data, how to read it without a KNUMH already in hand, and the recurring mistake of confusing a master rate with what a document actually priced.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,028 words
What it stores
One row in KONP represents a single scale line of a single condition record: the value side of a price, discount, surcharge, freight rate, or rebate rate maintained through condition maintenance (VK11 to create, VK12 to change, VK13 to display). The record is identified by KNUMH, an internally assigned number with no business meaning, and KOPOS distinguishes scale steps within the same record (KOPOS 1 is the base line, higher values are further graduated scale tiers). The condition type, the key combination the record was created against, and its validity period are not stored here; they live in KONH, which shares the same KNUMH. KONP alone answers what value applies; KONH answers what the record is for and when it applies.
Key fields
- MANDT - client
- KNUMH - condition record number, the join key to KONH and to document-level condition data
- KOPOS - scale line number within the record; 1 for a flat rate, higher numbers for graduated scale steps
- KBETR - the condition rate, amount, or percentage itself
- KONWA - currency key of KBETR
- KPEIN - condition pricing unit, the quantity KBETR is expressed per
- KMEIN - unit of measure for the pricing unit
- KRECH - calculation type, controlling whether KBETR is a percentage, fixed amount, or quantity-based rate
- LOEVM_KO - deletion indicator flagging the scale line or record for deletion
How it joins the data model
- KONP-KNUMH = KONH-KNUMH, the join to the header: condition type, key fields, and validity dates
- KONP-KNUMH = KONV-KNUMH, the join from the master rate to the condition line copied into a sales or billing document at the moment of pricing
- KONP-KNUMH = KONA-KNUMH, for condition records tied to a rebate or sales agreement
- KOPOS must be matched consistently across scale-dependent reads; joining on KNUMH alone without KOPOS returns every scale line, not the applicable one
How to read it safely
KNUMH is not something a user types and cannot be guessed; it must be resolved first from KONH (by condition type and key fields) or from a document's KONV entry. Selecting on KONP without a KNUMH filter scans the entire table of every pricing record ever created in the client, which on an aged system is large and slow. The table is client-dependent (MANDT). Restrict by KNUMH first, then order by KOPOS if the condition type uses scales, and always cross-check DATAB/DATBI on the corresponding KONH row before trusting a value as currently active, since expired records with the same key combination are not deleted, only superseded.
How to prove it in the data
Symptom: an order shows a price that looks wrong for a given material and customer. Read the document's condition data in KONV for that item to find the condition type and KNUMH actually used at pricing time. Select KONP where KNUMH equals that value, ordered by KOPOS, and compare KBETR, KONWA, and KPEIN against what VK13 displays as current. If they match, the document priced correctly against stale master data or an unexpected scale tier; if they differ, the document was never repriced after the master record changed.
ECC vs S/4HANA
KONP and KONH remain in S/4HANA in the same structure and role as in ECC, continuing to serve as the persistence layer for condition records maintained through standard condition maintenance transactions. The document-level counterpart, KONV, has been supplemented in the newer S/4HANA pricing engine by additional structures for storing pricing results, with compatibility views preserving KONV-based reads for existing code. KONP itself was not replaced or restructured.
Common pitfalls
- Treating a wrong price on a saved document as a KONP data error, when the real cause is that the document was never repriced after the master condition record changed; KONV in the document keeps the value from the moment it was priced, not a live pointer to KONP
- Reading only KOPOS 1 for a scaled condition type and reporting a flat rate that does not match what actually applied, because the order quantity fell into a higher scale tier
- Comparing KNUMH values across systems (test versus production) as if they carried business meaning; the number is internally assigned per system and tells nothing on its own
- Ignoring validity dates on KONH and picking up an expired record from KONP that happens to share the same key combination as a currently valid one
- Trusting a row is inactive because it looks old, without checking LOEVM_KO; conversely, assuming LOEVM_KO being set means the row disappears from every report, when custom queries that do not filter on it will still show it
- Editing a condition record through VK12 and expecting already-saved sales or billing documents to update automatically; they do not, by design, unless explicitly repriced
Whose problem this is
Which rates should be loaded, and why a record is wrong, is a pricing master data question owned by the SD pricing or commercial team maintaining condition records. Why a record was not picked up by a document, or why an access sequence resolves to the wrong table, is an SD configuration question. A rate that never loaded correctly usually traces back to a data migration or mass load into condition maintenance, not to a defect in the table itself.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/konpERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.