MBEW table — MBEW Material Valuation Table
MBEW stores the current accounting valuation of a material at valuation area level: price control, standard price, moving average price, valuation class, and the total valuated stock quantity and value. It is the table behind stock value on the balance sheet and behind the price used for goods movement postings. It holds current state, not history.
MBEW is the material valuation table that carries price, valuation class and stock value per material and valuation area. This page covers the key fields, the joins consultants actually write against MARA, MARC, MSEG and T001W, and the recurring mistakes made when using MBEW to explain a stock value discrepancy.
Published 15 Sept 2026· 1,048 words
What it stores
One row represents the current accounting valuation of a material within a valuation area, and within a valuation type if the material is split valued. It carries the price used for that material's goods movement postings, the accumulated valuated stock quantity, and the resulting total inventory value. It is a current-state table, not a document table: it does not record when a price changed or what the value was last period, only what it is now. Every standard cost run, moving average update, goods receipt, invoice receipt with price variance, and manual price change (MR21) writes to this table. For split valuation materials there can be multiple rows per plant, one per valuation type, plus a header row that aggregates them.
Key fields
- MATNR - material number
- BWKEY - valuation area, normally the plant
- BWTAR - valuation type, populated only for split-valuated materials
- VPRSV - price control indicator, S for standard price or V for moving average / periodic price
- STPRS - standard price
- VERPR - moving average price under price control V, or periodic unit price under price control S
- PEINH - price unit, the quantity the price refers to
- LBKUM - total valuated stock quantity
- SALK3 - total value of the valuated stock
- BKLAS - valuation class, drives GL account determination
- LFGJA - fiscal year of the last posting to this record
- LFMON - period of the last posting to this record
How it joins the data model
- MBEW-MATNR = MARA-MATNR to reach material type and base unit
- MBEW-MATNR = MARC-MATNR and MBEW-BWKEY = MARC-WERKS when the valuation area equals the plant, to reach plant-level MRP and procurement data
- MBEW-BWKEY = T001W-BWKEY to resolve the valuation area to a plant and company code
- MBEW-MATNR joins MSEG or MATDOC on MATNR with WERKS resolved to BWKEY, to trace which movements built up LBKUM and SALK3
- MBEW-BKLAS is not a direct foreign key but feeds account determination for the movement type postings that hit finance, so tracing it forward means reading the FI document line, not another MM table
How to read it safely
Always restrict on client (MANDT), then on BWKEY and MATNR before touching anything else; the natural key is MATNR, BWKEY, BWTAR and selecting without at least the material is a full table scan in any production system. Do not select on VERPR or STPRS in isolation, they are meaningless without the material and price control context. If the material is split valued, BWTAR must be included explicitly or the aggregate header row and the individual valuation-type rows get summed together, doubling the quantity.
How to prove it in the data
Symptom: reported stock value for a material looks wrong at period end. Select MBEW for MATNR = the material and BWKEY = the plant's valuation area. Check VPRSV to know whether STPRS or VERPR is the live price, then compare LBKUM against the physical stock in MARD or the current quantity total in MATDOC for the same material and plant. If LBKUM times the unit price does not reconcile with SALK3 divided by PEINH, the gap points to an unposted goods movement or an open costing run, not a table defect.
ECC vs S/4HANA
MBEW remains a live transparent table in S/4HANA and continues to be updated by the same events as in ECC; it has not been retired or replaced by a compatibility view for its core valuation fields. What changes is the surrounding landscape: the material ledger, which is mandatory in S/4HANA, becomes the authoritative source for multi-currency and actual costing detail, so a valuation question that used to stop at MBEW may now need the material ledger's period and valuation tables as well.
Common pitfalls
- Treating MBEW as history: it holds the current value only, so using it to explain a value change from three periods ago produces a plausible but wrong story; the historical table or the material ledger has to be checked instead.
- Misreading VERPR: under standard price control (VPRSV = S) the VERPR field carries a periodic unit price used for reporting, not a moving average, and reading it as moving average leads to a wrong variance narrative.
- Assuming BWKEY always equals plant: it usually does, but valuation grouping can be configured differently, and a hardcoded join to MARC-WERKS silently returns zero or wrong rows if that assumption does not hold in that client.
- Forgetting BWTAR on split-valued materials: summing MBEW rows without filtering valuation type double counts quantity and value because the header row aggregates the type-specific rows.
- Reconciling old FI documents against the current BKLAS: valuation class can be changed as part of a revaluation, so a posting made under the old class will never match today's BKLAS, and that mismatch is not an error.
- Reading a negative LBKUM as data corruption: negative stock scenarios are configurable and legitimate in some plants, and a negative value alone does not indicate a broken record.
- Chasing an MBEW discrepancy as an MM problem when the root cause is an open costing run or an unclosed material ledger period, which belongs to the CO/costing team, not inventory management.
Whose problem this is
Inventory accounting sits jointly with the MM consultant responsible for goods movement and valuation configuration and the FI or CO consultant responsible for costing and account determination. A price or valuation class question is theirs to resolve together; basis only owns performance issues on the table.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-tables/mbewERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.