Catch weight items in Dynamics 365 SCM

A box of beef weighs about 18kg — but actually 17.642kg or 18.193kg depending on the box. The customer is invoiced for actual weight, but the warehouse counts and ships in boxes. This dual-unit reality — count one way, weigh another — is what catch weight handling in F&O addresses. Without catch weight, every box would have to be created as a unique item with its actual weight, which is operationally absurd.

The two units of measure.

• Inventory unit — what you count. Typically "EA" (each), "BOX", or "CTN".
• Catch weight unit — what you weigh and price. Typically "KG", "LB".

The item is set up with both. Each transaction line carries both quantities: a sales line might be 5 EA @ 87.5 KG at $4.20/KG.

Item setup. On the Released Product, enable catch weight:

• Catch Weight Item = Yes.
• Inventory Unit — counting unit.
• Catch Weight Unit — weighing unit.
• Nominal Quantity — expected weight per inventory unit (18 KG per BOX).
• Minimum Quantity / Maximum Quantity — allowable variance (16–20 KG per BOX).

The nominal lets the system pre-fill expected weight; the min/max constrains capture to flag obvious errors.

Operational capture. Every inbound and outbound transaction prompts for actual weight:

• Purchase receipt — operator captures actual weight of received boxes.
• Production output — actual weight per finished good unit.
• Inventory adjustment — actual weight when adjusting count.
• Sales picking — actual weight per picked unit.
• Production consumption — actual weight consumed.

Scale integration (electronic weigh scales connected to the warehouse mobile device or terminal) automates capture; without it, manual weight entry is the norm.

Pricing. Trade agreements (price lists) are typically per catch weight unit (per KG, per LB) — the inventory unit (BOX) is just the handling unit, but invoicing is by weight. A 5-BOX line at $4.20/KG with captured weight 87.5 KG bills at $367.50.

Inventory valuation. Both quantities are tracked at every step:

• On-hand in inventory unit (250 BOX) and catch weight unit (4,500 KG).
• Cost can be per inventory unit or per catch weight unit depending on costing setup.

The cost engine handles both — most food companies cost per KG for accuracy.

Lot-based variability. Each lot of a catch weight item can have its own weight characteristics. Combined with item tracking (lot/serial), full traceability of weight per lot is captured: lot ABC has 50 BOX totalling 905 KG; lot DEF has 50 BOX totalling 890 KG. Same SKU, different per-unit weights.

Catch weight tag. Some operations track individual unit weights through a catch weight tag — a barcode label printed at production or receipt, capturing the specific unit's weight. When the unit is sold, the tag is scanned and the system pulls the exact weight. This is the high-end pattern for traceability and accurate invoicing.

Reservation and picking. Catch weight complicates reservation:

• Reserving 100 KG when each box is 17.5–18.5 KG means reserving 5 or 6 BOX.
• Picking might short or over the reservation weight; the order is adjusted at confirmation.

The reservation engine has catch-weight aware logic, but warehouse picking flows need to handle the variability — the picked weight is rarely the planned weight to the gram.

Integration with WMS. Mobile warehouse devices integrated with scales capture weights in line with pick/put-away. Without integration, operators handwrite weights and key them in later — error-prone and slow.

Common pitfalls.

• Catch weight added to existing item. Switching an item from non-catch-weight to catch-weight is operationally painful; existing inventory must be re-weighed.
• Variance limits too tight. Real-world weights exceed the min/max; receipts blocked; warehouse frustration.
• Variance limits too loose. Bad data slips in; weight totals wrong.
• Pricing unit confusion. Trade agreement set per BOX instead of per KG; invoices wrong.
• Costing unit mismatch. Costed per BOX (nominal weight) but sold per KG (actual weight); margin calculation noisy.

Regulatory compliance. Food traceability (FSMA, EU Reg 178/2002) often requires per-lot weight tracking for recall scenarios — knowing exactly how much weight was distributed to which customers per lot. Catch weight + item tracking achieves this in F&O.

When you need it. Catch weight is essential for: meat, poultry, fish, cheese, fresh produce, bulk chemicals, anything weighed in handling units that vary. It's overkill for items that are dimensionally fixed.

Operational discipline. Catch weight depends on accurate weight capture at every step. Scale integration, operator training, and exception monitoring (weights outside expected variance) are essential. Without that discipline, the precision the module enables is illusory.