MCHB table — Batch Stock at Storage Location Level

One row in MCHB represents the on-hand quantity of one batch of one material in one plant and storage location, split across stock categories. It exists because plain storage-location stock (MARD) has no batch field, and any material flagged as batch-managed needs its quantities tracked per batch as well as per storage location. The table carries no movement history and no valuation amount; it is a current-quantity snapshot maintained by goods movement postings. A material can have many MCHB rows for the same plant and storage location, one per batch currently held there, plus historical rows for batches whose quantity has since gone to zero but which have not been physically deleted. Batches themselves are described in the batch master, not in MCHB; this table only tells how much of a given batch sits where, in which status.

MANDT is implicit in most systems and should not be forgotten in native SQL access outside the ABAP layer. The table is keyed on material, plant, storage location and batch together, so any selection restricted only by MATNR on a material with many batches and locations returns far more rows than intended. Always restrict by WERKS and, where the investigation is location-specific, by LGORT, before pulling CHARG-level detail. A row with all quantity fields at zero is not necessarily a bug; it means the batch existed there at some point and the record has not been physically deleted, which is normal on a table that is never purged as part of routine operations. Do not filter on LVORM as a proxy for zero stock; check the quantity fields directly.

To confirm whether a specific batch shows unrestricted stock at a given storage location, select MCHB with MATNR, WERKS, LGORT and CHARG all specified and read CLABS. A non-zero CLABS with zero in CINSM, CSPEM, CEINS and CRETE confirms the batch is fully available for unrestricted use at that location. If the row does not exist at all for that combination, the batch has never carried stock there, which is different from having carried stock and been consumed to zero, a distinction that matters when reconciling against a goods movement that references that storage location.

In S/4HANA, MCHB is not a physically maintained transaction table in the same way it was in ECC. Stock quantities are derived from the universal journal of material movements, and MCHB is exposed as a compatibility view that computes the same field structure on the fly for programs and queries still coded against the classic table. Existing reports, custom ABAP and interfaces that select from MCHB continue to work, but the read now goes through an aggregation layer rather than a stored quantity, which changes performance characteristics on large selections and makes direct table-level locking arguments from ECC obsolete.

Stock discrepancies traced to MCHB are an inventory management functional question first, owned by whoever configures storage locations, batch management and movement types for the plant in question. Batch master data content and batch determination logic sit with the same team or with quality management if inspection-related statuses are involved. A technical performance problem reading the table at scale, especially post-migration, belongs with basis or the S/4 data model owner.

MARD carries the same stock categories without the batch split and is the reconciliation target for MCHB totals. MCHA holds batch stock at plant level without the storage location dimension. MARA and MARC supply the material and plant master attributes needed to interpret a row. Goods movements posted through migration and inventory movement transactions write MSEG and MKPF in ECC and MATDOC in S/4, which are the source of any change in MCHB quantities and the first place to look when a balance looks wrong.