VBAP table — Sales Document Item Table

One row in VBAP represents a single item within a sales document, identified by the document number VBELN and the item number POSNR. The item can be a standard material line, a text item, a free goods line, a higher-level item in a bill of materials structure, or a service item. VBAP holds the commercial and logistical attributes of that line: item category, plant, storage location, order quantity, sales unit, net value, currency, route, and rejection reason if the line has been cancelled. It applies uniformly across sales document categories because inquiries, quotations, orders, contracts, and scheduling agreements all use the same header-item structure, VBAK and VBAP. The document category itself is read from VBAK, not from VBAP, so VBAP alone cannot tell what type of document the item belongs to.

MANDT is implicit in most tools but still the logical first filter. VBELN is highly selective and should be the primary restriction whenever the document number is known; POSNR alone is close to useless since it repeats across every document. Never select on MATNR or WERKS across the whole table without also restricting VBELN or a date range, the table is large in any live SD system and an unrestricted scan on those fields will run for a long time. If the starting point is a customer or date rather than a document number, query VBAK first with VKORG, ERDAT, or KUNNR, extract the VBELN list, then join into VBAP. Watch for leading zeros in VBELN when pasting document numbers manually.

Symptom: a sales order item shows zero net value on the order screen. Select VBAP for that VBELN and POSNR and check NETWR and WAERK directly. If NETWR is genuinely zero and ABGRU is blank, the item priced at zero, which points at the condition records in KONV via VBAK-KNUMV and KPOSN = POSNR, not at VBAP itself. If ABGRU is populated, the item was rejected and a zero value is expected and correct.

VBAP remains a transparent table with essentially the same structure in S/4HANA, it was not replaced or restructured as part of the SD data model simplification. It sits underneath the sales order CDS view layer used by newer Fiori apps and analytical reporting, but that layer reads from VBAP rather than replacing it, so direct table access, ABAP reports, and legacy queries built against VBAP continue to work unchanged. The business partner model change affects customer master tables, not VBAP.

Order management or SD functional consultants own questions about item category determination, pricing results, and rejection reasons stored here. Basis or data management owns table growth and archiving. If the dispute is about what the customer was actually charged rather than what the order line shows, ownership shifts to billing, which means VBRP and VBRK, not VBAP.

VBAK is the header counterpart, written together with VBAP by VA01, VA02, and their document-type-specific transaction variants. VBEP carries schedule lines, VBUP carries item status, VBKD carries item-level business data, all three are maintained in the same transactions as VBAP. VBFA is the document flow table that links VBAP items forward into delivery items in LIPS and billing items in VBRP. Pricing results shown in VBAP-NETWR trace back to condition records in KONV.