Purchase Order Pricing Condition Table in SAP: A017, KONV

Purchase order pricing in SAP is spread across four layers, and the table you need depends on which question you are asking. The prices actually on a purchase order live in the document condition table, KONV in ECC and PRCD_ELEMENTS in S/4HANA, reached from EKKO-KNUMV. The reusable condition records live in KONH and KONP. The access layer that decides which record gets found is the numbered condition tables, A016, A017 and A068. Customizing sits in T685A, T682I and T683S.

Last updated August 2026.

Where purchase order pricing actually lives in SAP

Almost every confused query about SAP purchase order pricing comes from mixing up two different things: the price that was calculated on one specific order, and the master record that supplied it. They are stored in completely different tables, and a report built against the wrong one gives an answer that looks plausible and is wrong.

Layer	Table	Key	What it holds
Document conditions	KONV in ECC, PRCD_ELEMENTS in S/4HANA	KNUMV, KPOSN, STUNR, ZAEHK	The condition lines actually calculated on a specific purchasing document, one row per condition type per item
Condition record header	KONH	KNUMH	The header of a reusable condition record, including validity dates DATAB and DATBI
Condition record item	KONP	KNUMH plus KOPOS	The rate, currency, unit and scale control of the record. KONP holds no validity dates, those are on KONH
Condition tables	A016, A017, A068 and the rest of the Annn range	Varies by key combination	The index that maps a key combination to a KNUMH, which is how a record is found in the first place
Condition types	T685 and T685A	KSCHL	The definition of PB00, FRA1, SKTO and every other condition type, including its category and calculation rule
Access sequences	T682 and T682I	KOZGF	The ordered list of condition tables a condition type searches
Pricing procedure	T683 and T683S	KALSM	The calculation schema, RM0000 in standard purchasing, and its steps

The bridge from a purchase order to its conditions is a single field. EKKO-KNUMV carries the document condition number, and that value is the KNUMV key of the condition table. Join EKKO to KONV or PRCD_ELEMENTS on KNUMV, and match KPOSN to the EKPO item number, and you have the full price breakdown for the order including freight, discounts and tax lines that never appear in EKPO at all.

What is the purchase order pricing condition table in SAP?

If you mean the table holding the prices on the order itself, it is KONV in ECC and PRCD_ELEMENTS in S/4HANA, keyed on the document condition number KNUMV from EKKO. If you mean the table that supplies those prices, it is KONP, indexed by the condition tables in the Annn range, of which A017 for purchasing info records is by far the most used.

The reason both answers are correct is that SAP copies. When a purchase order is created, the pricing procedure runs, each condition type searches its access sequence, and any record it finds is copied into the document conditions as a new row. From that moment the order carries its own frozen copy. Change the info record price tomorrow and yesterday's purchase order does not move, which is exactly what you want for audit and exactly what surprises people writing their first pricing report.

PB00 and access sequence 0002: the three tables SAP actually searches

PB00 is the gross price condition type in standard purchasing, described by SAP as the price without taking any possible discounts and surcharges into account. It carries access sequence 0002, and that access sequence is the single most useful thing to understand about purchase order pricing, because it explains the order of precedence every buyer eventually asks about.

Access order	Condition table	Question it asks
1	068	Does a plant-specific agreement item exist?
2	016	Does a contract item exist?
3	017	Does a purchasing info record exist?

SAP notes that with the access to table 017 the record is normally found and the search ends. That is the practical rule behind a very common support question: a contract price beats an info record price, because the contract access runs first and the search stops at the first hit. Nothing is averaged and nothing is combined. The first access that returns a record wins.

PB00 also carries condition category H, base price, and SAP states that a condition type with condition category H must always exist in the calculation schema, with stock transfers as the exception. If someone has built a custom schema and prices are behaving strangely, a missing category H condition is worth checking before anything more exotic.

What is the difference between PB00 and PBXX?

PB00 is the automatic gross price and PBXX is the manual one. PB00 has access sequence 0002, so it searches for a condition record in agreements, contracts and info records. PBXX has no access sequence at all, which means it can only ever be typed in by hand on the document. SAP requires both in the standard schema: RM0000 and RM1000 each need one gross price condition type for automatic determination and one for manual maintenance.

That design is deliberate rather than redundant. A buyer creating a one-off purchase order for a part with no info record still needs somewhere to enter a price, and PBXX is that slot. The moment a condition record does exist, PB00 finds it and fills the price automatically, and PBXX stays empty. Seeing both condition types listed in the schema and assuming one is obsolete is a common misreading of the standard configuration.

One more practical difference: PB00 is time dependent, because it is backed by condition records that carry validity dates, while a value keyed into PBXX belongs to that document and nothing else.

RM0000 and RM0002, and why there are two schemas

RM0000 is the standard calculation schema SAP delivers for determining the purchase price in purchasing documents. RM0002 is a supplementary calculation schema, and SAP assigns it to condition type PB00 specifically.

The distinction trips people up because a supplementary schema is not an alternative to the main one. Discounts, surcharges and freight are frequently maintained in relation to the gross price rather than independently, so they are entered as condition supplements against the PB00 record and grouped in RM0002. SAP's rule is that if an access sequence is assigned to a condition type, a supplementary calculation schema must be assigned to it as well. Any condition type used in a supplementary schema also has to be present in the document schema, so RM0002 does not let you smuggle in a condition RM0000 has never heard of.

The standard purchasing condition types, and what each one is for

The table below covers the condition types most US teams meet in a purchase order. Descriptions and behavior are the standard delivered ones, but every SAP landscape gets customized, so confirm against your own M/06 before relying on any of it in a report.

Condition type	Purpose	Calculation basis
PB00	Gross price, found automatically through access sequence 0002	Condition record from agreement, contract or info record
PBXX	Gross price, entered manually	Typed on the document, no access sequence
RA00	Discount percent on net, applied across the condition types that build the net amount	Percentage
RA01	Discount percent on gross, applied only to the gross price	Percentage, supplementary to PB00
RB00	Absolute discount	Fixed amount
RC00	Discount per quantity	Quantity
ZA00	Surcharge percent on net, the mirror of RA00	Percentage
FRA1	Freight as a percentage	Percentage
FRB1	Freight as a fixed value	Fixed amount
FRC1	Freight per quantity	Quantity
NAVS	Non-deductible input tax, pulled automatically from the tax code calculation	Value from the tax procedure
NAVM	Non-deductible input tax, entered manually	Manual
SKTO	Cash discount, read from the payment terms rather than a pricing record	Percentage from the terms of payment
GRWR	Statistical value for the border-crossing value used in Intrastat reporting	Percentage of the line net value

Two of those rows carry a distinction worth spelling out, because it produces wrong numbers quietly rather than loudly. RA00 is a discount percent on net and is calculated across all the condition types that make up the net amount, while RA01 is a discount percent on gross and is calculated only on the gross price of the item. On an order with freight and surcharges those two produce different money from the same percentage.

FRA1, FRB1 and FRC1 are the item-level freight conditions, with FRA2, FRB2 and FRC2 as the corresponding header-level variants. What makes them behave as delivery costs is not the name but the condition category: KNTYP set to B, delivery costs, is what tells SAP to post the planned delivery cost to a separate clearing or provision account at goods receipt and clear it when the delivery cost invoice arrives. Note that KNTYP also has a value F for freight, which is not the same thing and does not drive that flow.

SKTO is the one people misread most often. It takes its percentage from the first rate in the item's terms of payment through condition category E rather than from any pricing condition record, and in the purchasing schema it is flagged statistical, so it displays the cash discount without changing the effective price.

The domain values behind the configuration screens

Three fields on T685A explain most condition type behavior, and knowing their fixed values saves guessing at a config screen.

Field	Meaning	Values worth knowing
KNTYP	Condition category	B delivery costs, D tax, E cash discount, F freight, H basic price, N sales tax not deductible
KRECH	Calculation type	A percentage, B fixed amount, C quantity, G formula
KOAID	Condition class	A discount or surcharge, B prices, C expense reimbursement, D taxes

Which tcode do I use for purchase order pricing conditions?

MEK1, MEK2 and MEK3 create, change and display purchasing condition records. M/06 maintains condition types, M/07 access sequences and M/08 the calculation schema. ME11, ME12 and ME13 maintain the purchasing info record, which is where the PB00 price usually comes from in practice.

Transaction	What it does
MEK1 / MEK2 / MEK3	Create, change and display purchasing condition records
ME11 / ME12 / ME13	Create, change and display a purchasing info record
M/06	Define condition types
M/07	Define access sequences
M/08	Define the calculation schema and its steps
ME23N	Display a purchase order, including the Conditions tab and its Analysis view

The Analysis button on the Conditions tab of ME23N is the fastest answer to nearly every "why is this price wrong" question. It shows each condition type, each access it attempted, and whether the access found a record or was skipped because a required field was empty. Reading that screen is faster than querying KONV, and it is the one troubleshooting step most people skip.

Why is my condition not showing in the purchase order?

Usually one of four things: the condition record's validity period does not cover the order date, a field in the access key combination is blank on the document so the access is skipped, an earlier access in the sequence already found a record and the search stopped, or the condition type is not in the calculation schema assigned to that vendor and purchasing organization.

There is a fifth case that looks like a bug and is not. When no valid condition record is found for the pricing date, SAP can fall back to the price on the last purchase order linked to the info record, rather than leaving the price at zero. That is why a buyer sometimes sees a price nobody can find a condition record for. The info record keeps the pointer to that last document, and the order price history is available separately, so the trail exists once you know it is a fallback rather than a determination.

The validity case is the most common and the least obvious, because DATAB and DATBI sit on the condition record header KONH rather than anywhere near the order. A record created last month with a start date of the first of next month simply is not there yet, and SAP does not warn you. The schema determination case is the second most common, and it bites when a new vendor is created with a schema group nobody set, so the vendor quietly picks up a different calculation schema from the one everyone assumes is in play.

What happened to KONV in S/4HANA?

KONV was replaced by PRCD_ELEMENTS as the table that stores document conditions. The part that catches people out is that KONV was not deleted. The dictionary object still exists, it is simply empty, so a legacy report that selects from KONV still compiles, still runs, and returns zero rows without raising a single error.

That is the expensive version of a migration bug. Nothing dumps and nothing alerts. A landed-cost report or a freight accrual extract just quietly starts reporting nothing, and it can run that way for months before somebody notices the numbers are too clean. If you are preparing for a conversion, grep the custom code for KONV rather than waiting for the tests to fail, because they will not fail loudly.

For read access there is a compatibility CDS view, V_KONV, which projects PRCD_ELEMENTS in the old KONV shape. Writing is a different matter: direct database updates to the pricing result are not supported, and the pricing result is meant to be built through the standard pricing API rather than by inserting rows.

This sits alongside the other purchasing table changes worth knowing during a conversion. EKKO and EKPO themselves remain real tables in S/4HANA rather than becoming compatibility views, which is covered in more depth in the reference on EKKO and EKPO purchase order tables and joins.

Why condition reporting was so slow before S/4HANA

There is a structural reason, and it is worth knowing because it explains why the old advice was always to enter through KNUMV. In ECC, KONV was a cluster table stored in cluster KOCLU, and the standard purchasing condition tables A016, A017, A018 and A025 are pooled tables in pool KAPOL. Cluster and pooled tables cannot be indexed or joined at the database level.

That is the whole story. You could not put a secondary index on KONV, you could not join it in a database view, and selecting on anything other than the leading key meant unpacking records one at a time. A068 is the odd one out among the condition tables, because it is transparent rather than pooled. In S/4HANA, PRCD_ELEMENTS is a transparent column store table, and that change in storage is the real performance difference, more than any index.

Why the price on EKPO does not match quantity times unit price

EKPO-NETPR is a net price expressed per price unit, and EKPO-PEINH is that price unit. A line priced at 250.00 with PEINH of 100 costs 2.50 each, so multiplying MENGE by NETPR and ignoring PEINH overstates that line by a factor of a hundred. There is a second factor almost nobody accounts for: the order price unit BPRME can differ from the order unit MEINS, with the conversion held in BPUMZ and BPUMN. The complete relationship is:

NETWR = MENGE × (BPUMN / BPUMZ) × NETPR / PEINH

SAP's own field documentation for the price unit works through the case that proves it. You order 10 liters, the vendor prices at 2.00 per kilogram, and the conversion is 2 liters per kilogram. The quantity in the price unit is 10 times 1 divided by 2, so 5 kilograms, and the value is 10.00. Multiply quantity by price naively and you get 20.00, which is double. What makes this bug so durable is that the formula collapses to MENGE times NETPR divided by PEINH whenever the order price unit equals the order unit, which is the common case, so the mistake passes testing and only surfaces on the minority of items priced in a different unit.

The safe answer is to use the values SAP has already calculated. NETWR is the net order value after discounts and surcharges, BRTWR is the gross order value before them, so the difference between the two is the net effect of the discount and surcharge conditions. Carry the currency from EKKO-WAERS, because EKPO has no currency field at all: every amount on EKPO references the header currency.

Non-deductible input tax is a further wrinkle: where it applies, the amount lands in EKPO-NAVNW as well as in the condition line of category N. And freight, discounts and surcharges are not in EKPO at all. They only exist as condition rows reached through KNUMV, which is the reason a landed-cost report cannot be built from EKPO alone.

Getting purchase order prices out of SAP, and the gap that remains

Once you know the joins, extracting historical pricing is straightforward. The pattern below is the usual starting point for a purchase order price extract.

SELECT  k.EBELN,          " purchase order number
        p.EBELP,          " item
        p.MATNR,          " material
        p.MENGE,          " quantity
        p.NETPR,          " net price per price unit
        p.PEINH,          " price unit
        p.NETWR,          " net order value, already calculated
        k.WAERS,          " currency, header only
        c.KSCHL,          " condition type, e.g. PB00 / FRA1
        c.KBETR,          " condition rate
        c.KWERT           " condition value
  FROM  EKKO AS k
  JOIN  EKPO AS p  ON p.EBELN = k.EBELN
  LEFT JOIN PRCD_ELEMENTS AS c          " KONV on ECC
         ON c.KNUMV = k.KNUMV
        AND c.KPOSN = p.EBELP
 WHERE  k.BSTYP = 'F'.                  " purchase orders only

Analysts who benchmark those contract prices against published list prices normally collect the reference side with a web scraping API that returns clean structured data rather than copying catalog pages by hand, then join the two sets on part number.

That covers everything already inside SAP. The gap is the orders that are not in SAP yet. A purchase order a customer emails you as a PDF has a price on it too, and no join reaches it. Someone reads the document and keys the header and every line before any of the tables above contain a single row about it.

That is the part PurchaseOrders handles. It reads a purchase order in PDF, scan or photo form and returns the order number, vendor, dates, line items, quantities and unit prices as Excel, CSV, JSON or API output, so the data is in columns before anyone opens SAP. It is a capture layer and nothing more: it does not connect to SAP, does not post documents, does not create condition records and does not run a pricing procedure. If your target is an SAP system, the purchase order to SAP converter covers how teams move that extracted data across.

Frequently asked questions

Which table stores condition records in SAP?

KONH holds the condition record header, including the validity dates DATAB and DATBI, and KONP holds the record items with the rate, currency and unit. Both are keyed on KNUMH. The numbered condition tables in the Annn range are the index that maps a key combination, such as vendor plus material plus purchasing organization, to the right KNUMH.

What is condition table A017 in SAP?

A017 is the condition table for the purchasing info record, and it is the third and usually final access in access sequence 0002 for condition type PB00. In most landscapes it is where the gross price on a purchase order actually comes from, because plant-specific agreements and contracts exist for a minority of parts while info records exist for most. Its sibling A018 carries the same key combination without the plant, so where the info record condition was maintained decides which of the two tables the record lands in.

What is the difference between KONV and KONP?

KONV, now PRCD_ELEMENTS in S/4HANA, holds the conditions calculated on one specific document and is reached through KNUMV. KONP holds reusable master condition records reached through KNUMH. A KONP record can supply many documents, and each of those documents keeps its own copy of the resulting condition line.

Where are pricing scales stored?

Quantity scales are in KONM and value scales are in KONW, both keyed on KNUMH plus the condition item KOPOS plus a scale line counter. KONP holds the rate only where no scale applies, and its scale type and scale basis fields tell you which of the two scale tables to read. A frequent cause of a missing price is that no scale line covers the ordered quantity, which is fixed by starting the first scale step at zero.

Does the pricing procedure differ by vendor?

It can. The calculation schema is determined from the schema group on the vendor master combined with the schema group on the purchasing organization, so two vendors can run different schemas in the same system. When a condition type is missing from an order for one vendor but present for another, mismatched schema groups are the first thing to check.

What is condition type GRWR used for?

GRWR carries the statistical value, the notional value of goods at the moment they cross a border, used for Intrastat reporting. Its calculation type is percentage and in the sample pricing procedures its base is the net value of the line item, with the system adding or removing a percentage for incidental expenses depending on the Incoterms.