Build your own purchase price index: what your basket actually costs

Why national inflation does not describe your purchasing

Official price statistics for Poland exist, they are good, and the honest thing is to name them precisely rather than borrow them.

Poland's statistical office publishes the national consumer price index in the same family — the monthly series "Miesięczne wskaźniki cen towarów i usług konsumpcyjnych od 1982 r.", downloadable as a table (GUS, monthly consumer price indices since 1982, read 26 August 2026).

Read the label on both of them before you use either. CP111 measures what a guest pays for catering services across a whole country — menu prices, not invoice prices. The national consumer index measures a household basket. Neither one is the price your supplier charged you for pork loin last Tuesday, and the gap is not a rounding error: guest prices carry your labour, your rent and your margin decisions inside them, and a national basket carries other people's shopping.

There is no official purchase price index for restaurants to reach for instead. The Eurostat dataset catalogue, read on 26 August 2026, carries ten entries whose titles contain "purchase prices" and every single one of them is agricultural — fertilisers, feeding stuffs, energy products used in agriculture, and the means of agricultural production. The phrase "input prices" appears nowhere in it. The only hospitality entry in the whole catalogue is the harmonised consumer index for hotels and restaurants, which is the guest's price again. So this page does not name an industry norm for how fast your purchasing rises. It gives you the arithmetic to measure your own, and the official series above stay where they belong: as background against which your own number can be read.

Three things make your index differ from a national one even in a calm month. The basket is different — a national basket is built from household or guest spending, yours is the twenty lines your kitchen buys. The weights are different — national weights come from expenditure surveys, yours come from your invoices. And the supplier is different — your price depends on your volume, your delivery frequency and your payment terms, which no national average knows about.

The basket: which items go in and how many are enough

Basket — the list of purchased items tracked over time. Chosen by spend, not by count: the items covering most of the purchase money.

Take one closed month of invoices, sum the spend per item, sort descending, and go down the list until you have covered roughly four fifths of the money. For a single kitchen that is usually twelve to twenty lines. Everything below that point can be watched, but it will not move the index, and pretending otherwise makes the work heavier without making the number better.

The table below is a template, not data. It is filled from your own invoices, which is the point of the whole exercise.

The last two columns are not decoration. An item whose price is fixed by a twelve-month contract belongs in the basket for completeness but will never explain a move; an item with no substitute is the one where a supplier's price rise turns straight into your cost, because you cannot walk away from it. Getting invoices into a ledger where this sorting is even possible is a systems job before it is an arithmetic one — see integrations and what a system has to do with invoicing and KSeF.

What does not belong in the basket

One-off purchases, equipment, repairs, a crate of something bought for a single event, and anything you stopped buying entirely. The index measures the price of a repeated purchase. A line that appears once has no price change to measure — it has a price, which is a different thing.

How many lines are enough

Enough is when adding the next line changes the index by less than the rounding you report. If your basket covers four fifths of purchase spend and the twenty-first item is worth a fifth of a per cent of it, that item can move by half and shift your index by a tenth of a point. Stop there and put the effort into keeping the twenty accurate instead.

Weights: why by money spent and not by number of items

Weight — an item's share of purchase spend in the base period.

Weight of an item = Purchase spend on the item in the base period ÷ Total purchase spend in the base period

• Purchase spend on the item in the base period — everything you paid for that item across the base period, net of VAT, PLN;
• Total purchase spend in the base period — the same sum across every item in the basket, PLN;
• the result is a dimensionless share between 0 and 1.

Weighting by the number of items would say that a line of napkins and a line of beef are one item each — true, and useless, because they are not one zloty each. Weighting by money says how much of your purchasing each line actually controls. Here is a base period worked through:

The weights sum to exactly 1.00, and that is not a coincidence — it is the built-in check on the whole basket. If your weights do not sum to one, you have either double-counted a line or divided by the wrong total, and no amount of later arithmetic will repair it. A running series of purchase spend by item is a ledger question rather than a negotiating one: see finance and, if you are still deciding which layer holds it, CRM or ERP.

The index formula and what a base period is

Base period — the period whose prices and weights the index is measured against. Fixing it is what makes later values comparable.

Price index = Σ ( Weight of the item × Current price of the item ÷ Base price of the item )

• Weight of the item — the item's share of base-period purchase spend, dimensionless, from the formula above;
• Current price of the item — the price in the period being measured, per comparable unit, PLN;
• Base price of the item — the price of the same item in the base period, per the same unit, PLN;
• summation runs over every item in the basket; the result is dimensionless.

Index change % = (Price index − 1) × 100

Run the basket above forward one period. Meat moves from 30.00 to 34.50 PLN per kilogram, a relative of 1.15; dairy from 12.00 to 12.60, a relative of 1.05; vegetables from 7.00 to 8.40, a relative of 1.20; bread and flour from 4.00 to 4.08, a relative of 1.02; oils from 10.00 to 11.00, a relative of 1.10; soft drinks do not move, a relative of 1.00.

The same basket costs you eleven per cent more than it did in the base period.

One trap does more damage here than every other mistake combined: the unit. A price per kilogram in the numerator and a price per pack in the denominator produce a ratio that means nothing, and it means nothing quietly, because it still looks like a number. Before a line enters the index, write down its unit and never let the unit change without re-basing that line.

Fixed weights against floating weights: two numbers, two conclusions

Fixed-weight index — weights held at the base period, so the index shows price change alone.

Floating-weight index — weights recalculated each period, so the index mixes price change with change in what is bought. A different number answering a different question.

Suppose the meat rise pushed your kitchen towards dairy, so that in the current period meat holds 0.26 of purchase spend and dairy 0.34, with the rest unchanged.

Both numbers are correct. They differ by 1.4 percentage points, and the whole of that difference is your own decision to buy differently, not the market's decision to charge differently.

The working rule: keep the fixed-weight index as your price series, and if you also want the floating one, keep it in a separate column with a separate name. The failure to avoid is quoting the floating number in a supplier conversation.

That is a discount you hand over before the conversation starts.

Pass-through to a dish plate cost: the formula

Pass-through to plate cost — the share by which a dish's plate cost rises when the index rises, given how much of that dish's cost the affected items make up.

Plate cost itself is defined on our food cost page and quoted here unchanged: "Plate cost — the costed sum of every recipe component at yield-adjusted prices, for one portion exactly as it is served." The whole method of costing a dish lives there: see food cost in a restaurant.

Pass-through to a dish % = Index change % × Share of the affected items in the dish plate cost

• Basket increase — the index change over the period, per cent;
• Share of basket items in plate cost — how much of this dish's plate cost is made up of the basket items that moved, a dimensionless share between 0 and 1;
• Plate cost increase — the result, per cent of the dish's plate cost, not of its menu price.

Take a dish whose plate cost is 14.00 PLN and in which the moved basket items make up 0.70 of that cost.

The two routes agree, which is the check.

⚠️ Pass-through is not the price rise you need. These two numbers get confused constantly and the confusion is expensive in one direction: it overcharges.

How much less, and how many extra covers a price move has to bring back, is worked out on how much sales a discount has to recover and on the food cost page. Modelling that before you commit to a new menu is what what-if and forecast are for.

The formula assumes the moved items in that dish moved by the basket average. If the dish is dominated by one item — a steak, a whole fish — do not use the basket index for it at all. Use that item's own price relative, which you already computed on the way to the index.

How long to hold the weights unchanged

Long enough for the series to mean something, which in practice means a full year. Weights refreshed every month turn the fixed-weight index into the floating one by stealth: nobody decided to change the measure, it just stopped measuring prices.

Re-base once a year, on a fixed calendar date rather than when it feels necessary, and do not overwrite the old series. Keep the old index alongside the new one, and record the ratio between them in the changeover period so the two can be chained. A series that restarts at 1.000 every January and has no link back cannot answer the only interesting long question — how much your purchasing has risen since you opened. Watching this as a standing indicator rather than a one-off recalculation is the difference between a number and a report: see analytics and the numbers an owner actually looks at.

A restaurant group has one more rule here. Three sites have three different indices, and they cannot be averaged into a group number without weighting by each site's purchase spend — and even then the group number will hide the site that is being squeezed. Look at them side by side instead: managing a chain on one screen.

Supplier swap and product swap: when the index breaks

Same product, new supplier

That is a price change, and it stays in the index — but only if the unit and the specification match. Same cut, same grade, same pack size, same delivery terms. If the new supplier's pork is a different cut at a different yield, you have not found a cheaper price; you have found a different product, and the index will report a saving that your kitchen will not see.

New product filling the same role

That is a basket change, not a price change. Splice it: close the old line at its last observed price, open the new line, and treat the changeover period as a re-basing for that line alone rather than letting the substitution show up as a price fall. The single sentence that keeps this honest is worth writing on the sheet: if you cannot say that the two prices are for the same thing, it is not a price change.

Yield is where this rule earns its keep, and yield belongs to the food cost method rather than to the index: a cheaper raw price with a worse yield can raise plate cost while lowering your index. When your index and your actual food cost disagree, that gap is the subject of theoretical against actual food cost.

Answer by price, answer by recipe, answer by negotiation

An index rise is not an instruction. It is an input to three different decisions, and they have different arithmetic.

By price. You move a menu price, and the required move is smaller than the pass-through, as shown above. Which dishes can absorb it and which cannot is a menu question rather than a purchasing one: menu engineering has the method for sorting them.

By recipe. You change the portion, the yield or the component. This changes the basket, which means it changes the index — record it as a splice, or you will congratulate yourself on falling prices that are actually smaller portions.

By negotiation. You go to the supplier with the number.

Where the item sits in your purchase structure overall — and therefore how much of your total cost this conversation can move — is the subject of prime cost.

For the wider official picture your own series sits inside, see what official data say about restaurant economics in Poland. That page holds the published indices and their coverage; this one holds the method for the series nobody publishes for you.

What the index will not show: it is not about quality or service

It is a price series. That is the whole of it, and the honesty is worth more than the extra claim.

It does not see waste, theft, over-portioning or spoilage: your index can be flat while your actual food cost climbs, and that difference is the subject of the theoretical-against-actual comparison, not of this page. It does not see quality — a supplier who holds the price and quietly drops the grade shows up in your index as stability. It does not see service, delivery reliability or short deliveries. It does not see your total cost either: purchasing is one basket inside prime cost, and labour moves on its own calendar.

It also does not need artificial intelligence, and this page will not pretend otherwise. Every number above is a weighted average and two divisions; a spreadsheet does all of it. What software earns its place doing is the boring half — pulling supplier invoices into a ledger, matching the same item across suppliers and units, and keeping the series unbroken for a year so that the arithmetic has something to run on. That is the part that fails when it is done by hand, and it is the part worth automating: see restaurant automation.

Frequently asked questions

How do I build a purchase price index for my restaurant?

Take one closed period as a base, sum the purchase spend for each item, and turn those sums into weights by dividing each by the total. Record the price per comparable unit for every item in that base. In the next period, record the same prices again, divide each current price by its base price, multiply each ratio by that item's weight and add them all up. The sum is your index; subtract one and multiply by a hundred for the percentage.

How many items should be in the basket?

As many as it takes to cover about four fifths of your purchase spend, which for a single kitchen is usually between twelve and twenty lines. The stopping rule is arithmetic rather than a target: when the next item is too small to change the index by more than your reporting rounding, adding it costs work and buys nothing. Accuracy on twenty lines beats coverage of eighty sloppy ones.

Why are weights based on spend rather than on quantity?

Because the index has to answer what happens to your money, and quantities are not money. Counting items equally makes a line of napkins as important as a line of beef; counting kilograms equally makes flour more important than saffron. A weight is a share of purchase spend precisely so that a ten per cent rise on the item taking forty per cent of your budget outweighs a ten per cent rise on the item taking two.

What is the difference between fixed and floating weights?

Fixed weights are frozen at the base period, so only prices are allowed to move and the index is a pure price measure. Floating weights are recalculated every period, so the number also absorbs your own substitutions. In the worked example the same prices give 11.0 % on fixed weights and 9.6 % on floating ones, and the 1.4-point gap is entirely the kitchen buying differently. Keep the fixed one for supplier conversations.

How much does a dish cost more when my index rises?

Multiply the index change by the share of that dish's plate cost made up of the items that moved. With an index change of 11.0 % and a share of 0.70, the plate cost rises 7.7 % — on a 14.00 PLN plate cost, that is 1.08 PLN. If one expensive component dominates the dish, skip the index for it and use that component's own price ratio instead, because the basket average will be wrong in whichever direction that component moved.

What do I do when a supplier or a product is replaced?

Ask whether the two prices are for the same thing. Same product from a new supplier, with the same unit and specification, is a price change and stays in the index. A different product filling the same role is a basket change: close the old line, open the new one, and treat the changeover as a re-basing of that line so the substitution is not recorded as a price fall. The same applies to a changed pack size, which is the version of this that slips through most often.

Does a rising index mean I should raise menu prices?

Not by itself, and never by the same percentage. The index tells you what your purchasing did; it does not tell you what your guests will accept, what your competitors did, or which dishes carry the contribution. The pass-through to plate cost is always larger than the price rise needed to hold the same contribution in zloty, so copying the index onto the menu overcharges. Price, recipe and negotiation are three separate answers, and the index is the input to all three rather than the decision in any of them.

Twenty invoices across two periods are enough to build the first index, and the first one is always the hardest because it is the one where the units get sorted out. After that the conversation with your supplier runs on a number instead of a feeling. Start with your own basket, on our restaurant section, and keep it as a series rather than a one-off.