VBUP table — Sales Document Item Status Table

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.

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.

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.

VBUP is unchanged in S/4HANA in terms of structure and role. It is not superseded by a CDS compatibility view as the primary write target; the underlying update logic for item status still populates this table directly. Reporting-oriented CDS views built on top of VBAK, VBAP, VBUK and VBUP exist for analytics, but for diagnosing a specific document's status the table itself is still the object to query.

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.

VBUK is the header-level equivalent, maintained by the same update logic. VBAP and VBAK hold the item and header data that VBUP has no business fields of its own for. VBFA is the document flow table that explains which follow-on documents actually drove a given status change. VBEP carries schedule line data that feeds delivery-related status. Transactions VA01, VA02, VA03 for the sales order and VL01N, VL02N for the delivery are what trigger the updates that change VBUP.