KNVV table — Customer Master Sales Area Data
KNVV holds the customer master data that is specific to a sales area, one row per customer per sales organization, distribution channel and division combination. It carries order, delivery and billing blocks, currency, incoterms, payment terms, pricing procedure assignment and customer group. If a row is missing for a given sales area, the customer has never been extended there and no sales document can be created against it.
This page covers KNVV, the sales-area segment of the customer master, and how it differs from the general (KNA1) and company code (KNB1) segments. It focuses on the diagnostic path for missing sales area extensions, block fields, and the common confusion between KNVV blocks and document-level blocks.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,060 words
What it stores
One row in KNVV represents the sales-area-specific view of a customer: a unique combination of customer number, sales organization, distribution channel and division. This is the segment SAP populates when a customer is extended to a new sales area beyond the general data in KNA1. It carries everything a sales document needs that is not company-code or general-data related: order, delivery and billing blocks, the currency used for that sales area, incoterms, payment terms, the customer's pricing procedure assignment, customer group, sales district, shipping condition and account assignment group for revenue determination. A customer can exist in KNA1 with no corresponding KNVV row at all, in which case no sales order, delivery or billing document can reference that customer in that sales area.
Key fields
- MANDT - client
- KUNNR - customer number
- VKORG - sales organization
- VTWEG - distribution channel
- SPART - division
- VKBUR - sales office
- VKGRP - sales group
- WAERS - sales area currency
- KTGRD - account assignment group for the customer, used in revenue account determination
- ZTERM - payment terms key
- INCO1 - incoterms part 1
- INCO2 - incoterms part 2 (location text)
- AUFSD - sales order block for this sales area
- LIFSD - delivery block for this sales area
- FAKSD - billing block for this sales area
- LOEVM - deletion flag at sales area level
- KDGRP - customer group
- BZIRK - sales district
- VSBED - shipping condition
- KALKS - customer pricing procedure indicator
- PLTYP - price list type
- AWAHR - order probability, used for quotations and forecasting
How it joins the data model
- KNVV-KUNNR = KNA1-KUNNR (general data)
- KNVV-KUNNR = KNB1-KUNNR (company code data, separate extension, no shared key with sales area)
- KNVV-KUNNR+VKORG+VTWEG+SPART = KNVP-KUNNR+VKORG+VTWEG+SPART (partner functions per sales area)
- VBAK-KUNNR = KNVV-KUNNR with VBAK-VKORG = KNVV-VKORG, VBAK-VTWEG = KNVV-VTWEG, VBAK-SPART = KNVV-SPART (confirms the order's sales area matches an existing extension)
- KNVV-VKORG = TVKO-VKORG, KNVV-VTWEG = TVTW-VTWEG, KNVV-SPART = TSPA-SPART (validate the sales area itself is configured)
How to read it safely
Always restrict by MANDT implicitly and always select on KUNNR together with VKORG, VTWEG and SPART as a set, not KUNNR alone. Selecting on KUNNR alone returns one row per sales area the customer has ever been extended to, which is misleading if the incident is specific to one sales channel. The table is not as large as document tables like VBAP, but scanning it without the sales area key still returns noise across every division and channel a customer participates in. When comparing customers, restrict to the same VKORG/VTWEG/SPART combination before drawing any conclusion, since blocks and terms are set independently per sales area.
How to prove it in the data
Symptom: order creation fails with a message that the customer is not defined for the sales area. Select KNVV where KUNNR equals the customer and VKORG, VTWEG, SPART equal the order's sales area. No row returned confirms the customer was never extended to that sales area, which is a master data gap, not a document error. If a row exists, check LOEVM for the deletion flag and AUFSD, LIFSD, FAKSD for active blocks before assuming the extension itself is faulty.
ECC vs S/4HANA
KNVV is retained in S/4HANA with its structure intact; sales area segment fields have not been restructured. Customer maintenance is done through the business partner transaction rather than the legacy customer transactions, but the sales area data entered there is still persisted into KNVV underneath. No functional replacement table exists for this segment; it remains the source for sales-area-specific customer attributes in both ECC and S/4HANA.
Common pitfalls
- Treating the customer master as one flat record: blocks, terms and pricing assignment in KNVV are per sales area, so a block visible in one sales organization does not mean the customer is blocked everywhere.
- Confusing KNVV with KNB1 or KNA1: a deletion flag or block can be set at the sales area level without touching company code data or general data, producing symptoms that look like a broader master data failure but are scoped to one segment.
- Reading LOEVM in KNVV as the definitive deletion status: a customer can be flagged for deletion in one sales area only, while remaining fully active in another.
- Assuming an order, delivery or billing block seen in a document was set at the KNVV default level: sales documents can carry their own header or item level block that overrides or duplicates the customer default, so the document tables need checking too, not just KNVV.
- Trying to fix a missing sales area by editing a field in KNVV directly: if the row does not exist, the fix is a customer extension to that sales area, not a field correction on a row that is not there.
- Assuming WAERS is the currency every order will actually post in: document currency can be overridden at order entry or driven by condition records, so KNVV currency is a default, not a guarantee.
- Blaming pricing configuration for a wrong revenue account when the real cause is a mismatched KTGRD value in KNVV feeding account determination incorrectly.
Whose problem this is
Sales area segment configuration and content is typically owned by the master data governance team in coordination with the SD functional consultant responsible for the affected sales organization. Company code segment questions belong to the finance/credit team against KNB1, not to the sales team. Order desk or business users raising a missing-extension incident should route it to master data governance rather than treating it as an order configuration defect.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/knvvERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.