Delivery Margin After Commission: The Real Number

The advertised commission and the actual deduction are two different numbers

Ask a restaurant owner what a delivery platform charges and you get one number, quoted from memory, usually the one on the contract's first page. Open the settlement statement for the same week and you get a different, bigger number. The headline commission is one line on a statement that has several, and every other line also sits between the guest's payment and your bank account.

This page is about the arithmetic of that gap, and about one honest limitation: there is no official statistic for delivery platform commission rates, so this page does not name a single rate. That is not caution for its own sake, it is a checked fact. The Eurostat dissemination catalogue was downloaded in full on 26 August 2026 and searched end to end: the word commission appears twice in the whole catalogue, and both hits are credit-institution tables covering 1997–2001; delivery platform, take rate, courier and marketplace fee return nothing at all. There is no dataset to cite, so nothing is cited, and every rate below is an input from a worked example, not a norm.

What official statistics do confirm is that the channel matters.

Two cautions belong next to those numbers, not at the bottom of the page: section I is accommodation and food service activities, hotels included, with no separate PKD 56 cut, so "restaurants in Poland" would be the wrong words; and the survey covers only enterprises with ten or more people employed, which leaves most small kitchens outside the frame.

For that group there is no second channel to compare against. The take rate is not a negotiating position for them; it is the price of the only door they have.

What gets deducted between the order and the transfer

The list below is a shape, not a price list. Which lines exist and what base each is charged on is decided by your contract and shown on your settlement statement — the only document that can answer it for your restaurant.

Two of those rows do more damage than the rest, because they are irregular. A promotion runs for eleven days and is invisible in the other three weeks; a chargeback lands a month after the order it reverses. Generalise from one good week and you get a take rate that is real and unrepresentative at once. The window has to hold at least one promotion and one reversal: a month is the shortest honest window, a quarter is better.

Gross order value — what the guest paid on the platform, measured on the base your contract names.

Net remittance — what the platform actually transferred to your account for that order, after every deduction it applied.

The effective take rate: a formula for your statement, not for the rate card

Effective take rate % = (Gross order value − Net remittance) ÷ Gross order value × 100

• Gross order value — what the guest paid for the order, in PLN, on the base the contract names;
• Net remittance — what the platform transferred for that same order, in PLN;
• both figures come from the same statement and the same period. Taking the order value from the point-of-sale system and the transfer from the bank statement is the most common way to get a wrong answer, because the two documents cut the period on different days.

Effective take rate — the gap between gross order value and net remittance as a share of gross order value. It is measured from settlement statements, not read off a price list.

Where the gap comes from

Take one order with a gross value of 89.00 PLN. The figures below are example inputs and not a benchmark for anything:

• rate-card commission, 25 % of the order → 22.25 PLN;
• payment handling, 1.9 % → 1.69 PLN;
• the restaurant's share of a platform promotion that week → 5.00 PLN;
• the restaurant's share of a delivery-fee campaign → 1.00 PLN;
• total withheld → 29.94 PLN, so the net remittance is 59.06 PLN.

(89.00 − 59.06) ÷ 89.00 × 100 = 33.6 %

The rate card said 25 %. The statement says 33.6 %. Nothing here is a hidden charge — all four lines were agreed to; only the first is what people mean when they say "the commission". And mind the unit: the gap is 8.6 percentage points, not "8.6 per cent", which would be a different and much smaller statement.

Reading a statement into a spreadsheet by hand works exactly once. To have this number every month without a data-entry evening, the statement has to arrive in the accounting layer by itself — that is what an integration between the platform and your systems is for, and what a revenue and cost analytics layer then does with it. The live article on online orders covers how the deal with a platform is built; this page covers what to do with the statement it produces.

What base the commission is charged on, and why you read that in the contract

A percentage means nothing until you know what it is a percentage of. Three bases are in circulation, and the same rate on each yields a different amount from the same order: the menu price of the items only; the menu price plus the delivery fee the guest paid; or the whole total the guest was charged, service and packaging fees included.

No arithmetic on your side recovers that difference — it is a contractual fact, not a calculation. Read the clause, then check it against one line of one statement. If they disagree, the statement describes what happened and the contract describes what should have happened, and the distance between them is a conversation with your account manager.

The tax base is a second layer of the same matter.

These are Polish rules and are named as Polish on purpose. Charging commission on the amount with tax or without it changes the money, and the statement has to say which. Which denominator every restaurant indicator should stand on belongs to gross or net sales as the denominator.

Official statistics carry a quieter version of the same trap. Poland's statistical office publishes food service revenue including VAT — the definition heading in the 2024 volume reads, word for word, "PRZYCHODY Z DZIAŁALNOŚCI GASTRONOMICZNEJ (łącznie z podatkiem VAT)", and the 2024 total on that basis was 85.2 bn PLN (GUS, Rynek wewnętrzny w 2024 r., Warszawa 2025, opened 26 August 2026). Eurostat's turnover series for the same sector is net of VAT. Both are official, both correct, and a ratio built with one in the numerator and the other in the denominator is neither.

Packaging: a cost the dining room does not have at all

Packaging cost — everything the order needs in order to travel: container, lid, bag, cutlery, napkin, sauce cup, label. It exists only because the food left the building, and the dining-room version of the same dish has none of it.

Cost it the way you cost a recipe: per unit, from the invoice, for the packaging this dish actually leaves in. For the 89.00 PLN order above: container 2.10, carrier bag 0.60, cutlery set 0.80, label 0.20, sauce cup 0.50 — packaging cost for the order 4.20 PLN.

Two mistakes are worth naming. Folding packaging into food cost inflates the one ratio you use to talk to suppliers about ingredients — food cost is the cost of food sold over food sales and nothing else, as the food cost page sets out. Averaging packaging across all orders, dine-in included, makes every dish look dearer and the delivery channel look better than it is. Packaging belongs to the orders that used it.

The extra kitchen and floor labour, and how to measure it without inventing it

Incremental kitchen labour — the extra labour hours the delivery channel creates, valued at the fully loaded hourly cost of the people who work them. The term is introduced on this page; the price of an hour is not. That comes from the labour cost page, where Fully loaded hourly cost = Total annual cost of the position to the employer ÷ Hours actually worked, and where hours actually worked exclude paid absence (restaurant labour cost).

Time the operations, do not estimate them: the operations the delivery order adds and the dining-room order does not have: packing into containers, sealing, checking the bag against the ticket, labelling, walking it to the pickup point, handling couriers who arrive early or late. Then:

Incremental labour per order = Extra minutes per order ÷ 60 × Fully loaded hourly cost

Six extra minutes at an example fully loaded cost of 36.00 PLN an hour give 6 ÷ 60 × 36.00 = 3.60 PLN per order. Your minutes and your hourly cost are your own; the 36.00 PLN is an illustration, not a rate to copy.

A tablet on the wall is a fixed cost within the period, and putting it into a per-order contribution calculation is a category error: it does not move with the next order. Fixed costs belong in the break-even calculation, where the break-even page sets out the split between fixed, variable and semi-variable.

The contribution of one delivery order

Contribution margin — the money left from net sales after variable costs, available to cover fixed costs and, once they are covered, to become profit. Expressed as a share of net sales it is the contribution margin ratio; expressed per guest it is the contribution margin per cover. That definition belongs to the break-even page and is quoted from it word for word, so two of our own pages cannot define one term two ways.

Contribution margin per delivery order = Net remittance − Plate cost − Packaging cost − Incremental labour

• Net remittance — what the platform transferred for the order, in PLN;
• Plate cost — the costed sum of every recipe component at yield-adjusted prices, for one portion exactly as it is served, in PLN — definition and method are the food cost page's;
• Packaging cost — packaging for that order, in PLN;
• Incremental labour — extra minutes ÷ 60 × fully loaded hourly cost, in PLN.

All four terms must describe the same order. Mixing a month of remittances with the plate cost of one dish produces a meaningless number, and both inputs look real enough to survive a review.

Worked example: one order, line by line

Every figure there is an example input except the last two, which are arithmetic: 89.00 − 29.94 = 59.06, and 59.06 − 24.50 − 4.20 − 3.60 = 26.76.

Which denominator you compare on: the order value or what was transferred

The same 26.76 PLN can be expressed as a rate on two different denominators, and both are legitimate:

Channel CM rate on gross % = Contribution margin per delivery order ÷ Gross order value × 100

• the denominator is what the guest paid, in PLN.

Channel CM rate on remittance % = Contribution margin per delivery order ÷ Net remittance × 100

• the denominator is what the platform transferred, in PLN.

One order, one contribution in zloty, two rates fifteen percentage points apart. Neither is wrong. What is wrong is printing one without saying which denominator it stands on, then comparing it with a dining-room figure computed on the other.

The same order in the dining room

Pick a denominator, write it next to the number, and never compare two rates that do not share one. If both rates live on a dashboard, keep the label on both, and a reporting layer that carries the caption with the number is the cheap way to stop it. The live article on the numbers an owner actually looks at makes the same point about reports.

When a thin delivery order is still worth taking: three cases

A low contribution rate is not by itself a reason to close the channel. Three situations make a thin order worth accepting, and each has a condition that turns it off.

Idle capacity. If the kitchen is staffed and the rent is paid regardless, an order with a positive contribution adds money that would not otherwise exist. The condition: the contribution must be positive. A negative one does not improve with volume, it scales with it, and "at least it keeps the kitchen busy" does not change the sign.

Displacement is zero. A Tuesday order at 15:00 takes nothing from anyone. The same order at 20:00 on a Saturday may occupy a pass a dining-room table needed. The condition is a measurement: compare covers and delivery volume hour by hour, because "we have spare capacity" is a belief until it has a chart. A demand forecast by hour turns it into a number.

The order buys a guest, not just a sale. If a delivery guest later shows up in the room, the channel bought something the single order does not show. The condition is brutal: you have to recognise that guest again. If you cannot link a delivery order to a person and see them return, this is a hope rather than a case, and it justifies nothing. Recognising the guest at all is a guest data layer problem before it is a marketing one.

Taking orders yourself alongside the platform: what changes in the same formula

Your own ordering channel does not remove the deduction, it changes the lines. The commission disappears; the payment handling fee does not; packaging and the extra minutes do not change at all, because the food still has to travel. Delivery itself becomes a fee you charge, a courier you pay or a driver on your payroll — and whichever it is goes into the same formula, on the same order.

The arithmetic that matters most here is about pricing, and it is where restaurants lose money by accident, so it is worth setting out plainly even though the pricing decision belongs to the delivery menu price page.

A take rate divides. It does not subtract. If a platform keeps a share t of the order and you want the transfer to equal your dining-room price P₀, the price on the platform has to be P₀ ÷ (1 − t), not P₀ × (1 + t). With t = 0.30 and a dining-room price of 89.00 PLN:

• "add 30 %" gives 89.00 × 1.30 = 115.70 PLN; the transfer is 115.70 × 0.70 = 80.99 PLN — you are 8.01 PLN short, which is 9.0 % below where you started;
• "hold the transfer" gives 89.00 ÷ 0.70 = 127.14 PLN; the transfer is 127.14 × 0.70 = 89.00 PLN, exactly the dining-room price.

The two instructions sound almost identical and differ by nearly thirteen percentage points of menu price. Note what the second does not claim: holding the transfer equal to the room price still leaves packaging and the extra minutes unpaid, because those costs exist in the delivery channel and not in the room. Covering those as well is a further step and the pricing page's subject rather than this one's.

The same arithmetic applied to a reservation instead of an order is on the cost per booking page. Practically, your own channel next to a platform means two revenue streams with different deduction structures arriving in one accounting month. If they land in one bucket, the take rate becomes unmeasurable and this whole page becomes untestable. Keeping delivery as its own revenue stream with its own commission line is a finance layer decision, taken once, and the CRM or ERP article covers which layer that belongs in. The commission itself usually arrives as an invoice — the invoicing and KSeF article covers the document side.

What this arithmetic does not settle: delivery takes kitchen capacity from the room

Every number above is a per-order number. Per-order arithmetic cannot see the thing that most often decides whether the channel is a good idea: the kitchen has a maximum throughput, and during the two hours a week when that maximum binds, a delivery order and a dining-room cover compete for the same pass.

At that moment the comparison is not "is the contribution positive" but "which of these two orders has the higher contribution per minute of the constrained station". That is a different calculation with a different denominator — minutes of the bottleneck, not zloty of order value — and this page does not do it. What it can do is give you the numerator honestly, so the contribution figure going into a capacity comparison is the real one and not the rate card's.

Two more limits, plainly. This page does not tell you whether to be on a platform: that depends on your street, your kitchen and your alternatives. And it involves no artificial intelligence — every line here is arithmetic on a settlement statement and works identically on paper. Software helps in one way: getting the statement into the accounting layer by itself, so the number is recomputed monthly rather than once, on the day somebody got worried. The restaurant automation article is the wider tour; the profit margin page shows where the channel's contribution lands inside your own P&L.

Frequently asked questions

How do I calculate what a delivery platform really keeps?

Take one settlement statement and one period. Add up the gross value of the orders in it, add up what was actually transferred for those same orders, subtract the second from the first and divide by the first. That is the effective take rate. Do not use the rate from the contract, and do not pick a month with a promotion in it unless the promotion belongs in the answer — if it ran all quarter, it does.

Why is the effective take rate higher than the advertised commission?

Because the advertised commission is one deduction and the statement has several. Payment handling, your share of platform promotions, delivery-fee campaigns, voucher redemptions and reversal lines all sit between the guest's payment and your transfer, and none is usually counted when someone says "the commission is X per cent". Nothing is hidden; the headline number covers less ground than you assumed.

Is commission charged on the price with or without VAT?

Your contract decides, and it has to be read rather than assumed: the same percentage on a base that includes tax yields more money than on one that does not. Check the clause against a single line of an actual statement — if they disagree, that is a conversation with your account manager, not a rounding difference. Polish food service falls under the reduced rate through art. 41 ust. 12f and the transitional art. 146ef of the VAT act.

Should packaging sit inside food cost or on its own line?

On its own line. Food cost is the cost of food sold divided by food sales, and containers and bags in that numerator inflate the one ratio you use when talking to suppliers about ingredients. Packaging is a variable cost of the delivery channel, it belongs to the orders that used it, and averaging it across dine-in orders makes both channels look wrong at once.

How do I value the extra kitchen work a delivery order creates?

Time it, then price it. Measure the minutes the delivery order adds and the dining-room order does not have — packing, sealing, checking, labelling, handing over, waiting on couriers — divide by sixty and multiply by the fully loaded hourly cost of the people doing it. That hourly cost is the annual cost of the position divided by hours actually worked, paid absence excluded from the denominator, which is why it exceeds the nominal rate.

Which denominator do I use to compare delivery with the dining room?

Either one, as long as it is the same on both sides and written next to the number. The contribution rate on gross order value and the rate on the transfer differ widely for the same order, because the second denominator has already had the platform's cut removed. Setting a delivery rate measured on the transfer against a dining-room rate measured on the order value flatters the channel by exactly the size of the take rate.

Can a delivery order with a thin margin still be worth taking?

Yes, in three situations: when the capacity it uses is idle and already paid for, when it displaces no dining-room cover, and when it produces a guest you can recognise and see return. All three carry conditions. The first needs the contribution to be positive rather than merely small — a negative one gets worse with volume, not better. The second needs an hour-by-hour comparison rather than an impression. The third needs you to be able to identify the guest, otherwise it is a hope used as a justification.

Take one settlement statement for one week and compute the effective take rate on it. Almost nobody's answer matches the number they had in their head, and the distance between the two is the size of the decision you have been making without data. The restaurant hub gathers the rest of this arithmetic in one place: restaurant economics.