VBUK table — Sales Document Header Status (ECC; Eliminated in S/4HANA)
VBUK is the classic ECC header-status table for sales and delivery documents, containing aggregated processing, delivery, billing, goods-movement, credit, and related status fields. In S/4HANA, VBUK persistence was eliminated and relevant status fields were moved into the corresponding document header tables such as VBAK, LIKP, and VBRK.
VBUK is the status-carrier twin of VBAK, storing rolled-up header status fields for a sales document rather than business content. This page covers the key status fields, how they roll up from item level, the joins consultants actually write, and the recurring mistake of trusting VBUK status without checking the item-level VBUP breakdown or the underlying document flow in VBFA.
Published 20 Sept 2026· 924 words
Diese Seite ist noch nicht auf Deutsch verfügbar.
What it stores
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.
Key fields
- ECC: VBELN — document number.
- ECC: header-level processing, delivery, billing, goods-movement, and credit status fields.
- S/4HANA sales documents — read relevant header status from VBAK.
- S/4HANA delivery — read relevant header status from LIKP.
- S/4HANA billing — read relevant header status from VBRK.
How it joins the data model
VBUK is a one-to-one satellite of the sales header table, sharing the same primary key value.
- VBUK-VBELN = VBAK-VBELN
- VBUK-VBELN = VBUP-VBELN (header status vs item status, one-to-many)
- VBUK-VBELN = VBFA-VBELV (as preceding document in document flow) or VBFA-VBELN (as subsequent document)
- VBUK-VBELN = VBEP-VBELN when checking schedule line rollups behind the header status
How to read it safely
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.
How to prove it in the data
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.
ECC vs S/4HANA
SAP S/4HANA conversion documentation explicitly lists elimination of status tables VBUK and VBUP. Header status fields moved to the relevant sales, delivery, and billing header structures. New S/4HANA code must not assume VBUK is still the physical status table, even if compatibility or search artifacts exist in a particular release.
Common pitfalls
- Treating GBSTK or LFSTK equal to completed as proof every item is closed - the header status is an aggregate and a single open item can sometimes still show a header status that looks closed depending on how partial processing is configured, so cross-check VBUP for the item detail before reporting an order as fully resolved.
- Assuming VBUK updates in real time during a batch run - status recalculation can lag slightly behind the triggering document change if update tasks are queued, so a status read immediately after a delivery post may still show the old value for a few seconds.
- Using CMGST alone to explain why an order is stuck - credit status can show as released while the order is still blocked for a completely different reason such as a pricing incompletion or a delivery block set independently on VBAK.
- Filtering large selections directly on VBUK status fields without joining to VBAK first, which returns results spanning every sales organization and document type in the client and produces a report nobody can use.
- Forgetting that ABSTK (rejection status) is independent of GBSTK - a document can carry a completed overall status while individual items are rejected, which shows correctly in ABSTK but is invisible if only GBSTK is checked.
Whose problem this is
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.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/vbukERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.