KNVP table — Customer Master Partner Functions Table
KNVP stores the partner function assignments maintained on the customer master at sales area level - which customer numbers act as ship-to, bill-to, payer or sold-to for a given customer in a given sales organization, distribution channel and division. It is the source data that partner determination copies into sales documents (VBPA); it is not the partner data actually sitting on a live order.
KNVP holds the customer-master-level partner function records (ship-to, bill-to, payer, and additional partners) per sales area, one row per partner function occurrence per customer. This page covers its key fields, how it joins into KNA1 and KNVV, and the recurring confusion between master data partners here and document partners frozen into VBPA at order creation.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,017 words
What it stores
Each row in KNVP represents one partner function assigned to one customer for one sales area: a given KUNNR, in a given VKORG/VTWEG/SPART combination, has a partner of function PARVW (sold-to, ship-to, bill-to, payer, or an additional function configured for the account group) fulfilled by another customer number KUNN2 (or in some setups a vendor or personnel number). Because a customer can have several ship-tos or several payers, a counter field distinguishes multiple occurrences of the same function, and a default indicator marks which one is proposed automatically when a sales document is created. This table is pure master data configuration - it defines what partner determination should propose, not what was actually used on any particular document.
Key fields
- MANDT - client
- KUNNR - the sold-to customer whose master record this partner assignment belongs to
- VKORG - sales organization
- VTWEG - distribution channel
- SPART - division (together with VKORG and VTWEG these form the sales area key)
- PARVW - partner function (for example AG sold-to, WE ship-to, RE bill-to, RG payer)
- PARZA - sequential counter distinguishing multiple partners with the same PARVW
- KUNN2 - the customer number that fulfils the partner function
- LIFNR - vendor number, used when the partner function is fulfilled by a vendor rather than a customer
- PERNR - personnel number, used when the partner function is an internal employee
- DEFPA - default partner indicator, marks which entry is proposed automatically for that function
How it joins the data model
- KNVP-KUNNR = KNA1-KUNNR (the sold-to whose master record owns the partner list)
- KNVP-KUNN2 = KNA1-KUNNR (the assigned partner is itself a customer master record)
- KNVP-KUNNR/VKORG/VTWEG/SPART = KNVV-KUNNR/VKORG/VTWEG/SPART (sales area data the partner functions are attached to)
- KNVP entries are the template read at document creation to populate VBPA-PARVW/VBPA-KUNNR on the sales document header, though VBPA is stored independently once written
How to read it safely
Always restrict on MANDT and KUNNR first; without KUNNR this table is scanned in full and is not small in any live system with a real customer base. Selectivity improves sharply once VKORG, VTWEG and SPART are added, since most customers only have entries for the sales areas they are actually extended to. PARVW narrows further when only one function is of interest. Do not attempt to browse KNVP by PARVW alone across all customers looking for, say, every payer relationship system-wide; that selection has almost no index support and will run against the full table.
How to prove it in the data
Symptom: a sales order proposes the wrong ship-to, or none at all, for a customer newly extended to a sales area. Select KNVP on KUNNR, VKORG, VTWEG, SPART, PARVW = 'WE'. If no row exists, no ship-to has been maintained for that sales area and partner determination has nothing to propose. If rows exist but none has DEFPA set, the system will require manual partner selection instead of defaulting one.
ECC vs S/4HANA
KNVP continues to exist in S/4HANA in the same shape for SD sales area partner functions. Where the system uses the business partner model with customer-vendor integration, changes to partner relationships made through the business partner transaction are synchronized down into KNVP so that classic SD documents and partner determination logic keep working unchanged. The underlying business logic for partner determination in sales documents still reads KNVP the same way it did in ECC.
Common pitfalls
- Treating KNVP as the record of what partner was used on an order. It is not; VBPA is written at document creation from KNVP's default entries and can then be changed manually or overridden by output of the partner determination procedure, so KNVP and VBPA can legitimately disagree for a specific document without either being wrong.
- Assuming a partner function is missing system-wide when it is only missing for the sales area being checked. KNVP is sales-area specific; a customer freshly extended to a new distribution channel or division starts with no partner records there even if the same customer has a full set in another sales area.
- Missing the default flag and concluding the configuration is broken when in fact multiple valid partners of the same function exist (several ship-tos, for example) and none has been marked default, so the document simply prompts for selection instead of erroring.
- Forgetting that KUNN2 can point to a customer master that itself is incomplete or blocked - the KNVP row looks perfectly correct while the referenced customer lacks company code data or is blocked for the relevant sales area, which surfaces later as a billing or credit management failure rather than an order entry error.
- Editing KNVP directly outside the standard maintenance transaction to fix a partner in bulk. This bypasses partner determination consistency checks and account group authorization checks that the customer master transactions enforce, and can leave inconsistent PARZA numbering.
Whose problem this is
Customer master data governance owns KNVP content, whether that sits with a dedicated master data team, MDG, or the SD functional team acting as data steward. SD functional consultants own the partner determination configuration that decides which functions are mandatory and how defaults are proposed; they do not typically own the individual customer records themselves.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/knvpERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.