Average check is revenue divided by closed bills; spend per guest is revenue divided by covers. The two differ by party size alone, and party size drifts on its own. A restaurant whose average check rises while spend per guest stays flat is seating larger parties, not selling better, which is why upselling is judged on the guest denominator.
Two numbers the trade calls by one name
Walk into any restaurant office and ask what the average check was last week. You will get one number. Ask what it is divided by, and the conversation splits in two: some places divide revenue by the number of bills the till closed, others divide it by the number of people who sat down. Both answers are called "the average check" out loud, and they are not the same measurement.
The gap is not a rounding difference. On the same week of the same restaurant the two figures can sit 40 or 50 PLN apart, because one of them counts a table of four as a single event and the other counts it as four. When a manager reports that the average went up and an owner hears that guests are spending more, the sentence has already gone wrong — not because anyone lied, but because the denominator was never said out loud.
This page holds the two denominators and the identity that links them. What each hour of a seat earns belongs to revenue per available seat-hour; how fast a table is released belongs to table turnover. Neither of those pages is repeated here. What is repeated nowhere else is the arithmetic of the two ratios and the denominator trap that sits inside the attachment rate.
Average check — revenue for the period divided by the number of closed bills. Sensitive to party size, and therefore poorly suited to judging the work of the floor.
Spend per guest — revenue for the period divided by the number of seated guests. It does not depend on whether the guests sat down together or separately.
Average check: revenue per closed bill
Average check = Revenue ÷ Number of closed bills
Revenue— sales for the period on a stated base, the same base for both ratios;Number of closed bills— bills the till closed in that period, in units.
The result carries the unit PLN per bill. That unit is worth saying aloud, because it tells you exactly what the number is about: a bill, not a person. A bill is an accounting event. It appears when a table asks to pay, and it disappears when the same table asks to split the payment three ways, at which point one visit becomes three bills and the average check of that evening drops without a single guest changing their mind.
Which revenue goes on top of that fraction is a separate decision with its own consequences, and it is settled on its own page: whether you divide sales including tax or sales net of it belongs to gross or net sales as a denominator. Take the answer from there and keep it fixed. The only requirement this page adds is that both ratios be built on the same base — a check computed gross next to a spend per guest computed net is not a comparison, it is two units pretending to be one.
Average check is still a useful number. It is the right one when the question is about the payment event itself: card fees per transaction, how many payment terminals a room needs, how long a settlement queue gets at 22:00. It is the wrong one whenever the question is about a person.
Spend per guest: revenue per seated cover
Spend per guest = Revenue ÷ Number of seated guests
Revenue— sales for the period on the same stated base as above;Number of seated guests— covers actually seated in that period, in people.
The unit is PLN per guest, and the definition of the denominator has to be written down before anyone counts anything. Seated guests are the people who took a place and were served. They are not the people who walked past the window, not the people who called and did not come, and — this is the one that quietly breaks the number — not the number of chairs a booking reserved. A booking for six that arrives as four is four covers, and a place that lets the booking system supply the denominator will report a spend per guest that is a third too low for reasons that have nothing to do with selling.
Where does the count come from in practice? Either the waiter enters the cover count when opening the table, or the till derives it from the number of main courses, or nobody enters anything and the field is empty. Only the first is a measurement. The second is an estimate that collapses on any table sharing a plate, and the third means this page's second ratio simply does not exist in your data yet. Fixing that is a one-line change in the ordering routine and it is the highest-return change on this whole page, because without a cover count everything below is unavailable to you.
Once both counts exist, the ratio between them is itself a number worth watching, and it has a name.
Party size is the only thing between them, and it moves on its own
Party size = Number of seated guests ÷ Number of closed bills
Number of seated guests— covers seated in the period, in people;Number of closed bills— bills closed in the same period, in units.
The unit is guests per bill. Put the three formulas next to each other and an identity falls out of them, not a hypothesis:
Average check = Spend per guest × Party size
The dimensions confirm it: (PLN per guest) × (guests per bill) = PLN per bill. Nothing was assumed to get here. The identity is a consequence of the two definitions, which means it holds in every period, in every restaurant, without exception — and that is exactly what makes it useful. If the average check moved and spend per guest did not, party size did all of it. There is no third explanation available.
Party size — guests per bill. The only multiplier connecting the two ratios, and it drifts by day of the week, by weather and by season without anybody in the restaurant doing anything.
Party size is not under your control in any straightforward way. A rainy Tuesday brings couples; a warm Saturday brings groups; a school holiday brings families of five; a corporate December brings tables of twelve. All four move the average check by several tens of PLN, and all four are invisible in a report that shows only the average check. This is the whole reason the second denominator is worth the trouble of collecting.
The case where the check rises and the guest gets poorer
Two consecutive weeks in the same restaurant, same menu, same prices, same team:
| Period | Revenue, PLN | Bills | Guests | Average check, PLN | Spend per guest, PLN | Party size |
|---|---|---|---|---|---|---|
| Week 1 | 96 000 | 1 200 | 3 000 | 80.00 | 32.00 | 2.50 |
| Week 2 | 100 800 | 1 200 | 3 360 | 84.00 | 30.00 | 2.80 |
Revenue is up 5.0%.
Any report built on the first denominator says the week went well and somebody sold better.
Now the second denominator.
Every individual guest left 2.00 PLN less behind than a guest of the week before. Check the identity on the second row: 30.00 × 2.80 = 84.00, exactly the average check the till reported.
Both statements are true at once. The room worked harder, the money grew, and the selling got worse. A bonus paid on the average check that week rewards the weather.
The two-term split is a convention, and it has to be fixed once
The registry formula for splitting the change looks like this:
Change in average check = (Change in spend per guest × Party size) + (Spend per guest × Change in party size)
Change in spend per guest— this period minus the previous one, PLN per guest;Change in party size— this period minus the previous one, guests per bill;- the remaining two variables are levels, and this is the point that has to be settled.
Split with the party size of the new week and the spend per guest of the old one: (−2.00 × 2.80) + (32.00 × 0.30) = −5.60 + 9.60 = 4.00 PLN. Split the other way, with the party size of the old week and the spend per guest of the new one: (−2.00 × 2.50) + (30.00 × 0.30) = −5.00 + 9.00 = 4.00 PLN. Both reproduce the total change of 4.00 PLN exactly, and both give a different size to each half.
That is not a defect in the arithmetic; it is what a two-term split of a product always does. The honest response is to pick one convention, write it next to the report, and never switch it mid-year, because switching it changes the reported contribution of the floor without anything happening in the restaurant. The third, fully exact form keeps a cross term of −0.60 PLN separately: −5.00 + 9.60 − 0.60 = 4.00. It is the most correct and the least readable, which is why most places take one of the two-term versions and say which one.
Whichever you pick, the reading is the same here: the floor took roughly 5 to 5.60 PLN off the check, the guest mix put roughly 9 to 9.60 PLN back, and the visible +4.00 is what is left after they cancelled. Reports that show only the +4.00 hide a working problem behind a weather effect. Screens that show both halves are what dashboards and self-assembling reports are for, and the choice of which numbers an owner will actually look at is the subject of a separate article on reporting automation.
Attachment rate: how many guests took something beyond the main
Spend per guest tells you the size of the result. It does not tell you what produced it, and the component that the floor can actually move has its own ratio:
Attachment rate = Guests who took an item beyond the main ÷ Total guests
Guests who took an item beyond the main— covers with at least one starter, side, dessert, coffee or extra drink attached to the visit, in people;Total guests— all covers seated in the period, in people.
Guests divided by guests: a dimensionless share between 0 and 1. The denominator is the whole point, and it has to be guests.
Attachment rate — the share of guests who took a position beyond the main course. Counted by guests, not by bills: otherwise one party of six with a single dessert looks like a complete success.
The party of six with one dessert
Six people sit down, five have a main and go, one takes a dessert. Count by guests: 1 ÷ 6 = 0.17. Count by bills: the table paid on one bill, that bill contained a dessert, so 1 ÷ 1 = 1.00. The second number is not a stricter or a looser version of the first. It is an error of denominator, and it reports a full house of dessert-eaters where five people out of six were never offered one.
Scale that to a day and the two numbers stay incompatible. A day with 420 guests across 150 bills, where 126 guests took something beyond the main and 96 bills contained at least one such item: attachment by guests is 126 ÷ 420 = 0.30, attachment by bills is 96 ÷ 150 = 0.64. Both are computed correctly from the same till export. The first answers "how often did a guest get offered something and take it", the second answers "how often did a table contain at least one such guest". Only the first is a question about selling, and a place that reports 0.64 to its floor has told them they are doing twice as well as they are.
Three things move the average check, and only one of them is the floor
When the average check changes, exactly three things can have caused it, and they arrive with very different bills attached:
| What moved | Who moved it | Shows up in spend per guest | Shows up in party size |
|---|---|---|---|
| Menu prices | The owner, on a stated date | Yes | No |
| What each guest orders | The floor, shift by shift | Yes | No |
| Who sits down together | The calendar, weather, bookings | No | Yes |
A price rise raises both ratios and neither of them is evidence of anything except the price rise; the only honest way to read a period containing one is to compare it with the period before at the old prices, and to say the date of the change on the same screen. A change in what guests order is the floor's result, and it lands in spend per guest and in the attachment rate together. A change in who sits down together lands only in party size, and lands in the average check through the identity without touching anything else.
The menu itself sets the ceiling for the second line: a card with no natural attachments cannot produce them, however good the floor is. Which dishes carry the margin and which ones are there to be attached to is the subject of menu engineering, and it is upstream of everything on this page.
Counting attachment so that it does not count itself
An attachment rate is easy to compute and easy to inflate without noticing. Three ways it inflates itself, all of them by moving a boundary rather than by selling anything:
The first is the item list. If a glass of tap water served by default counts as an attachment, the rate approaches 1.00 in a week and stops being a measurement. The list of what counts has to be written once, kept short, and kept stable — because every addition to it raises the rate retroactively while nothing changes on the floor.
The second is the guest definition. A guest who arrives, orders and leaves is one cover. A guest who joins a table halfway through and takes a coffee is also one cover, and if your count comes from main courses that guest does not exist in the denominator, while their coffee sits in the numerator.
The third is the period. An attachment rate over a month averages a Saturday dinner into a Tuesday lunch, and both of them disappear.
Guests who never ordered a main
Take the same day: 420 guests, 126 of them with an attachment, and 60 of the 420 came only for coffee and cake without a main course at all. Compute the rate on all guests: 126 ÷ 420 = 0.30. Compute it on the 360 guests who ordered a main: 126 ÷ 360 = 0.35. Both are arithmetically correct, both are defensible, and the difference between them is five percentage points that nobody sold.
Counting forms that carry their own denominator into the answer are what calculators are for; the discipline of writing the definition next to the figure is the same discipline described in the four thresholds where small-company automation starts.
Lunch and dinner: why one average across both describes neither
Lunch and dinner are different objects. They have different party sizes, different menus, different price points and different reasons for being there. An average that spans both describes a guest who does not exist.
| Segment | Guests | Party size | Spend per guest, PLN | Bills | Revenue, PLN | Average check, PLN |
|---|---|---|---|---|---|---|
| Lunch | 900 | 2.00 | 26.00 | 450 | 23 400 | 52.00 |
| Dinner | 600 | 3.00 | 58.00 | 200 | 34 800 | 174.00 |
| Both | 1 500 | 2.31 | 38.80 | 650 | 58 200 | 89.54 |
Nothing in the restaurant costs 89.54 PLN and no guest ever pays it. It is a valid arithmetic mean of two populations that should never have been pooled.
The mix moves and both averages fall
Now change one thing and only one: lunch traffic grows from 900 to 1 200 guests. Inside each segment nothing at all changes — same party size, same spend per guest, same prices, same team.
| Segment | Guests | Bills | Revenue, PLN |
|---|---|---|---|
| Lunch | 1 200 | 600 | 31 200 |
| Dinner | 600 | 200 | 34 800 |
| Both | 1 800 | 800 | 66 000 |
Both averages fell, the restaurant earned materially more, and not one guest behaved differently from the month before.
This is why the two ratios are reported by daypart before they are reported at all. A single line for the day is not a summary of the two segments — it is a fourth number that describes a population you never served, and it moves whenever the proportions move. A chain that wants these figures comparable across three locations has the same problem one level up, which is what managing several locations on one screen is about.
Daypart — lunch and dinner as separate objects with their own party size and their own menu. One average across the two describes neither of them.
Judging an upsell: telling a real result from a coincidence with the weather
An upselling push runs for a week, the average check rises, and everybody agrees it worked. The identity above says that conclusion is unavailable: the check could have risen entirely on party size. Here is the sequence that makes the answer available.
Compare like with like. Take the same daypart in both weeks, and split it by party-size band, because spend per guest itself falls as parties get larger — a table of eight shares starters that two people would have ordered separately.
| Party-size band | Week before: guests | Week before: revenue, PLN | Week before: spend per guest, PLN | Promo week: guests | Promo week: revenue, PLN | Promo week: spend per guest, PLN |
|---|---|---|---|---|---|---|
| 1–2 guests | 480 | 15 840 | 33.00 | 360 | 12 240 | 34.00 |
| 3–4 guests | 600 | 18 000 | 30.00 | 600 | 18 600 | 31.00 |
| 5 and more | 420 | 11 340 | 27.00 | 640 | 17 920 | 28.00 |
| All bands | 1 500 | 45 180 | 30.12 | 1 600 | 48 760 | 30.48 |
Every single band gained exactly 1.00 PLN per guest. The total gained 0.36 PLN, because the cheapest band per guest — parties of five and more — grew from 420 to 640 guests and pulled the pooled figure down. A restaurant reading only the bottom row concludes the push produced almost nothing and stops it. A restaurant reading the bands concludes it produced 1.00 PLN per guest everywhere and keeps it.
Second, look at the attachment rate over the same split. Spend per guest can rise because guests bought the same things at higher prices; the attachment rate can only rise because more guests took something extra. Two indicators moving together are a result. Spend per guest moving alone, in a week when the menu was reprinted, is a price rise.
Third, say what you did not control. A promo week that coincides with warm weather, a public holiday or a football match is not a clean comparison, and the honest report names the coincidence instead of hiding it. Nothing on this page can separate an effect from a coincidence that happened once; only repetition can, which is why an upsell that matters is measured over several comparable weeks and not one. Pulling the same split out of the till automatically, week after week, is what analytics is for, and the wiring of bookings, suppliers and reviews into one place is described in the article on restaurant automation.
What goes on the shift screen so the number changes behaviour
A number that arrives in a monthly report changes nothing, because by the time it arrives the shift it describes is four weeks old and the people who worked it have forgotten the evening. The two ratios on this page are worth putting where they can still be acted on.
Three lines are enough for a service screen, and each of them carries its denominator in the wording:
- spend per guest for this daypart, today so far, against the same daypart last week;
- attachment rate by guests for this daypart, today so far, against the same daypart last week;
- party size, shown as context and never as a target.
The third line is the one people try to delete, and it has to stay. Without it the first two are unreadable: a shift that seated unusually large parties will show a lower spend per guest with no fault of its own, and the only way for the floor to see that is to have the party size in front of them.
Reading the screen when the shift is half over
Early in a service the counts are small and the ratios jump. A screen that shows spend per guest after eleven covers is showing noise, and a floor that chases it will push desserts at the wrong tables. Set a floor on the count — no ratio until the daypart has passed some number of covers that fits your room — and show the raw counts until then. The same restraint applies to comparisons: yesterday is not a comparison, the same weekday last week is.
What is deliberately not on that screen is a target. There is no published industry average check for restaurants in Poland: the figure is not collected in the official statistics, so any "the average check in the sector is such-and-such" you meet in an article has no source behind it that you can open. Checked on 28 August 2026: neither the full Eurostat dataset catalogue nor the GUS trade section holds such a dataset. Your comparison base is your own previous period, by daypart, by party-size band — and building that base is worth more than any borrowed benchmark, because it is the only one that shares your menu, your prices and your room.
Who is standing in that room while the numbers move is the next question in this section, and it is answered on its own page: staffing is measured per guest and not per bill, which is the subject of how many people a shift needs. What happens to the numerator after the bill is closed — discounts, voids and comps — is the subject of discounts, voids and cancellations at the till. Rota and task assignment for the people involved is what shifts and tasks covers, and how much of this counting can be automated at all is estimated in the article on what process automation costs.
Frequently asked questions
What is the difference between average check and spend per guest?
Average check is revenue divided by the number of closed bills; spend per guest is revenue divided by the number of seated guests. They differ by exactly one factor, party size, and the identity between them is average check = spend per guest × party size. The first is a statement about a payment event, the second is a statement about a person.
Why can the average check rise while spend per guest falls?
Because party size can grow faster than spend per guest falls. In the two-week example on this page revenue rose 5.0% and the average check rose from 80.00 to 84.00 PLN, while spend per guest fell from 32.00 to 30.00 PLN because the restaurant seated 3 360 people instead of 3 000. Larger parties lifted the check; every individual guest left less money.
Which one should be used to judge upselling?
Spend per guest, together with the attachment rate. The average check contains party size as a factor, and party size is set by the calendar and the weather rather than by the floor. Judging a shift on the average check pays a bonus for a Saturday that filled with groups and withholds it for a Tuesday of couples.
How is attachment rate calculated correctly?
Divide the number of guests who took an item beyond the main course by the total number of seated guests in the same period and daypart. Write the item list down once and keep it stable, because every item added to the list raises the rate retroactively without anything being sold. State the denominator on the same screen as the result.
Why must attachment rate be counted per guest, not per bill?
Because a bill covers a whole table. A party of six with one dessert gives 1 ÷ 6 = 0.17 counted by guests and 1 ÷ 1 = 1.00 counted by bills. On a full day the same export gave 126 ÷ 420 = 0.30 by guests against 96 ÷ 150 = 0.64 by bills. The bill version answers a different question and flatters the floor by roughly double.
Should lunch and dinner be averaged together?
No. In the worked example lunch runs at 26.00 PLN per guest with parties of 2.00 and dinner at 58.00 PLN with parties of 3.00; pooled they produce an average check of 89.54 PLN that belongs to neither. Adding 300 lunch guests while dinner stays untouched tilts the mix toward lunch: both pooled averages drop while revenue rises 13.4%, and nothing inside either segment changes.
How do I separate the effect of the team from the effect of party size?
Split the change with the identity: one term is the change in spend per guest, the other is the change in party size. Fix which of the two factors is taken at the new period and never switch it — in the example the split gives −5.60 and +9.60, or −5.00 and +9.00, and both add to the visible +4.00. Then check the result band by band, because a shift in the mix of party sizes moves the pooled figure on its own.
Take two closed weeks from the till, put revenue, bills and covers in three columns, and split the change in the average check into the two halves before anyone talks about a bonus. In most rooms the second half — who sat down together — turns out to be the larger one, and that single fact changes what the conversation about the floor is even about. The rest of the section is here: restaurants.