European delivery apps and why VAT moves your menu prices
Restaurant chains running a European estate compare displayed prices across markets and reach wrong conclusions, because the displayed price contains a variable that has nothing to do with pricing policy. Value added tax on food differs between member states, several treat delivery differently from the food itself, and some distinguish hot from cold or eat-in from takeaway. Identical net pricing therefore produces different customer-facing prices across markets, correctly, and a review that ignores this generates work where there is no problem.
What varies between European markets on VAT?
Three things, and they compound.
The rate applied to food, which differs by country. Whether the delivery charge carries a different rate from the food. And whether the channel matters, meaning that the same dish can attract a different rate eaten in than delivered.
Any of those alone produces a visible difference. Together they can make two markets with identical policy look several percent apart.
How should an estate be compared then?
On net prices, always, and on displayed prices only within a single market.
That single change removes most of the noise from a European price review. It also makes deliberate local decisions visible, because once tax is out of the comparison, a difference is a decision rather than an artefact.
Keep both numbers. Net for internal comparison, displayed for anything customer-facing, including competitor comparison.
Does the channel distinction cause operational problems?
It causes a specific and common one: the same item priced identically in the restaurant and on the app arriving at different totals for the customer.
That is correct and it looks like an error to everybody who has not thought about it, including customers and sometimes including site managers. Groups that operate both channels benefit from a short written explanation held by whoever fields the question.
Where does this interact with the delivery listing itself?
At the point where a tax change has to be reflected, which is where errors enter.
A rate change requires a price update across every listing in that market. Updates fail partially, apply to one platform and not another, or miss items that were edited locally at some earlier point. The result is a market where some items carry the new treatment and some do not.
Nothing announces that. The only way to see it is to read the prices the listings are showing. Kitchain (kitchain.co) reads them per site and per platform, so a rate change that landed on nine listings out of ten is a list on the Monday rather than a discovery in the audit.
Who should own this?
Finance owns the rates and operations owns the listings, and the handover between them is where it breaks.
The practical fix is that a rate change is treated as a project with a verification step, not as a notification. Somebody confirms afterwards that every listing in the market shows the new prices, and the confirmation is a look at the storefront rather than at the upload log.
Is there any platform obligation here?
None about tax, which is yours.
What the European rules require is that the platform’s own terms are in plain language and available, and that changes to them come with notice on a durable medium of “at least 15 days”. Commission and promotional funding changes arrive through that route and often trigger a pricing response, so the two subjects meet more often than they look as though they would.