VBAK table — VBAK Sales Document Header Table

One row in VBAK represents the header of a single sales document: a standard order, inquiry, quotation, contract, or scheduling agreement, identified by VBELN. The header carries data that applies to the whole document rather than to any one line: creation stamp, sales area (sales organization, distribution channel, division), sales office and group, document currency, net value at header level, and the number of the pricing document used to determine conditions. VBAK does not contain the customer number, the material, or quantities; those live in the partner, item, and business-data tables that hang off the same VBELN. A row in VBAK persists even after the order is fully delivered, invoiced, or rejected — deletion is rare, status is tracked elsewhere, not by removing the row.

Always restrict on MANDT first in any direct table access; forgetting it is the most common way to return rows from the wrong client in a shared development system. VBELN is the most selective field available and should anchor any single-document lookup. For date-range extracts, ERDAT is a reasonable second filter but has low selectivity on its own in a system with years of history, so pair it with VKORG or AUART. Never query VBAK without at least one of VBELN, a date range, or a sales-area combination; a bare select on AUART alone on a mature production system returns an unmanageable result set because order types have very low cardinality relative to row count.

Symptom: an order appears stuck with no delivery created. Select VBAK where VBELN equals the document number and check LIFSK for a header delivery block; a populated value confirms the block exists before looking anywhere else. Next check VBUK for the same VBELN and read the delivery status field to confirm nothing has been created downstream, then check VBFA with VBELV equal to the same VBELN to confirm no successor delivery document exists in the flow at all.

VBAK is retained as a transparent table in S/4HANA with its structure largely unchanged; it remains the primary persistence for sales document headers rather than being replaced by a compatibility view. Analytical and Fiori access typically goes through CDS views built on top of VBAK rather than reading it directly, but the table itself is still the object that VA01/VA02 write to. A small number of fields have been added over time to support newer functionality, but the core key fields behave the same as on ECC.

Questions about what a VBAK row should contain, why a header field carries a given value, or why pricing has not re-triggered belong to the SD order-management functional consultant. Structural changes to the table, custom append fields, or extraction logic for reporting belong to the ABAP or data team, but the business meaning is validated by SD, not by basis.

VBAP holds the item lines under each VBAK header. VBKD carries additional business data such as payment terms and incoterms. VBUK and VBUP hold overall and item-level status flags. VBPA holds partner assignments including sold-to and ship-to. VBFA records the document flow linking quotations, contracts, deliveries and invoices back to the order. VA01, VA02 and VA03 create, change and display the document that ultimately writes to VBAK; VA05 lists orders using it as the base table.