VEPO table — Handling Unit Packing Item Table
VEPO stores the packing item lines that link a handling unit (VEKP header) to the source document content that was packed into it, typically a delivery item. One row represents one packed quantity of one material from one source document line, inside one handling unit. A delivery item packed into three boxes produces three VEPO rows against one VBELN/VBELP.
VEPO is the item-level table behind SAP handling unit management, recording what material and quantity from which source document line sits inside which handling unit. This page covers the join to the VEKP header and to the delivery, the usual splitting and quantity-mismatch pitfalls, and how packing data is proved out during a delivery or shipment investigation.
Reviewed by an ERPClimb SAP consultant on 15 Sept 2026· 1,050 words
What it stores
Each VEPO row represents one packed content line: a specific quantity of a specific material, taken from one line of a source document, placed inside one specific handling unit. The handling unit itself (a box, pallet, container, or nested HU) is described by its header in VEKP; VEPO is the child table that lists what is physically inside that unit. Packing is almost always driven from an outbound delivery, so the source document referenced by a VEPO row is normally a delivery item, though the packing framework is generic enough to reference other document categories. Because packing can split a single delivery item across several handling units, or combine several delivery items into one handling unit, the relationship between a delivery item and its VEPO rows is not one-to-one; it is whatever the warehouse actually did.
Key fields
- MANDT - client
- VENUM - handling unit number, together with POSNR forms the key and links up to the VEKP header for the same HU
- POSNR - item number of this packing line within the handling unit
- VBELN_VP - number of the source document whose content was packed here, in most cases the outbound delivery number
- POSNR_VP - item number within that source document, in most cases the delivery item
- MATNR - material number packed on this line
- WERKS - plant of the packed material
- LGORT - storage location of the packed material
- CHARG - batch, populated when the packed material is batch managed
- VEMNG - quantity packed on this line
- VEMEH - unit of measure for VEMNG
How it joins the data model
- VEPO-VENUM = VEKP-VENUM to get from a packing item back to its handling unit header, dimensions, weight and status
- VEPO-VBELN_VP = LIPS-VBELN and VEPO-POSNR_VP = LIPS-POSNR when the packed content originates from an outbound delivery item, which is the normal case
- VEPO-VBELN_VP = VBAP-VBELN and VEPO-POSNR_VP = VBAP-POSNR in the less common scenario where packing is recorded directly against a sales order item rather than a delivery
- VBFA can be used to trace forward from the delivery item to any follow-on shipment or billing document once the packing itself has been confirmed through VEPO/VEKP
How to read it safely
Always restrict by MANDT first, then by VENUM if a specific handling unit is already known, or by VBELN_VP and POSNR_VP if starting from a delivery item and working forward to find where it was packed. VENUM alone is highly selective; a full table scan on VEPO in a live system with heavy HU usage is expensive because nested handling units and split packing generate large numbers of item rows. When starting from the delivery side, pull the delivery item first from LIPS, then query VEPO on VBELN_VP/POSNR_VP rather than guessing at VENUM ranges.
How to prove it in the data
Symptom: warehouse claims a delivery item was packed but the shipment shows it as unpacked. Select VEPO where VBELN_VP equals the delivery number and POSNR_VP equals the item number. No rows returned means the item was never actually packed at the item level, regardless of what the delivery's overall packing status field on VBUK or the HU header suggests. Rows returned but with VEMNG summing to less than the delivery item quantity means a partial pack, not a full pack.
ECC vs S/4HANA
VEPO continues to exist as the packing item table in S/4HANA and the underlying handling unit management logic is largely unchanged from ECC. Access in newer implementations is increasingly done through CDS views built for warehouse and delivery monitoring rather than direct table reads, but the table itself has not been replaced or restructured in a way that changes its key fields or its relationship to VEKP.
Common pitfalls
- Assuming one VEPO row per delivery item. A single item is routinely split across multiple handling units, and a single handling unit can contain multiple delivery items, so counting VEPO rows to infer delivery lines is wrong.
- Treating VEMNG as automatically consistent with the delivery item quantity in LIPS. Nothing enforces that the sum of VEMNG across all VEPO rows for a given VBELN_VP/POSNR_VP equals the delivery quantity; partial packing, repacking, or a cancelled pack step can leave them out of step, and this has to be checked by summing, not assumed.
- Reading VEPO in isolation without joining to VEKP to check the handling unit's own status. A handling unit can exist with content rows in VEPO but be flagged as deleted, cancelled, or not yet confirmed at the header level, which changes what the packing data actually means operationally.
- Forgetting that VBELN_VP/POSNR_VP can point at a document category other than the delivery. Code or queries written assuming it is always LIPS will silently return wrong or missing joins when the source is a sales order or another handling unit nested inside this one.
- Using VEPO to determine current stock or bin location. It records what was packed at the time of packing; it is not a live inventory table and does not reflect stock movements or corrections made afterward outside the packing transaction.
Whose problem this is
Packing data discrepancies are a warehouse or logistics execution question first, since VEPO is populated by packing transactions run against the delivery, whether manual or through automated packing station integration. SD consultants get pulled in when a discrepancy affects delivery status, billing relevance, or downstream shipment documents; the actual packing logic and HU status handling usually sits with the EWM or WM-side team.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/vepoERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.