What catch weight actually is
Start with the definition: catch weight is the actual recorded weight of an individual unit of a product that naturally varies in weight, used as the basis for pricing and inventory valuation instead of a fixed or nominal weight.
An example makes it clearer. Think of a filet mignon. No two cuts are identical, and in the food business every ounce is money. Without catch weight, every "8 oz" filet sells for the same $20 whether the cut actually weighs 6.5 oz or 9.5 oz. With catch weight, the item carries a weight tolerance (commonly +/- 20%), and each steak is priced by what it actually weighs. The same item number might invoice anywhere from $16 to $24 depending on the specific cut that was picked for that specific customer.
The customer pays for the steak they got. You get paid for the steak you shipped. That's the whole idea, and it's why catch weight is table stakes for meat, seafood, cheese, and produce distributors.
Let's start where every catch weight decision starts: product setup.
Product setup: get it right the first time
Catch weight starts on the released product, with a checkbox on the product creation screen. Pay attention to that checkbox, because it's about as close to permanent as a setting gets in D365.
Next, units — the part of setup that trips up almost everyone. The inventory unit is the weight unit: pounds, kilograms, whatever you weigh in. The catch weight unit is the unit you actually buy and sell in, typically a case or a piece. We set the sales and purchasing units to the weight unit as well, because food pricing is almost always per pound. It feels backwards the first time you see it. It makes sense once you watch an order flow through, which we'll do in a minute.
Set your catch weight unit to your primary handling unit — for most distributors, the case. D365 doesn't handle multiple catch weight units well on a single item: weight capture happens per catch weight unit, so if the CW unit is set to piece but the warehouse moves whole cases, workers get prompted to scan a weight for every individual piece in the case — unrealistic unless you're actually breaking cases open to do it.
If you sell the same product in more than one handling unit — by the case and by the piece — model it as separate items per unit of measure rather than one item with an overly granular catch weight unit. It's a decision worth getting right the first time: this choice is sticky for the same reason the catch weight flag is — once the item has been transacted against, the catch weight unit on the product can't simply be changed, so going with the wrong unit means a new item, not a quick edit.
Last up: nominal weight. The nominal weight comes from your unit conversions, so defining a conversion for every catch weight item isn't optional — it's the foundation. The bare minimum is the conversion between your catch weight unit and your inventory unit: 1 CS = 40 LB. With the nominal weight in place, you can set the minimum and maximum weight allowed per unit. Those boundaries are what keep a fat-fingered entry from turning a 40-pound case into a 400-pound one.
Order entry: two quantities, one line
Enter an order for a catch weight item and you'll see extra fields on the line. Which ones you can edit follows a pattern nobody guesses on the first try:
| Field | What it holds | Editable? |
|---|---|---|
| CW quantity | How many cases or pieces | Yes |
| CW unit | The catch weight unit | No |
| Quantity | The weight | No |
| Unit | The weight unit | Yes |
Most users live in the CW quantity field: the customer wants 15 cases, you type 15, and the weight fields take care of themselves. Until the pattern clicks, expect some "why is this field greyed out?" tickets. After it clicks, order entry is smooth.
One more thing to set expectations on with your users: the weight that defaults onto a sales or purchase line is the nominal weight from the product setup. The real weight gets captured out in the warehouse during picking (or at the packing station), where workers scan a weight for each catch weight unit handled. Those individual scans aggregate back onto the order line — you'll see the result on the order once the packing slip posts. That actual weight is what gets invoiced.
That's the sales side. The buy side runs on the same mechanics — and has its own payoff worth understanding.
Purchasing: the same story on the buy side
Everything so far sounds sales-flavored, but catch weight is symmetric. Purchase order entry uses the same two-quantity pattern — you order 15 cases in the CW quantity field, the nominal weight defaults onto the line, and the field editability quirks are identical. The actual weight gets captured at receiving, and because inbound ASNs don't carry weight information, the mobile device prompts for real weights at registration. Plan your receiving labor with that in mind.
The payoff comes at vendor invoice time: you're reconciling the supplier's invoice against the weight you actually received, not the nominal weight on the PO. When the vendor bills for 1,020 pounds against a nominal 1,000-pound order, the match runs against what your scale said — which is exactly the argument you want to be able to win.
With both sides of the order now covered, that leaves one place left where catch weight still shows its seams: the warehouse floor.
Warehouse picking: where the gaps are
Two gaps in base D365 come up on nearly every food implementation we run.
Per-unit weight detail. First, what's not at risk: invoicing. Base D365 correctly apportions the total picked weight back to the sales order line, so customers get billed on actual weight with zero customization. The gap is granularity. The transaction stores one total, so if reporting or traceability needs to know what each individual case weighed, that per-unit detail doesn't exist out of the box. The native route is catch weight tags, which assign a tag and a weight to every catch weight unit received — tags do the job, but they bring their own list of restrictions and add labor at receiving, so plenty of distributors pass on them. Beyond tags, per-unit weight capture means a code modification that logs each unit's weight to a separate table. For food distributors staring down traceability requirements, that detail is often worth the investment.
Cluster picking. Standard picking for catch weight items through the Warehouse Management mobile app works fine out of the box. Cluster picking does not — it's on Microsoft's documented list of unsupported scenarios for catch weight products. That one stings, because cluster picking is exactly what a food warehouse wants: one picker running two skids at once, position 1 and position 2, picking for both orders in a single pass through the warehouse. Out of the box, catch weight items force separate passes.
The practical workaround: set up a standard picking menu item for your catch weight items and keep a cluster picking menu item for everything else. Not elegant, but it keeps the warehouse moving without custom code on day one. If clustering catch weight picks is a must-have, budget for the modification.
Wrapping up
Catch weight solves a real problem well. It prices and values the product you actually shipped instead of pretending every case weighs the same, and for meat, seafood, cheese, and produce, that accuracy shows up directly in margin.
The cost of getting it wrong shows up early and is hard to unwind: the flag is permanent, the unit setup runs against instinct, purchasing carries the same weight-capture demands at receiving, and the warehouse has holes around per-unit weights and cluster picking. So make the unit decisions deliberately — catch weight unit matched to your primary handling unit — and budget for a modification or two where the gaps touch your requirements.
Frequently asked questions
What is catch weight in Dynamics 365?
Catch weight is the actual recorded weight of an individual unit of a product that naturally varies in weight — a case of steaks, a wheel of cheese — used as the basis for pricing and inventory valuation instead of a fixed or nominal weight. In D365, a catch weight item carries two quantities on every transaction: a handling quantity in the catch weight unit (cases, pieces) and a weight quantity in the inventory unit (pounds, kilograms). The customer is invoiced for the actual weight shipped.
Can you turn catch weight on or off for an existing product?
Effectively no. The flag is set when the product is created, and an item with existing inventory transactions can't be changed in either direction. Once a catch weight item has been released, changing the designation requires deleting the item in every company where it exists — only possible if it has never been transacted on. Otherwise your option is to create a new product and transfer the inventory. Make the call during design.
How should units be set up for catch weight items?
The inventory unit is the weight unit (pounds, kilograms) — the unit the product is weighed and invoiced in — and the catch weight unit is the handling unit you buy and sell in, like a case or piece. A unit conversion between the two is required and defines the nominal weight (for example, 1 CS = 40 LB), and minimum and maximum quantities define the allowed weight range. Set the catch weight unit to your primary handling unit — usually the case — and only go more granular if you genuinely transact at that level today. Be aware this choice is sticky for the same reason the catch weight flag is: once the item has been transacted against, the catch weight unit on the product can't simply be changed — you're looking at a new item, not a quick edit.
Does catch weight work the same way on the purchasing side?
Yes. Purchase order entry follows the same two-quantity pattern as sales, and the actual weight is captured at receiving rather than at shipping. Because inbound ASNs typically don't carry weight data, expect the mobile device to prompt for real weights during receiving — plan labor accordingly. The payoff shows up at vendor invoice reconciliation: matching the supplier's invoice against what you actually received, not the nominal PO weight, gives you the leverage to dispute overbilling.
Does D365 capture the individual weight of each case picked?
Not per unit, out of the box — a sales line stores the total weight, and standard functionality correctly apportions the picked weight back to the line, so invoicing accuracy is not at risk. The gap is reporting and traceability granularity. The native route to per-unit weights is catch weight tags, which assign a tag and a weight to every catch weight unit received — but tags carry their own restrictions and add work at receiving. Many food distributors instead invest in a small code modification that records each unit's weight to a separate table, especially with traceability requirements in play.
Does D365 support cluster picking for catch weight items?
No — cluster picking is a documented unsupported scenario for catch weight products in D365 warehouse management. Standard sales order picking on the mobile device works fine. A common workaround is to route catch weight items through a standard picking menu item and keep cluster picking for everything else, or budget for a code modification if clustering catch weight picks is a must.
Caf2Code implements Dynamics 365 Supply Chain Management for food and beverage distributors — catch weight, advanced warehousing, and the modifications that bridge the gaps between them. If your products don't weigh what the item card says they do, we should talk.