PC, PAK, CS, KG: de eenhedenchaos bij leveranciers die uw voedselkosten stilletjes ondermijnt

Op een prijslijst van een leverancier staat een regel: Crème entière 35% — CHF 4.80 — PC. Wat betekent ‘PC’ hier? Een fles van 1 liter? Een portiebekertje van 200 ml? Een bag-in-box van 5 liter? De afkorting zegt het niet. En meestal weet degene die de gegevens onder tijdsdruk in het systeem invoert het ook niet — die kiest de meest voor de hand liggende lezing en gaat verder, waarna het recept dat die room gebruikt een kostprijs krijgt die óf ruwweg klopt óf met een factor vijf de mist ingaat, zonder dat u dat aan het getal alleen kunt zien.

Dit is geen zeldzame uitzondering. In onze ervaring met het onboarden van nieuwe grootkeukens op gestructureerde receptsystemen is dit een van de allergrootste bronnen van stilletjes foute voedselkosten — groter dan afwijkende portiegroottes, groter dan een verouderde prijs, want het levert geen getal op dat een beetje afwijkt. Het levert een getal op dat met een heel veelvoud fout is, vermomd als een precieze berekening.

Elke leverancier verzint zijn eigen alfabet

Op het punt waarop de meeste keukens daadwerkelijk bestellen, bestaat er geen gedeelde standaard. De export van de ene leverancier gebruikt ‘PC’ voor stuk. Een andere gebruikt ‘PC’ voor verpakking. Een derde gebruikt ‘STK’ (Duits Stück), een vierde ‘CT’ voor karton, een vijfde ‘GEB’ voor Gebinde — een Duitse verzamelterm voor ‘wat voor verpakking het toevallig ook is waarin dit wordt verzonden’. Tel daar ‘CS’ voor krat, ‘BTL’ voor fles en ‘BUC’ voor bos bij op, en vermenigvuldig dat met het aantal leveranciers waar een middelgrote keukengroep daadwerkelijk bij bestelt — doorgaans acht tot vijftien, elk met een eigen catalogusexport, vaak in verschillende talen afhankelijk van de regio.

Dit is geen opgelost probleem dat alleen nog maar toegepast hoeft te worden — het is een lastig probleem. GS1, de mondiale standaardenorganisatie achter barcodes, onderhoudt een formele verpakkingshiërarchie die specifiek dit probleem moet oplossen: elk fysiek niveau — los stuk, binnenverpakking, krat, pallet — krijgt een eigen unieke identificatie, zodat ‘een krat’ altijd naar een exacte, ondubbelzinnige hoeveelheid verwijst in plaats van naar een gok. Die standaard bestaat juist omdat de sector verpakkingsdubbelzinnigheid groot genoeg vond om een wereldwijde oplossing te rechtvaardigen. In de praktijk volgen de prijslijstexports van de meeste kleine en middelgrote foodservice-leveranciers die standaard nog steeds niet — waardoor de dubbelzinnigheid onopgelost terechtkomt bij wie het product ook maar in uw systeem invoert.

Wat er in de praktijk misgaat — drie terugkerende patronen

De gok naar de kratgrootte. Er staat een regel: ‘1 krat — CHF 48.00.’ Is dat een krat van 6 stuks of een krat van 12? Raadt u het mis, dan wordt elk recept dat dat product gebruikt gecalculeerd op precies het dubbele of de helft van de werkelijke ingrediëntkost — geen afrondingsfout, maar een schoon veelvoud, en één die elke volgende berekening in de keten perfect aannemelijk overleeft.

Hetzelfde ingrediënt, drie verschillende verpakkingen. Slagroom van leverancier A komt in flessen van 1 liter. Dezelfde room van leverancier B wordt verzonden in een bag-in-box van 5 liter. Een derde leverancier, gericht op catering, verkoopt portiebekertjes van 200 ml. Als uw systeem ‘room’ als één uitwisselbaar product behandelt in plaats van als drie afzonderlijke verpakkingsrecords, hangt de kostprijs van het recept volledig af van welke variant het laatst is ingevoerd — of opnieuw besteld — zonder enige waarschuwing dat het getal is veranderd.

De eenheid die verstopt zit in een omschrijving. Bij onboarding komt het vaak voor dat een aanzienlijk deel van een bestaande productcatalogus binnenkomt zonder enig gestructureerd eenheidsveld — de verpakkingsgrootte staat dan als vrije tekst in de productnaam: “Box 6x1kg”, “Carton de 24”. Een omschrijvingsveld is geen data waarmee een calculatie-engine iets kan doen. Elk van die regels moet handmatig worden heropend en het echte getal eruit worden gehaald voordat het product überhaupt vertrouwd kan worden in een recept — en tot dat gebeurt, is de kostprijs van het product óf leeg, óf nul, óf stilletjes fout.

Geen van deze gevallen is een trainingsprobleem. Het is wat er, voorspelbaar, gebeurt bij het volume waarop een echte leverancierscatalogus draait — honderden of duizenden regelitems, meerdere verpakkingsvormen per leverancier, ingevoerd onder tijdsdruk, zonder structurele barrière die voorkomt dat een dubbelzinnige eenheid in een recept terechtkomt.

Waarom dit de calculatie erger verstoort dan bijna al het andere

Leveranciers van receptcalculatiesoftware komen vanuit een heel andere invalshoek tot dezelfde conclusie: verpakkingsgrootte en meeteenheid zijn ‘de velden die het meest verantwoordelijk zijn voor variantie in voedselkosten’ — nog vóór prijsschommelingen, nog vóór portiegrootte. De reden is proportioneel. Een verouderde prijs kan 5–10% afwijken. Een verkeerde eenhedenconversie wijkt af met precies het veelvoud dat de verpakking toevallig is — 2x, 6x, 12x — en corrumpeert stilletjes ieder gerecht dat dat product gebruikt, totdat iemand toevallig die specifieke regel controleert.

En het stapelt op. Bijdragemarge, menu-engineering, het verschil tussen theoretisch en werkelijk verbruik — alles in de reeks over winstgevendheid veronderstelt dat de ingrediëntkost die eraan ten grondslag ligt reëel is. Een verkeerde conversiefactor vertekent niet alleen één getal; hij vergiftigt elke berekening die erop is gebouwd, net zoals een ongedefinieerde portie dat doet — zie waarom ‘één portie’ niets betekent zonder een getal voor de variant van precies hetzelfde probleem aan de opschepkant.

Hoe u dit daadwerkelijk beheerst

De oplossing is niet zorgvuldigere data-invoer — mensen die onder tijdsdruk duizenden dubbelzinnige afkortingen intypen, zullen altijd een bepaald percentage fouten produceren. De oplossing is structureel:

1. Inkoopeenheid en recepteenheid zijn twee gescheiden velden, verbonden door één expliciet getal. Laat ‘hoe het wordt ingekocht’ en ‘hoe het wordt gebruikt’ nooit één veld delen, en laat de conversie tussen beide nooit verstopt zitten in een tekstomschrijving. ‘1 krat = 12 × 1 kg’ is een getal, geen zin.
2. Eén productrecord per daadwerkelijke verpakkingsvorm. Als een leverancier — of drie verschillende leveranciers — hetzelfde ingrediënt in verschillende verpakkingsgroottes verkopen, zijn dat meerdere productrecords met hun eigen conversiefactoren, niet één record met een aangenomen standaardwaarde die meestal toevallig klopt.
3. Geen conversiefactor, geen receptgebruik. Een product zonder bevestigde conversie van inkoop- naar recepteenheid zou helemaal niet bruikbaar moeten zijn in de calculatie — een opvallende leemte die iemand moet invullen is beter dan een aannemelijk ogend fout getal waar niemand vraagtekens bij zet.
4. Controleer eenheden voordat u prijzen aanpakt. Bij het live zetten van een nieuwe vestiging of een nieuwe leverancierscatalogus is het eenheidsveld het eerste dat u moet verifiëren — een correcte prijs tegenover een verkeerde conversiefactor levert nog steeds een foute kostprijs op. Prijzen herstellen vóór eenheden is het kleinere probleem eerst oplossen.
5. Herzie de conversie telkens wanneer de verpakkingsvorm verandert. Leveranciers wisselen wel degelijk van verpakkingsgrootte — een blik van 5 liter wordt er een van 3 liter, een krat van 6 wordt een krat van 4 — meestal zonder aankondiging. Als niets een herziening van de conversiefactor afdwingt op het moment dat dit gebeurt, blijft het oude veelvoud onbeperkt op de nieuwe werkelijkheid worden toegepast.

Niets van dit alles maakt een weegschaal en een geoefend oog overbodig, net zomin als portiediscipline dat doet. Wat het wel wegneemt, is de stille variant van de fout — degene die eruitziet als een echt getal, elk rapport overleeft, en pas maanden later aan het licht komt als marge die stilletjes is weggeslonken en die niemand kan verklaren.

Verwante artikelen

• De openingspost van de reeks Winstgevendheid — de basisprincipes van het berekenen van de werkelijke voedselkosten van een gerecht.
• Waarom ‘één portie’ als mondelinge instructie bij drie verschillende koks drie verschillende borden oplevert — en wat je in plaats daarvan moet opschrijven.

---

Bent u bezig met de migratie van een leverancierscatalogus en weet u niet zeker welke conversies daadwerkelijk betrouwbaar zijn? Boek een gratis gesprek van 15 minuten met ons team — vrijblijvend: Plan een gesprek.

Bronnen en verder lezen

• 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