PC, PAK, CS, KG: The Supplier Unit Chaos Quietly Wrecking Your Food Cost

A supplier price list has a row: Crème entière 35% — CHF 4.80 — PC. What is “PC” here? A 1-litre bottle? A 200 ml single-serve cup? A 5-litre bag-in-box? The abbreviation doesn’t say. Neither, usually, does the person re-keying it into your system under deadline pressure — they pick the most common-sense reading, move on, and the recipe that uses that cream now has a cost figure that’s either roughly right or off by a factor of five, and there is no way to tell which from looking at the number alone.

This is not a rare edge case. It is, in our experience onboarding new enterprise kitchens onto structured recipe systems, one of the single biggest sources of silently wrong food cost — bigger than portion drift, bigger than a stale price, because it doesn’t produce a number that’s a little off. It produces a number that’s wrong by a whole multiple, wearing the disguise of a precise calculation.

Every supplier invents its own alphabet

There is no shared standard at the point most kitchens actually order. One supplier’s export uses “PC” for piece. Another uses “PC” for pack. A third uses “STK” (German Stück), a fourth “CT” for carton, a fifth “GEB” for Gebinde — a catchall German term for “whatever container this happens to ship in.” Add “CS” for case, “BTL” for bottle, “BUC” for bunch, and multiply that by however many suppliers a mid-sized kitchen group actually orders from — typically eight to fifteen, each running their own catalog export, often in different languages depending on region.

This isn’t a solved problem waiting to be adopted — it’s a hard one. GS1, the global standards body behind barcodes, maintains a formal packaging hierarchy specifically to fix this: each physical unit — each, inner pack, case, pallet — gets its own unique identifier, so “a case” always resolves to an exact, unambiguous quantity rather than a guess. That standard exists precisely because the industry recognized pack-size ambiguity as big enough to need a global fix. In practice, most small and mid-sized foodservice suppliers’ price-list exports still don’t follow it — which means the ambiguity lands, unresolved, on whoever is typing the product into your system.

What actually goes wrong — three real patterns

The case-size guess. A line reads “1 case — CHF 48.00.” Is that a case of 6 units or a case of 12? Get it wrong and every recipe using that product is costed at exactly double or half its real ingredient cost — not a rounding error, a clean multiple, and one that survives every downstream calculation looking perfectly plausible.

The same ingredient, three different containers. Heavy cream from Supplier A comes in 1-litre bottles. The same cream from Supplier B ships in a 5-litre bag-in-box. A third catering-format supplier sells 200 ml single-serve cups. If your system treats “cream” as one interchangeable product rather than three distinct pack records, the recipe’s cost depends entirely on which one happened to be entered — or re-ordered — most recently, with no warning that the number moved.

The unit hiding inside a description. During onboarding, it’s common for a meaningful share of an existing product catalog to arrive with no structured unit field at all — the pack size sitting as free text inside the product name instead: “Box 6x1kg”, “Carton de 24”. A description field isn’t data a costing engine can act on. Every one of those has to be manually reopened and the real number extracted before the product can be trusted in a recipe at all — and until that happens, the product’s cost is either blank, zero, or silently wrong.

None of these are training failures. They’re what happens, predictably, at the volume a real supplier catalog runs at — hundreds or thousands of line items, several formats per supplier, re-keyed under time pressure, with no structural barrier stopping an ambiguous unit from reaching a recipe.

Why this breaks costing worse than almost anything else

Recipe costing software vendors converge on the same finding from the other direction: pack size and unit of measure are “the fields most responsible for food-cost variance” — ahead of price drift, ahead of portion size. The reason is proportional. A stale price might be off by 5–10%. A wrong unit conversion is off by whatever the pack multiple actually is — 2x, 6x, 12x — and it corrupts every single dish that uses that product, silently, until someone happens to audit that specific line.

And it compounds. Contribution margin, menu engineering, theoretical-versus-actual variance — everything in the Profitability series assumes the ingredient cost feeding into it is real. A wrong conversion factor doesn’t just bias one number; it poisons every calculation built on top of it, the same way an undefined portion does — see why “one portion” is meaningless without a number for the plating-side version of exactly this problem.

How to actually manage this

The fix isn’t more careful data entry — humans re-keying thousands of ambiguous abbreviations under deadline will always produce some percentage of errors. The fix is structural:

1. Purchase unit and recipe unit are two separate fields, joined by one explicit number. Never let “how it’s bought” and “how it’s used” share a single field, and never let the conversion between them live inside a text description. “1 case = 12 × 1 kg” is a number, not a sentence.
2. One product record per actual pack format. If a supplier — or three different suppliers — sell the same ingredient in different container sizes, that’s multiple product records with their own conversion factors, not one record with an assumed default that happens to be right most of the time.
3. No conversion factor, no recipe use. A product without a confirmed purchase-to-recipe conversion shouldn’t be usable in costing at all — better an obvious gap flagged for someone to fill than a plausible-looking wrong number nobody questions.
4. Audit units before touching prices. When bringing a new site or a new supplier catalog online, the unit field is the thing to verify first — a correct price against a wrong conversion factor is still a wrong cost. Fixing prices before units is solving the smaller problem first.
5. Re-check the conversion whenever the pack format changes. Suppliers do switch pack sizes — a 5-litre tin becomes a 3-litre one, a case of 6 becomes a case of 4 — usually without an announcement. If nothing forces a review of the conversion factor when that happens, the old multiple keeps being applied to the new reality indefinitely.

None of this removes the need for a scale and a trained eye any more than portion discipline does. What it removes is the silent version of the error — the one that looks like a real number, survives every report, and only surfaces months later as margin that quietly eroded and nobody can explain.

Related reading

• The opening post in the Profitability series — the fundamentals of calculating a dish’s real food cost.
• Why ‘one portion’ as a spoken instruction produces three different plates from three different cooks — and what to write down instead.

---

Migrating a supplier catalog and not sure which conversions are actually trustworthy? Book a free 15-minute call with our team — no commitment: Schedule a call.

Sources

• GS1 Package and Product Measurement Standard
• GS1 GTIN Allocation Rules for Foodservice
• Bad unit conversions poison your costs silently — Recipe Cost Calculator
• Recipe Costing Best Practices for Restaurants — meez
• Restaurant plate and menu costing 101 — MarginEdge