KNVI table — Customer Tax Classification Table KNVI

Each row in KNVI represents the tax classification assigned to one customer for one tax category in one departure country. Tax category here means things like output tax under a given tax procedure's access sequence step, not the tax code itself. The classification value (commonly 0, 1, or a country-specific code) tells pricing which tax condition record to pick when the sales document's departure country matches. Unlike KNVV, which is sales-area dependent, KNVI is scoped by country because tax law is territorial, not organizational. A customer with operations serviced from plants in two countries can have two different classification rows, one per departure country, and both feed different orders depending on which plant ships the goods.

KNVI is small relative to KNVV and rarely a performance concern, but always restrict by MANDT and KUNNR first since ALAND and TATYP alone are not selective. A customer typically has only a handful of rows, one per relevant departure country and tax category combination, so a full customer lookup is cheap. The trap is assuming a missing row means bad master data maintenance when it may simply mean the customer has never transacted with that departure country before, so no row was ever created.

Symptom: an order line shows no tax or the wrong tax code and pricing analysis shows the tax condition found no valid record. Select KNVI where KUNNR equals the sold-to or payer used in the order and ALAND equals the departure country of the shipping plant. If no row exists for that country, the classification defaulted to blank or an inherited value that does not match any tax condition record, which is why pricing came back empty.

KNVI is unchanged in shape on S/4HANA and continues to be maintained through the standard customer master transactions. It is not one of the tables restructured by the S/4HANA business partner data model consolidation in the same way KNA1 and KNVV address fields were affected; tax classification maintenance and storage remain consistent with the ECC design.

Tax classification setup is typically owned jointly by SD master data and the tax or finance team that defines which classification values map to which tax codes in the pricing procedure. When tax comes out wrong on a document, SD confirms whether KNVI has the expected row; finance or tax confirms whether the classification-to-tax-code mapping in the condition records is correct.

KNVV holds the sales-area dependent customer data that sits alongside KNVI on the same maintenance screens. KNA1 provides the general customer master data. VBAP and VBRP carry the tax classification once copied into the order and billing document, and pricing conditions such as KONV and KONP store the actual tax condition records that KNVI's classification value helps select.