How to deduct tare weight from catch-weight pricing so customers stop paying for the box

A poultry distributor running four vans delivered whole birds to restaurants packed in wax-lined cardboard boxes bedded with wet ice, the standard way to keep product cold between the plant and the walk-in cooler. Every box went on the scale at the depot before loading, and that scale reading — box, ice, and birds together — was the number the driver's handheld used to calculate the invoice. It had always been done that way. Nobody had ever separated out what the box and the ice actually weighed.

The scale doesn't know the difference between product and packaging

A scale reads total weight. It has no idea that two of those pounds are wet cardboard and shaved ice and the rest is chicken. Unless something in the process explicitly subtracts that packaging weight — the tare weight — before the price gets calculated, the customer is being billed for the box and the ice at the same per-pound rate as the meat inside it. On a single delivery that's a rounding error nobody notices. Across a route running four vans, six days a week, on product priced at several dollars a pound, it adds up to real money moving in the wrong direction — and it's the distributor's money, not the customer's, because the tare weight was never free. It cost packaging and ice, and now it was also being given away.

The reverse also happens, and it's worse. Some restaurants weighed spot-check deliveries themselves, net of packaging, using their own kitchen scale. When their number consistently ran under what the invoice charged, they didn't conclude "our scale is off." They concluded they were being overbilled, and in the food industry that suspicion has a name and a paper trail behind it — weights-and-measures rules exist specifically because billing gross weight instead of net weight, when the buyer is paying for a specific commodity, is treated as a compliance problem, not a rounding quirk.

The gap hid inside a number that looked precise

What made this hard to catch was that the invoice looked exact. It had a weight to two decimal places and a price calculated cleanly off that weight. Precision is not the same as accuracy — the scale reading was precise, but it was measuring the wrong thing, because it included packaging that should never have been priced at all. Nothing about a clean-looking invoice signals that it's wrong. The owner only found the pattern when a longtime customer, tired of asking about it politely, sent over three weeks of their own kitchen-scale readings next to the delivery invoices. The gap between "what we billed" and "what actually arrived, net of ice and box" was consistent enough to be systematic, not random — a few ounces per box, in the same direction, every time.

That consistency was the tell. Random variance washes out. A gap that shows up the same direction on every delivery means something in the process is structurally wrong, not that any one driver made a mistake.

The fix: tare weight has to be a number, not an assumption

The fix wasn't asking drivers to eyeball it or subtract "about half a pound" for the box. It was making tare weight an actual field in the system, tied to the packaging type, so it gets subtracted automatically before price is calculated:

• A dry cardboard box has a known, consistent tare weight — weigh a sample of empty boxes once, record the average, and it barely needs revisiting.
• Wet ice is the harder case, because the amount packed varies by driver, by route length, and by how warm the day is. A fixed tare doesn't work here; it needs to be weighed out or estimated at pack time and recorded per case, not assumed to be constant.
• Net weight, not gross weight, is what gets priced. Gross weight (product plus packaging) still matters for handling and vehicle load calculations, but the invoice and the ledger should only ever see net weight times rate.

Once tare weight became a real field instead of an invisible assumption baked into "the box weighs what it weighs," a few things changed at once. Invoices matched what customers measured on their own scales, which ended the polite-but-pointed emails. The margin line for that product recovered by roughly the amount that had been quietly walking out the door as unbilled packaging allowance — not dramatic on any single delivery, but consistent, every day, on every route. And because net weight was now a stored number instead of a mental subtraction, it showed up on reports: average tare by packaging type, by route, flagging when a driver's ice-pack habits started running heavier than the standard.

How to get tare weight right

• Weigh empty packaging by type — box, tray, ice, liner — and store that as a tare value tied to the SKU or packaging code, not left to memory.
• Treat wet ice as variable, not fixed — weigh it at pack time when the amount isn't consistent, rather than applying a flat estimate that drifts with the weather and the driver.
• Price off net weight only — gross weight can stay useful for load planning, but it should never be the number that multiplies against a per-pound rate.
• Show net weight, tare weight, and gross weight separately on the invoice — a customer who can see the subtraction has no reason to distrust the total.
• Report average tare by packaging type and route on a recurring basis — a tare that creeps upward over weeks is a packing-habit problem worth catching before it becomes a customer complaint.

iotoms handles this by treating tare as its own field on catch-weight items in the field app — a driver can record or select the packaging tare at the point of sale, the app subtracts it automatically before pricing, and the invoice, the ledger, and the margin reports all carry net weight forward, so a distributor selling by the pound is never pricing the box or the ice along with the product.