VBUK table — Sales Document Header Status Table

One row in VBUK represents the current aggregated processing status of one sales document header - the same document identified by VBELN in VBAK. VBUK does not store any business data such as customer, material or quantity; it stores derived status indicators that SAP recalculates whenever the document or its subordinate documents (deliveries, billing documents) change. These status fields answer questions like whether the order is fully delivered, fully invoiced, still blocked for credit, or has been rejected, without forcing a scan of every item or every downstream document. Because the status is an aggregate across all items of the document, a single VBUK row can mask mixed states at item level - one item delivered, another still open - which is the single most common source of confusion when working with this table.

VBUK is a one-to-one satellite of the sales header table, sharing the same primary key value.

MANDT is the first key field and must always be restricted, though most reporting tools handle this automatically. VBELN is the only other key field, so a lookup by document number is always a single-row read - fast even on a large client. The table itself is not large relative to VBAK since it is one row per document, so selectivity is rarely a performance concern; the real risk is selecting on a status field alone (for example GBSTK equal to a certain value) across the whole client, which returns an enormous result set with no business context. Always join to VBAK first to restrict by sales organization, document type or date, then filter on VBUK status fields, not the other way around.

To confirm a claim that 'order 12345 is fully delivered but billing has not happened', select VBUK where VBELN equals 12345 and check LFSTK against the completed value and FKSTK against the open value. If LFSTK shows completed and FKSTK shows open or partially processed, the delivery side is closed and the gap is on the billing side - check VBRK/VBRP for a missing billing document or a blocked billing due list entry rather than assuming a delivery problem.

VBUK continues to exist as a physical table in S/4HANA and is still populated and read exactly as in ECC; there is no compatibility view replacing it because the status logic and simplified sales document model kept the same header/item status split. Custom code and queries built against VBUK on ECC continue to work unchanged on S/4HANA. The status fields themselves have not changed meaning across releases known with certainty.

Status discrepancies on VBUK are an SD functional question first - the SD consultant configuring order and delivery types, copy control and status profiles owns the logic behind how status is derived. If the underlying update itself is stuck or delayed, that becomes a basis question about update task processing, not a data model question about VBUK.

VBAK carries the business header data that VBUK's status mirrors; VBUP carries the equivalent item-level status detail. VBFA links the sales document to the deliveries and billing documents that actually drive status changes, and VBRK/VBRP are read when the billing status specifically needs explanation. Transactions VA01/VA02/VA03 for order maintenance, VL01N/VL02N for deliveries, and VF01/VF02 for billing all trigger the update that recalculates VBUK in the background.