A plate of pasta and a glass of wine, one table, one bill. In Germany the pasta carries 7% VAT and the wine 19%. In France the pasta is 10% and the wine 20%. In Italy and Spain the whole thing is 10%, wine included. Same order, same evening, three different answers, and not one of them is a rounding error. Which means the tax on your sales is settled by how your restaurant POS system is configured, item by item, long before anybody opens a spreadsheet.
That is the part operators tend to have backwards. VAT feels like an accounting job, something that happens at the end of a quarter when the numbers go off to the bookkeeper. It is not. The rate is fixed at the moment of sale, by the till, from what was sold and how it left the building. Your restaurant accounting software can only report what the till recorded. If a takeaway beer went through at the dine-in rate, no reconciliation at month end will find it, because the fact that would have distinguished the two was never captured in the first place.
One caveat before any of the numbers. Rates change, and they change with politics rather than with logic, sometimes at a few weeks' notice. Germany rewrote its restaurant VAT on 1 January 2026. Treat every figure below as a worked example, check the current position with your accountant, and take from this the structure instead, which moves far more slowly than the percentages do.
The question everyone asks is the wrong question
Ask an operator how VAT works in a restaurant and you will get the same answer almost every time: eat in and you pay more, take it away and you pay less. That rule of thumb was never universal. It is now wrong in more places than it is right.
Four countries, four different tests. Germany asks whether the thing is food or drink. France asks whether it could be kept. Italy and Spain ask whether you served it or sold it. Only that last pair resembles the eat-in rule at all, and the mechanism underneath is not what most people assume it is.
None of this is deliberate awkwardness. EU law sets a framework and a list of categories that member states may tax at a reduced rate, then leaves each state to draw its own lines inside that list. Twenty-seven governments drawing lines independently produces exactly what you would expect it to produce.
Germany, since January 2026: food at 7, drinks at 19
Until the end of 2025 Germany ran the textbook version of the eat-in penalty. Food served at a table was a service, and services carried the standard 19%. The identical food handed across the counter to take away was a supply of goods at the reduced 7%. A 12 point gap on the same lasagne, decided by whether the customer sat down.
That stopped on 1 January 2026. Food is 7% now whether it is eaten at the table, carried out, or delivered. The distinction that dominated German hospitality tax for the better part of a decade simply ceased to exist.
Operators celebrated, then read the rest of it. Drinks stayed at 19%, and they stayed there in every channel. So the old split did not vanish. It rotated. Germany used to ask where the customer ate, and it now asks what is in the glass, and it asks that about every order rather than only the ones going out of the door.
The practical consequence is apportionment, and it is genuinely new for the dining room. Before 2026 a table order was 19% throughout and needed no breakdown at all. A set menu at one price with a drink included was a single rate applied to a single number. That same set menu now contains food at 7% and a drink at 19%, so one price has to be split into two before it can be declared. Every German restaurant selling a Menü, a buffet with drinks, or an all-inclusive package picked up a calculation in January that it had never had to do.
There is a concession for package prices, a flat allocation of a share of the total to the drinks, which spares operators from apportioning every bundle by hand. Whether you qualify depends on the package, which makes it precisely the sort of thing to put to an accountant rather than to a blog. What matters here is narrower: the till has to be capable of splitting one bundle price across two rates at all. A surprising number are not.
Then the edges, which are properly strange. Milk and milk based drinks above a certain milk content are reduced rate taken away but standard rate served on the premises, so a latte to go and a latte at the table are taxed differently while the pasta next to them is taxed the same. A short list of luxury foods, caviar and oysters and lobster among them, sits at the standard rate as goods, so a takeaway order of those does not pick up the 7%. Nobody builds a menu around any of this. Somebody still has to configure it.
France asks whether it could be kept
France never used the eat-in test, which tends to surprise people who assume the rule is European rather than national. The French question is about time. Is this going to be eaten now, or could it sit in a fridge until Thursday?
Immediate consumption is 10%, covering food and non-alcoholic drinks served to be consumed straight away, in the dining room, on the terrace, at the counter, or on the pavement after a takeaway sale. Deferred consumption is 5.5%, and it applies to food packaged so it can be kept, meaning a sealed container carrying a shelf life. Alcohol is 20% in every case, with no channel exception worth planning around.
Notice that location does nothing in that list. Packaging does everything. A hot sandwich wrapped in foil is 10%, because foil preserves nothing. The identical sandwich vacuum sealed with a use-by date is 5.5%. Ice cream scooped into a tub is 10%, the same ice cream in a sealed sleeve is 5.5%. A soft drink poured into a cup is 10%, the same drink in a closed can is 5.5%. Your customer can be standing in one spot for all six of those transactions.
France also has the hardest penalty for getting the mechanics wrong, and it is the strongest single argument for caring about how your till is set up. Apportioning takings across rates, what the French call la ventilation des recettes, is an obligation and not a convenience. Where a bill spanning several rates is not properly apportioned, the highest rate on that bill can be applied to all of it.
Work it through on a €14 pizza and a €6 glass of wine. Done properly the food carries about €1.27 of VAT and the wine €1.00, so €2.27 in total. Taxed as a single standard rated €20 it becomes €3.33. That is €1.06 of margin on one ticket, which sounds like nothing until you multiply it. Sixty mixed tickets a day is roughly €23,000 a year, and mixed tickets are not an edge case in a restaurant that sells wine.
Italy and Spain ask who served it
Italy and Spain reach the eat-in question from the opposite direction, and the answer comes out backwards from what most operators expect.
In both countries, serving food and drink on the premises is a service, and the service takes the reduced rate as a whole. Italy taxes somministrazione at 10%. Spain taxes hostelería at 10%. The part that catches people is that this covers the drinks, alcohol included. A glass of Chianti at an Italian table is 10%. A glass of Rioja at a Spanish table is 10%. That is the reverse of the German and French position, where alcohol is standard rated no matter what you do with it.
Take the same drink away and everything moves, because a sale to go is a supply of goods rather than a service, and goods are rated one at a time. In Italy a beer handed over the counter is 22%. Poured at a table two metres away it was 10%. A bottle of grappa sold to take home is 22%, the same grappa served as a digestivo is 10%. Prepared dishes to take away or deliver do hold the 10%, settled by legislation in 2021, but that relief was written for food and pointedly not for drinks. Loose fruit, meanwhile, can be 4%.
Spain runs the same logic with different numbers. The menú del día eaten at the table is 10% throughout, wine and all, and needs no breakdown on the bill. Sell that identical menú for collection and the food stays at 10% while the wine goes to 21%, and now the ticket does have to show the split. Spain adds a trap with nothing to do with channel: soft drinks containing added sugar or sweeteners are 21% rather than 10%, and since the test is the presence of sweeteners, the diet version is caught just as surely as the full sugar one.
Italy's cover charge earns its own footnote, since the coperto is not food and does not ride along at the food rate. If you are working out how service items are taxed and who they actually belong to, service charge and tips takes on the wider version of that question.
The same three orders in four countries
Abstractions are hard to configure a till from, so here are three real orders.
| Order | Germany | France | Italy | Spain |
|---|---|---|---|---|
| Food, eaten in | 7% | 10% | 10% | 10% |
| Food, taken away | 7% | 10%, or 5.5% if sealed | 10% | 10% |
| Beer or wine, at the table | 19% | 20% | 10% | 10% |
| Beer or wine, taken away | 19% | 20% | 22% | 21% |
| What decides the rate | Food or drink | Could it be kept | Served or sold | Served or sold |
Read the two beer rows twice, because the whole configuration problem is inside it. The beer does not have a VAT rate. The beer has a VAT rate per country per channel, and in two of those four countries the channel moves it by eleven or twelve points. A system that stores one tax rate against the product record cannot express that, and no amount of care from your staff will rescue it.
What this actually asks of the till
Strip the national detail away and the requirement is short. Short is not the same as easy.
The rate has to be a function of item and channel together. Not a property of the item on its own. This is the big one and the place cheap systems fail, because a product record with a single tax field is a product record that cannot be right in Italy or Spain.
Channel has to be a real attribute of the order. Set before the items are priced, and visible to the tax logic: eat in, takeaway, delivery, and each delivery marketplace separately, because a platform is a channel too. If the system treats the order type as a label printed on a receipt, it is worthless for this.
Bundles have to split. One price covering items at different rates needs to apportion across those rates by a method you can defend, and the method has to be stored rather than recomputed slightly differently by whoever runs the next report.
Rates have to be effective dated. Dated, not edited. When a rate changes at midnight on 1 January you need December's sales holding December's rate and January's holding January's, permanently, with nobody retyping anything.
And it has to come back out. Net sales by rate, by channel, by period, in a shape that reconciles to what you actually declare.
Set menus, buffets and the apportionment problem
Apportionment deserves its own section because it is the requirement that has grown fastest. Germany created a dining room version of it in January. Spain and Italy have wanted it on takeaway sales all along. France enforces it with the highest-rate rule described above.
The question is always the same: this bundle sold for one price and contains items at two or three rates, so how much of that price belongs to each? There are three broad answers and they give different numbers.
You can split by the à la carte prices of the components, which is the most intuitive and usually the most favourable, since the drink is typically the highest margin item in the bundle. You can split by cost, which is defensible, unfavourable, and unpopular for exactly that reason. Or you can use a flat allocation where the law offers one, like the German package concession, which is the least work and removes the argument entirely.
Whichever you pick, pick one and make the system do it. Apportionment done by hand in a spreadsheet at the end of a quarter is apportionment that will be inconsistent between quarters, and inconsistency is the thing an inspector notices first. It is also worth checking what your system does with a discount on a mixed bundle, since a 20% promotional discount on a menu containing two rates has to come off both proportionally rather than off whichever line the software happens to reach first.
When the order type changes after it is rung
A customer orders at the counter to take away, then spots a free table and sits down. Or orders for here, takes a phone call, and asks for it in a bag. In Italy and Spain that change moves the tax. In France it can move it. In Germany, for food, it no longer matters at all, which is one real simplification from the 2026 change.
The question for your till is whether switching the order type re-rates the items or merely relabels them. Relabelling is the common failure and it is the hard one to catch, because the receipt looks perfect. The order header says takeaway, the lines say takeaway, and the tax was calculated the moment those items were first rung and never recalculated since.
You will not find this in a brochure. You find it by ringing an order, switching the type, and watching whether the tax total moves. It takes about 40 seconds and it has failed in real evaluations.
The receipt, the register and the return
Most countries want the receipt to show a VAT breakdown by rate, and several want it specifically where one sale mixes rates. Spain expects the split on a takeaway ticket combining food and alcohol. Italy's electronic register needs its takeaway function configured so a sale to go is recorded as goods at the right per item rates instead of as a service at 10%, and that is a keypress somebody has to actually press.
Sit with that for a second, because it is the gap between a compliant system and a compliant restaurant. A perfectly configured till operated by someone who never hits the takeaway key will produce confidently wrong data all day and give you no reason to doubt it. Configuration is necessary and nowhere near sufficient. The workflow has to make the correct thing the easy thing, which in practice means channel is a required choice at the start of an order rather than an optional button somewhere near the end.
Out the other end you need net sales by rate for the period, since that is what the return is built from. In Spain it feeds the quarterly modelo 303. Wherever you are, the test is whether the number your system reports by rate ties to the number you declare, and whether you can still produce it for a quarter that closed eighteen months ago. If your daily close does not break down by rate, then Z reports are doing less for you than they should be.
The day the rate changes
Rate changes are political, so they land with short notice and a hard edge. Germany's move to 7% on food took effect at midnight on 1 January 2026. Three things bite on a day like that.
The rate that applies is the one in force when the supply happens, not when the invoice is raised and not when the money arrives. A December dinner invoiced in January is taxed at December's rate.
Everything displaying a price has to change at once, including the things people forget: printed menus, the specials board, the website, QR code menus, and every listing on every delivery platform. A menu still showing last year's VAT inclusive price is less a tax problem than a margin problem, and it is a margin problem happening in public.
Vouchers and deposits need a decision, because they straddle the boundary by design. A gift voucher sold under the old rate and redeemed under the new one, a deposit taken in November for an event in January: each has a rule and they are not the same rule. Deposits carry their own tangle, which the festive season playbook gets into properly.
The systems lesson repeats. If changing a rate means editing the rate on the product record, you have quietly destroyed your own history, and the first person to notice will be an auditor asking why last year's figures have moved since last year.
The formats where this gets genuinely painful
Some businesses live on the boundary and feel every millimetre of it.
Counter formats have it worst. A bakery sells the same item under two or three treatments in one morning and the customer decides which one at the last possible second, usually while four people wait behind them. A bakery POS has to carry all of that at the speed of a queue, which is a harder problem than carrying it correctly at leisure.
Delivery is next, and it is worse than it looks, because a marketplace is a channel whose rules you only partly control. Whether the food is your supply or the platform's, what the delivery fee itself attracts, and how commission is treated all interact with the rates. third party delivery covers the commercial side of those relationships; the tax side is worth a specific conversation per platform, because the answer is not the same for all of them.
Coffee shops collect the whole set: the milk drink edge in Germany, the sealed can question in France, the sweetener rule in Spain, all on a menu where the average ticket is about €4. Small amounts, enormous transaction counts. That is the precise shape of an error nobody notices for three years.
What to test before you sign
Bring a test script to the demo and drive it yourself. Six checks, all of which have failed somewhere real:
Ring the same item in two channels. One eat in, one takeaway. Look at the tax lines, not the totals. If they match in a country where they should differ, stop the demo.
Switch an order's type after ringing it. Confirm the tax recalculates rather than the label changing.
Ring a set menu with a drink in it. Ask to see how the single price was apportioned, and ask where that method is configured. Then discount it 20% and check the discount came off both rates proportionally.
Ask to see a rate change. Specifically, ask them to add a rate that starts next month without touching this month's numbers. Watch whether they edit a field.
Pull net sales by rate by channel for a past month. Ideally one before the last software update. This is the report you will actually live on.
Print a mixed receipt. Check the breakdown by rate is on it and legible, and that the totals add up to the amount taken.
Everything on that list is a question about data model rather than features, which is why it is worth asking early. A vendor who cannot vary tax by channel is not going to add it for you in the implementation week.
Where the money actually leaks
One closing point on why the configuration is worth the afternoon, because the cost of getting it wrong is not symmetrical.
Undercharge and you owe the difference. You cannot go back to the customer who ate a lasagne in March and ask for another €1.40, so the shortfall comes out of margin, with interest, and usually for every period the error ran rather than just the one it was found in. Two points of rate error on €400,000 of annual food sales is €8,000 a year, and this class of error is typically found in year three, not year one.
Overcharge and the damage is quieter. You have been slightly more expensive than the place across the road for as long as it ran, you may owe customers a correction, and unwinding it costs more admin than doing it right would have.
Either way the fix is the same and it is not heroic. Make channel a required field at the top of the order. Store the rate against item and channel together. Confirm bundles split and that switching the order type re-rates instead of relabelling. Then pull net sales by rate, by channel, for last month and hold it next to what you declared. If the two disagree you have found your next job. If your system cannot produce that report at all, you have found something rather more important than your next job.
Read next: menu pricing strategy for setting VAT inclusive prices without giving away the margin, profit and loss statement for where net of VAT sales land in the accounts, and POS with online ordering for how the digital channels feed the same tax logic.
