How to sell catch-weight products at the counter without breaking your inventory

A specialty foods distributor runs nine vans out to restaurants and delis, and also keeps a walk-in counter at the depot for smaller accounts and cash customers who stop by for cheese, cured meat and fresh fish sold straight off the case. The vans already track catch weight cleanly — cases come in by the crate, get weighed on the dock, and every case's actual weight is logged against the vendor invoice before it ever leaves the warehouse. The counter is a different story.

At the counter, a customer asks for "about two pounds" of prosciutto. The clerk slices it, puts it on the scale, sees 1.87 lbs, and keys the sale into the register as one line item: "Prosciutto — $14.98." The register has no idea that 1.87 lbs came off a case that was logged into inventory as 6.4 lbs. It just knows one prosciutto sale happened. Multiply that across forty counter transactions a day, six days a week, and the warehouse's catch-weight ledger — precise down to the hundredth of a pound on receiving — is being drawn down by a POS system that only understands whole units.

Where the gap actually shows up

The first place it surfaces is the month-end stock count. The perpetual inventory says there should be 4.2 lbs of prosciutto left in that case. The physical count says 3.6 lbs. Nobody stole anything — the register simply logged "1 unit sold" for every counter transaction instead of the actual weight the scale read, so each sale silently understated how much product left the building.

The second place is margin. The case was bought by weight at a catch-weight price per pound, so the true cost of that 1.87 lbs is knowable to the cent. But if the POS prices the sale off a flat per-unit list price instead of tying back to the weight and the case's landed cost, the reported margin on every counter sale is a guess dressed up as a number. On thin-margin perishables, that guess is often wrong by more than the actual margin.

The third is the one that costs the most time: reconciling the counter against the van-side catch-weight system at day close. Two different systems, two different units, and a manager trying to make a scale reading match a unit count by hand, every single day.

The turning point

The fix isn't a better scale — most counters already have one. It's making the scale's reading the transaction, instead of a number the clerk reads off a screen and re-keys as a flat-price unit sale.

That means the POS looks up the item as a catch-weight SKU, not a fixed-price product. The scale sends the actual weight straight into the sale line. The register prices that line off the per-weight cost carried from receiving — the same cost the vendor invoice was reconciled against — not a static list price nobody's updated since the last delivery. And the sale posts back to inventory as a weight deduction from the exact case it came from, the same case with a logged tare and an expected-vs-actual variance from the dock.

Once that's wired up, the counter and the van side are finally speaking the same language: both draw down inventory by measured weight, both price off the same catch-weight cost basis, and day close becomes one number instead of two systems argued into rough agreement.

What this takes in practice

• A scale that talks to the register, not a clerk who re-types a number. Manual entry is where catch weight quietly turns into a flat unit sale — the moment a human retypes "1.87" as "prosciutto x1," the weight is gone for good.
• Catch-weight SKUs at the counter, not just at receiving. If the warehouse tracks a product by measured weight but the counter sells it as a fixed-price item, the two halves of the business are using different units for the same product.
• Pricing pulled from landed cost per weight, not a static price list. A per-pound price that doesn't move with the actual cost of the case it's cut from is a margin number nobody can trust.
• Inventory deduction by weight sold, against the specific case. The stock count should reflect grams and ounces actually leaving the building, not a count of transactions.
• One day-close reconciliation across counter and route sales. If the counter and the vans post to inventory in the same unit, closing the day is a single tie-out instead of two ledgers reconciled by hand.

iotoms ties the counter's POS to the same catch-weight inventory the field app and procurement already use, so a scale reading at the register and a scale reading at the dock update the same case, in the same unit, without a clerk or a manager bridging the gap by hand.