How to run a product that's bought in one unit, made in another, and sold in a third — holding the truth in one base unit so a returned jar never posts as a quarter of a case and your numbers always tie out.
Do these first
Real help from real food people
Chef Diego runs a real food plant. If this page didn't get you there, tell us — a person reads every message.
After this lesson you can take one product that gets bought, made, and sold in three different units and keep the counts honest across all three — pick the one unit you store the truth in, write the conversions that ride on top of it, and prove the ugly cases (a case sold, a few eaches returned) post cleanly instead of leaving a fraction of a case that never existed. It helps to have a bill of materials in hand first, because the units written on it are where the trouble starts.
Walk one product through a day and count how many times its unit changes.
You buy peppers by the 25 lb bag. Your bill of materials calls for them in pounds. The finished sauce comes off the line as jars — you count it by the jar. Your customer orders it by the case of 12, a distributor takes it by the pallet, and when three jars arrive broken, the credit comes back to you by the each. That is at least four units for one pepper and one jar, and every hop between them is a place a number can go wrong.
A is just the unit a quantity is counted in. The problem is never one unit on its own. It is that the same physical stock gets counted in different units by different people — the floor in jars, sales in cases, purchasing in pounds — and unless those units are tied together exactly, the counts drift apart until nobody trusts any of them.
Two of these units are worth pinning down, because the trade uses them as nouns. An is one individual unit: one jar. A case is the shipping pack that holds a fixed number of eaches — here, 12 jars. A pallet holds a fixed number of cases. Stacked up they make a hierarchy: eaches into cases, cases onto pallets. The counts only stay honest if the number of eaches in a case, and cases on a pallet, is fixed and known.
Here is where it breaks, and it is small enough that most operations ship it into their books without noticing.
The numbers here are made up to show the shape. You sell a customer one case of hot sauce — 12 jars. Three arrive broken, and you issue a credit for those three jars. If your system stores stock and sales in cases, that return has to go back in as 3 ÷ 12 = 0.25 case. Now a quarter of a case exists in three places at once: on the credit memo, in your on-hand inventory, and in the cost behind that sale. None of them is real. You cannot put a quarter of a case on a shelf, you never made a quarter of a case, and no picker will ever pull one.
Left alone, that fraction compounds. A few returns and partial shipments later, your on-hand reads 41.75 cases while the shelf holds a whole number of jars, and the two will never agree again. The costing is worse: a quarter-case of returned product carries a quarter-case of cost, and once fractions like that are loose in the numbers, the true cost of what you sold — the figure the lesson on COGS from your recipes builds — stops tying out to anything you can count.
The fraction is not the disease. It is the symptom of storing the truth in the wrong unit. You sold in cases, but the thing that actually moved was jars — and jars are what you should have been counting all along.
The fix is one decision, made once per product: choose the unit you store the truth in, and make every other unit a conversion on top of it.
That unit is the . For anything you count, the base unit is the each — the jar, the bar, the finished bag. For anything you weigh, it is a weight: grams, or pounds. The rule is the same either way: pick the smallest unit you actually handle, and never let a fraction of it exist. Three jars is 3 eaches, a whole number. It is only "0.25 case" when you insist on reading it in the wrong unit.
Everything else becomes a : 12 eaches to a case, 48 cases to a pallet, 25 pounds to a bag. Two habits keep those factors from leaking error:
The same logic runs up the buying side. You buy peppers by the 25 lb bag, but you do not stock peppers in bags — you stock them in pounds, because a bag gets opened. Buy 3 bags and a batch pulls 45 lb, and the honest reading is 75 − 45 = 30 lb left: one opened bag with 30 lb in it. Read in bags, that is "1.2 bags," a fiction — there is no such thing as two-tenths of a bag of peppers. The bag is how you bought them; the pound is how you hold them. Landing a real cost on each pound — the work the landed material cost lesson walks through — depends on the pound, not the bag.
One case does not fit the base-unit rule cleanly, and it is common enough in food to name.
Some products are counted by the each but sold by weight, because no two eaches weigh the same. A cured salami, a wheel of cheese, a whole fish, a tray of portioned meat — you ship one unit, but this one weighs 0.94 lb and the next weighs 1.07 lb. That is . Assume a nominal weight — call every salami 1.00 lb — and your inventory weight, your invoices, and your customer's receiving all drift from what actually crossed the dock.
The fix is to carry both units and keep both real: the count in eaches, and the actual weight captured at pack-out, per unit or per lot. You still hold a whole number of eaches; you also hold the true weight that goes on the invoice.
This is not only an internal tidiness problem — the label rule already assumes variable weight exists. Under 21 CFR 101.7, the net quantity of contents on a packaged food's principal display panel is declared in weight, fluid measure, or numerical count, and it is the net contents — the food itself, not the jar or wrapper. The regulation names the exact case at 101.7(j)(2): a "random package," one of a lot of the same product with varying weights and no fixed weight pattern. A variable-weight package still has to declare the weight truly in it — so the actual weight you capture on the floor is the same number the label has to tell the truth about.
Confirm the label rule at the source
The net-quantity rule is federal and it moves; the label is its own subject, and a later track covers it in full. Verify the current text of 21 CFR 101.7 at ecfr.gov before you rely on a specific clause — this was checked against the Code of Federal Regulations in July 2026. The point here is narrow: a variable-weight product needs its real weight captured, not a nominal one, and the labeling rule expects the same.
Once the base unit holds the truth, the payoff is that you can show the same stock in whatever unit each person needs, without ever storing more than one number.
Take a run of 288 finished jars. The floor counts it as 288 eaches. Sales and shipping read it as 288 ÷ 12 = 24 cases. For a freight quote it is the net weight: 288 jars at 12 oz each is 3,456 oz, or 3,456 ÷ 16 = 216 lb of product. One quantity — 288 eaches — read three ways, every reading exact because every one is derived from the same base by a known factor. Nobody re-keys anything, and no two views can disagree, because there is only one number underneath.
Software built for food does this by holding stock in a base unit and computing cases, pallets, and weights from it on the fly, so a fractional case is never stored in the first place — the returned jar is 1 each, and "a quarter of a case" is only ever something a screen chooses to show. Bettr Manager, the operations platform this site is part of, works this way; it is one way to keep the base unit honest, not the only one. A spreadsheet can do it too, as long as one column holds the base unit and every case-or-pallet figure is a formula off that column rather than a number someone types.
Get this right and the whole chain — from the bill of materials through production and out to the invoice — stays in units that tie. Get it wrong and every count downstream inherits the fraction.
A clean base unit, exact conversion factors, and honest catch-weights are the difference between counts that tie and counts nobody trusts. But none of it holds if the people on the floor won't record the unit they actually used — the base unit only stays honest if the each gets logged as it moves. That is the last thing this course takes on: getting the floor to use the system instead of working around it. First, map the units on one real product and make them tie.
Do this in your operation