How to price and invoice catch-weight products by actual weight, not the case label

A specialty cheese and cured meats distributor running six vans out of a single depot sold wheels of aged cheddar and legs of prosciutto to restaurants and delis on standing weekly orders. Every SKU had a case weight printed on the label — 8 lb wheel, 15 lb leg — and for years the invoicing app just multiplied that label weight by the per-pound price. It was fast. It let a driver close an order in the doorway and move to the next stop. It was also wrong on almost every line, because a "15 lb" leg of prosciutto is never exactly 15 lb — it's whatever the animal and the cure happened to produce, usually somewhere between 13.5 and 16.5.

The label weight is a rounding number, not a real one

Nobody set out to overcharge or undercharge anyone. The label weight is a nominal figure — a planning number used for ordering, case-packing, and shelf labeling — not a measurement of the specific unit in the driver's hand. Selling and invoicing off that number instead of the actual weight of the actual piece means every single transaction has a built-in error, and the error runs in both directions depending on which side of average that day's product happened to land.

For a while this looked like it was washing out. Some legs ran heavy, some ran light, and the owner assumed it evened out over a month. It didn't, for two reasons. First, restaurants that got a habitually heavy case for the same price as a light one noticed, and started asking the driver to hand-pick their pieces — which slowed down every stop and turned "restocking" into "shopping." Second, and more expensive: high-value proteins don't distribute evenly around the label weight the way flour does. A run of larger animals from one supplier could push actual weights consistently above label for weeks, which meant the distributor was giving away pounds of a $14/lb product on every case, silently, with no line on any report that said so.

The cost only showed up as a shrinking number nobody could name

The signal wasn't a single bad month. It was gross margin on the cheese-and-charcuterie line drifting down a fraction of a point at a time, in a business where that category was supposed to be the highest-margin thing on the truck. The owner checked the obvious things — supplier cost increases, theft, spoilage — and none of them accounted for the gap. The invoices all matched the price list. The price list hadn't changed. Nothing in the reporting distinguished between "sold at label weight" and "sold at actual weight," because the system had never captured actual weight in the first place — it wasn't a field that existed on the invoice.

That's the part that made it hard to catch: a pricing error that happens on every transaction, in a direction that's individually invisible, doesn't look like an error. It looks like margin compression, which gets blamed on everything except its actual cause.

The turning point: weighing at the point of sale, not the point of packing

The fix wasn't a new price list. It was capturing a second number — the real weight of the specific piece being sold — at the moment of the sale, and pricing off that number instead of the label. Practically, that meant putting a weight field on the catch-weight SKU in the field app itself: the driver (or a scale synced to the app) enters the actual weight of the unit going out the door, the app calculates price as actual weight times the agreed per-pound rate, and the invoice shows both the unit count and the weight it was billed against. The case label still matters for ordering and shelf space. It just stopped being the number that determined what anyone got charged.

The immediate effect was that invoices matched what customers could verify with their own scale, which ended the informal renegotiation that had been happening in doorways. The slower, bigger effect was on the owner's side: once actual weight was a field on every transaction instead of an assumption, the reports could finally show the pattern that had been invisible — average actual weight running consistently above label weight for a specific supplier's product, on a specific SKU, for a specific stretch of weeks. That's a conversation you can have with a supplier. "Margin feels a little soft this quarter" is not.

How to price and invoice catch-weight items correctly

• Capture actual weight per unit at the point of sale, not just at receiving — a case's weight can be recorded twice, once in and once out, and they won't match.
• Price off actual weight times the agreed per-unit rate, always — never fall back to the label or nominal weight to save a step, even when the driver is confident it's close.
• Put the weight field where the sale happens, in the same app or device used to write the invoice, so entering it doesn't add a separate step the driver will eventually skip.
• Show both weight and price on the printed or digital invoice the customer keeps — it's the fastest way to end weight disputes, because the number is verifiable on their own scale.
• Report average actual weight against label weight by SKU and by supplier, on a recurring basis — a sustained gap here is a supplier-side issue, not a rounding error, and it's invisible until this comparison exists.

iotoms handles this by making weight a native field on catch-weight items in the offline field app: the driver enters or scans the actual weight at the point of sale, pricing calculates off that number automatically, and the invoice, the ledger, and the margin reports all carry the real weight forward — so a distributor selling by the pound can see exactly where a case ran heavy or light, instead of finding out three months later as an unexplained dip in gross margin.