VBKD table — VBKD Sales Document Business Data Table

One row in VBKD represents the business data of either the sales document header or one specific item of that sales document. The table is structured so that a header-level row exists with item number 000000, holding the values that apply to the whole document by default. If an individual item needs different terms, a separate row is written for that item's own POSNR, and that row overrides the header value for that item only. This means VBKD is not a simple one-row-per-item table like VBAP; it is a mixed header-and-item table sharing one structure. Fields covered include payment terms, incoterms, the customer purchase order number and date, pricing date, billing date, and the exchange rate used for the document. It does not hold quantities, materials, or condition values.

MANDT is the first key field and must be restricted in any direct table access, as with every SD table. VBELN is the second key and is highly selective on its own; restricting on VBELN alone before adding POSNR is the safe pattern, because scanning by ZTERM or INCO1 across the whole table without a document number is a full scan on a table that can be large in a mature system. When pulling business data for a set of documents, select all POSNR values including 000000 rather than filtering POSNR to a specific item up front, otherwise the header fallback row is excluded and fields appear blank for items that were never given their own override.

Symptom: a billing document shows payment terms that do not match what is displayed on the sales order screen for a specific item. Select VBKD where VBELN equals the order number and POSNR equals both 000000 and the specific item number. If the item-level row exists and its ZTERM differs from the header row's ZTERM, the item override is what fed the billing document; the header value seen on the overview screen is not what was actually used for that line.

VBKD is retained in S/4HANA as an active transparent table with the same header-plus-item structure; it has not been replaced by a compatibility view or restructured. Sales document processing logic in S/4HANA still reads and writes VBKD the same way ECC does, so joins, key structure, and the 000000 header convention behave identically. No field-level changes specific to this table are documented as part of the S/4HANA simplification list for the sales order object.

Discrepancies in VBKD content are an SD order management question first, since order entry, copy control, and pricing/billing date determination are configured and tested by the SD team. Payment terms or incoterms mismatches that trace back to master data defaults are a shared question with the customer master data owner. Finance gets involved only when the downstream financial document shows a value that does not match what VBKD recorded for the order.

VBAK and VBAP are the header and item tables VBKD attaches business data to, written by the same order creation and change transactions such as sales order create and change. VBFA is used to trace which VBKD-sourced business data reached which delivery or billing document downstream. KNVV supplies the customer master defaults that populate VBKD at document creation before any manual override. KONV holds the pricing condition values that PRSDT in VBKD helps determine but does not itself contain.