VBUP table — Sales Document Item Status (ECC; Eliminated in S/4HANA)
VBUP is the classic ECC item-status table for sales and delivery document items, containing overall processing, delivery, billing, goods-movement, rejection, and related item statuses. In S/4HANA, VBUP persistence was eliminated and the relevant status fields were moved into the corresponding item tables such as VBAP and LIPS.
VBUP is the item status table in SD, holding the derived processing flags for each sales document item. This page covers the status fields that matter, how they relate to VBAP, VBAK, VBUK and VBFA, and the pattern of misreadings that lead consultants to blame the wrong status field.
Published 20 Sept 2026· 910 words
Esta página aún no está disponible en español.
What it stores
One row in VBUP represents the current processing status of exactly one sales document item, identified by document number and item number. It does not store business data - no quantity, no material, no pricing - only status flags derived from the documents that reference this item, such as deliveries, goods issues, billing documents and rejections. Each flag is maintained by the system as those follow-on documents are created, changed or reversed; it is not something a user sets directly. VBUP exists alongside VBUK, which holds the same kind of information rolled up to the header. The two tables can disagree temporarily if an update was interrupted, which is one of the more common sources of confusion when investigating why a document behaves inconsistently with what its header status suggests.
Key fields
- ECC: VBELN and POSNR — document and item key.
- ECC: item-level processing, delivery, billing, goods-movement, and rejection status fields.
- S/4HANA sales document items — relevant status fields reside in VBAP.
- S/4HANA delivery items — relevant status fields reside in LIPS.
- Use released sales and delivery CDS views for new extension analytics where available.
How it joins the data model
- VBUP-VBELN = VBAP-VBELN and VBUP-POSNR = VBAP-POSNR, one-to-one, every VBAP row has exactly one VBUP row
- VBUP-VBELN = VBAK-VBELN, to reach header data such as sales document type and sold-to
- VBUP-VBELN = VBUK-VBELN, item status against header status for the same document
- VBUP-VBELN = VBEP-VBELN with matching POSNR, schedule line confirmation feeds into delivery status
- VBUP-VBELN and VBUP-POSNR appear as predecessor keys in VBFA, so document flow entries explain why a given status flag changed
How to read it safely
Always restrict on MANDT first, then on VBELN, ideally with POSNR if the item is already known. VBUP alone is not a useful entry point - it has no descriptive fields to filter on, so a scan of the table without a document list from VBAK or VBAP joined in is pointless and slow. The status fields are single-character codes, typically blank, A, B or C, but the meaning of each code is specific to the field it appears in; a C in LFSTA and a C in FKSTA are unrelated facts that happen to share a symbol. Treat this table strictly as a lookup against a document or item list already selected elsewhere, never as a starting filter.
How to prove it in the data
Symptom: a sales order line cannot be delivered again, system says fully processed, but the customer reports nothing arrived. Select VBUP for that VBELN and POSNR. If LFSTA shows fully processed but WBSTA does not, a delivery document exists and is blocking reprocessing even though goods issue was never posted. Confirm by pulling VBFA for the same item to see which delivery document was created and in what status, rather than assuming the order line itself is faulty.
ECC vs S/4HANA
SAP S/4HANA conversion documentation explicitly identifies VBUK and VBUP status-table elimination. New S/4HANA diagnostics and custom code should read the relevant status fields from the business-document header and item tables rather than treating VBUP as a physical write target.
Common pitfalls
- Reading GBSTA as the whole story - it is a rollup and can mask which specific sub-process (delivery, billing, goods movement) is actually stuck
- Assuming the same character code means the same thing across different status fields - each field has its own value domain
- Assuming VBUK and VBUP always agree - if a status update run was interrupted, header and item status can diverge and stay divergent until reprocessed
- Editing status fields directly in the table to unblock a document - this desynchronizes VBUP from the actual document flow in VBFA and creates a worse inconsistency than the one being fixed
- Assuming a rejected item disappears from the table - rejection sets ABSTA, the row and the item both remain
- Assuming status reflects quantity matching - a status field showing partial or complete processing says a follow-on document exists, not that quantities reconcile; a delivery of one unit against an order for ten still changes LFSTA away from blank
- Chasing the wrong document type when a status looks stuck - the fix is almost always in the copy control or item category status group configuration, not in the status table itself
Whose problem this is
This is an SD order management question, not a Basis or technical one. The consultant configuring item categories, copy control and status determination owns the behaviour that populates these fields. When status looks wrong, the fix lives in customizing or in reprocessing the document, never in a direct table change.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/vbupERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.