A bakery till does things a restaurant till never has to. It weighs a bag of rolls and prices them by the kilo. It takes a deposit in March for a christening cake in May, along with the spelling of a name that must not be got wrong. At half past four it drops the price of everything still in the window by a third, and it needs to record that as a markdown rather than a discount, because those two numbers tell you completely different things. Then on the first of the month it raises invoices for eleven cafes that have been taking sourdough on account all month. None of that appears in a demo of a restaurant POS system, which is why so many bakers end up running a spreadsheet alongside their till and calling it a system.
The other half of the problem is behind the counter. A bakery is a small factory with a shop attached, and the shop is the only place the factory gets any feedback. Every croissant sold at 8am and every loaf binned at 6pm is data about tomorrow's production, and if the till cannot hand that back in a form a head baker can use at five in the morning, the mix stays a guess forever. Which makes the link between the till and stock management the part worth getting right, more than the colour of the buttons.
What follows is not a feature list. It is the set of things a bakery does that break ordinary hospitality software, with what good looks like for each, roughly what the whole thing costs, and the questions that tend to expose a vendor who has only ever sold to cafes.
What is a bakery POS system?
A bakery POS system is a point of sale built for selling perishable goods that are produced on site, in volume, at low unit prices, through more than one channel. The definition matters less than the six demands that follow from it, and those are what separate a bakery till from a cafe till:
- Sale by weight: integrated scales, tare handling, and pricing per kilo or per pound alongside per-item.
- Forward orders: cakes and catering booked days or weeks out, with deposits, collection slots and written details.
- Markdown and waste: end-of-day price reductions and bin counts recorded per product, with a timestamp.
- Wholesale accounts: standing orders, customer-specific price lists, delivery notes and monthly invoicing.
- Split tax rates: the same pastry taxed differently depending on whether it is eaten in, taken away or served hot.
- Ingredient labelling: allergen and full ingredient data attached to products and printable at the counter.
A system that handles four of those will work. One that handles two will have you back in a spreadsheet by the second month. The sections below take each in turn, and the last three cover speed, cost and how to test a vendor's claims.
Why a restaurant POS struggles behind a bakery counter
Restaurant software is built around a table and a bill that stays open. A guest sits down, items get added over an hour, the bill grows, then it closes. Almost every design decision follows from that: the floor plan, the open tab, the course firing, the seat numbering, the split by seat at the end.
A bakery has none of it. There is no table. The average transaction takes eleven seconds and might be one coffee and two pastries. Transaction counts are high and basket values are low, so the cost of a single extra tap gets multiplied by six hundred a day. Meanwhile the things a bakery genuinely needs, weight and forward orders, are retail features that hospitality vendors often have not built at all.
Retail POS has the opposite problem. It knows about weight, barcodes and stock units, and it knows nothing about hot food tax, kitchen production or a coffee modifier. Bakeries with a seating area fall in the gap between the two categories, and the gap is where the spreadsheets breed.
Selling by weight
Plenty of bakeries never need this. If everything is priced per item, skip ahead. But sell bread rolls by the half dozen, pick-and-mix biscuits, traybakes cut to order, or anything at all in a market where bread is legally sold by weight, and a till without scale support becomes a person doing arithmetic in their head while eight people wait.
Scales, tare and price-embedded labels
Three things to check, and vendors are slippery about the difference. First, does the system read a scale directly, over serial or USB, so the weight lands in the basket without anyone typing it? A till that makes staff read a number off a separate display and key it in is not scale integration, it is a scale sitting next to a till. Second, does it handle tare, so the weight of the bag or box comes off automatically? Third, can it read price-embedded barcodes, the kind a label printer produces in the back when something is packed and weighed before it reaches the front.
That third one is what lets a bakery weigh and label at production rather than at the counter, which is usually where the queue time actually goes. Weigh the tray of flapjack once, print twelve labels, and the counter just scans. It also means the till needs to accept two price sources for the same product without treating one as an error.
Worth confirming the scale is trade-approved for your market if you are selling by weight for money. In the UK and EU that means a stamped Class III instrument, and a POS integration will not make an unapproved scale legal.
Custom cake orders, deposits and collection dates
This is where most bakeries discover their till was designed for a different business. A celebration cake is not a sale, it is a contract with a delivery date, and it carries information that a line item cannot hold: the inscription and its exact spelling, the tier count, the filling, an allergen the customer mentioned once at the counter, the collection window, the phone number, and whether the deposit was cash or card.
Handled badly, that lives on a paper diary behind the counter. Which works until the person who wrote it is off, or the page gets flour on it, or two cakes are promised for the same Saturday morning and nobody notices until Friday night.
What good looks like: a forward order is a first-class object in the system, not a note in the comments field. It has a due date and time, a status you can filter by, a deposit recorded against the eventual balance, and free-text fields that print in the production area rather than only on the customer's receipt. You should be able to stand at the till on Tuesday and answer "what is due out on Saturday, and what is still unpaid" in one screen. You should also be able to cap how many cakes any given day can accept, because a diary that lets you oversell Saturday will eventually oversell Saturday.
The accounting side trips people up too. A deposit taken in March for a cake collected in May is not revenue in March, it is a liability, and if the till books the full amount on the day the deposit is taken your monthly numbers will lie to you. Ask specifically how deposits flow through to the books, and whether the balance settles cleanly against the original order rather than becoming a second unrelated sale.
Markdown and waste, the number that defines a bakery
Every bakery lives with the same uncomfortable fact: you have to bake more than you will sell, or you disappoint people by ten in the morning and train them not to come back. So the question is never whether there will be surplus. It is how much, which products, and what you did with it.
Typical artisan bakeries run somewhere around four to ten percent of production unsold, and bread sits at the ugly end because it is unsellable the next day in a way that a biscuit is not. The operators who get that number down are not baking less. They are measuring it per product per day and changing the mix.
Three different events, and a till that lumps them together is costing you the insight:
- Markdown: sold, at a reduced price, usually in the last hour. Revenue came in, margin was thinner.
- Waste: binned. No revenue, full ingredient and labour cost absorbed.
- Staff and charity: given away. No revenue, but the cost is a deliberate decision rather than a failure.
If all three land in the reports as "discount", you cannot tell a bakery that is cleverly clearing its window from one that is quietly throwing away eight percent of its flour. Insist on separate reason codes and a timestamp. The timestamp is the underrated part: markdowns starting at two in the afternoon rather than half past four is not a pricing problem, it is a production problem, and the only way you will see it is by looking at when the reductions began over a fortnight. Recording it properly is also the first step in any serious attempt at cutting food waste, because you cannot cut what you have never counted.
Turning yesterday's sales into tomorrow's bake list
The head baker's first decision of the day, usually made around four or five in the morning, is how much of each thing to make. Get it right and the window looks full at nine and nearly empty at five. Get it wrong in one direction and you have bins full of bread, in the other you have customers turning around and leaving.
Most bakeries make that call from memory and a feeling about the weather. A till that reports properly can do a lot better, and the useful report is not total sales. It is sell-through by product by day of week, with the sell-out time attached. A product that goes at 100 percent every Saturday is not a success story, it is evidence you are leaving money in the oven, and the sell-out time tells you how much: gone by 10am means you should be making more, gone at 4pm means the quantity is about right.
Pair that with day-part data. A bakery usually has two or three distinct trading patterns in a single day, a commuter rush, a lunch peak and a slow afternoon, and they want different products rather than more of the same. The same technique applies here as in any other venue doing proper sales forecasting: last four same-weekdays, adjusted for anything unusual, not a single week or a whole-year average.
The other half is backwards. Ingredient consumption should come off the same data, so that selling 240 sourdough loaves depletes flour, water, salt and starter by recipe rather than waiting for somebody to count sacks on Sunday. That is what makes ordering something other than guesswork, and it is the single biggest reason to care whether your till talks to your stock properly.
Wholesale accounts, standing orders and sale or return
For a lot of bakeries the counter is the visible half and wholesale is the profitable half. Supplying cafes, delis, restaurants and farm shops can be a third to a half of revenue, and it runs on completely different mechanics from a retail sale.
A standing order repeats: the cafe on the corner takes twelve baguettes and twenty croissants every weekday, forty on Saturday, nothing Sunday. Nobody should be typing that in daily. The system should generate the day's delivery run from the standing orders, allow one-off variations without breaking the pattern, and produce a delivery note per customer that somebody can sign at seven in the morning.
Then the money. Wholesale customers pay on account, monthly, on their own price list, which is not your counter price. So you need customer-specific pricing, a credit limit that flags before you deliver to somebody who has stopped paying, consolidated invoicing at month end, and a clean handoff to whatever you use for restaurant accounting so your bookkeeper is not re-typing it.
Sale or return deserves its own warning. If you supply on the basis that unsold stock comes back, then a delivery is not a sale yet, and your revenue is not known until the returns are counted. Bakeries that treat sale-or-return deliveries as straight sales overstate turnover all month and then take an unpleasant credit note hit. Ask the vendor directly whether the system models returns against the original delivery, and be suspicious of an enthusiastic yes without a demo.
Eat-in versus takeaway, and the tax that follows the customer
If your bakery has four tables, this section will save you more money than any other. In a lot of tax regimes, the rate on the same item changes depending on how it is sold, and bakery products sit right on the boundary.
In the UK, most bread and cakes are zero-rated for VAT, but anything eaten on the premises is standard rated at 20 percent, and so is anything sold hot. Which means one sausage roll can carry three different VAT treatments in one morning: cold and taken away, hot and taken away, or eaten at the table by the window. The category is riddled with edge cases that have been litigated for decades, the chocolate-covered biscuit question being the famous one. In the EU the pattern is similar with different rates per country, and in the US the equivalent problem is sales tax that varies by state and sometimes by city on prepared versus unprepared food.
None of that is your till's fault, but the till decides whether you get it right six hundred times a day. What you need is a single control at the point of sale, one tap for eat in or take away, that re-rates the whole basket automatically, plus the ability to set a different rate on the hot version of a product without maintaining it as a separate item with a separate stock count. Staff will not remember to change a tax code. They will remember to press a large button labelled "eat in".
Get this wrong in the lenient direction and you are paying tax you did not owe. Get it wrong the other way and you have an underpayment accruing quietly until somebody asks for four years of records.
Allergen and ingredient labelling at the counter
A bakery handles wheat, egg, milk, nuts and soy as a matter of routine, which makes it one of the highest-stakes counters in food retail for allergen questions. The regulatory direction of travel is one way, towards more information printed on the item rather than recited by whoever is serving.
In the UK, food that is prepacked for direct sale, meaning packed on the premises before being ordered, has needed a full ingredient list with allergens emphasised since October 2021. That applies to the sandwich you wrapped this morning and put in the chiller. The practical consequence is that your product data and your label printer have to be joined up, because maintaining ingredient lists in a separate document from the product file guarantees they will disagree within a month.
What to look for: allergen and ingredient fields on the product record itself, the ability to print a compliant label from that record, and a way for counter staff to answer "does the focaccia have milk in it" from the till screen in a few seconds without finding a manager. Systems that treat allergens as a free-text note will drift. Broader practice on this sits in our guide to allergen management, and the labelling requirement is the part most bakeries underestimate.
Counter speed in the morning rush
Between about half seven and half nine a bakery can do forty to sixty percent of its daily transactions. The queue at that hour is mostly people on their way to somewhere else, and their tolerance is short. Speed is not a nice-to-have, it is the revenue.
The arithmetic is unforgiving because the basket is small. Add two seconds to a transaction and at six hundred transactions you have added twenty minutes of queue across the day, which lands entirely in the two hours when you can least afford it. So the things that matter are dull ones: how many taps to sell a coffee and a pastry, whether the most-sold twelve items are on the first screen without scrolling, whether the card terminal is triggered by the till or has to be keyed separately, and how fast the thing is after the card is tapped.
Two practical notes. Order the button grid by actual sales volume rather than by menu logic, and re-check it every few months, because it drifts. And if you have a seating area, look hard at whether counter staff should be taking coffee orders at all during the peak, or whether that traffic belongs on a screen the customer operates. Mobile ordering for collection takes the slowest part of the transaction out of the queue entirely.
Working offline at markets and pop-ups
Many bakeries trade somewhere other than the shop: a farmers' market on Sunday, a stall at a festival, a hatch on a street with no fixed line. Those are exactly the places where connectivity fails, and a cloud till that stops selling when the signal drops is worse than a cash box.
Test it rather than trusting the marketing. Ask the vendor to put a device in airplane mode mid-sale, then keep selling, take a card payment, and reconnect. What you want to see: sales continue, card payments queue or process through the terminal's own connection, and everything syncs without duplicates when the signal returns. What you often see instead is a spinner.
The related question is whether a market stall reports as its own location, so that Sunday's takings, and Sunday's waste, do not get mixed in with the shop's. If you are running more than one outlet from one production kitchen, consolidated reporting by location stops being a nicety quite quickly.
What a bakery POS system costs
Prices move and vary by market, so treat these as bands to argue with rather than quotes. The point is the shape of the spend, which catches people out more often than the headline number.
Software runs roughly 50 to 200 per till per month, and the spread usually comes down to whether wholesale invoicing and production reporting are included or sold as modules. A second till is often cheaper than the first. Hardware for one counter position, meaning a screen, a cash drawer, a receipt printer and a card terminal, sits around 900 to 2,500 depending on whether you buy purpose-built kit or run the software on a tablet you already own. A trade-approved scale that integrates properly adds perhaps 400 to 1,200, and a label printer capable of ingredient labels another 250 to 700.
Then the recurring cost that dwarfs the subscription: card processing. At 1.3 to 2.9 percent plus a per-transaction fee, on a bakery's tiny average basket, the fixed pence per transaction hurts far more than the percentage. On a 3.50 sale, 20p of fixed fee is close to six percent. Anyone comparing providers on the percentage alone is looking at the wrong half of the pricing, which is why it pays to work out your own blended rate on your real basket size before choosing payment processing.
Budget for two things nobody quotes: the hours of somebody's time to build the product file properly with tax codes, allergens and recipes attached, and a fortnight of slightly slower service while staff learn it. Both are real costs, and pretending otherwise is why implementations get described as chaotic. Our breakdown of POS system cost goes through the same line items for a general hospitality setup.
Questions to ask a vendor before you sign
Salespeople say yes. The trick is asking things that cannot be answered with a yes, and insisting on seeing them done in a live system rather than a slide.
Ask them to take a cake order for three Saturdays' time with a 20 percent deposit, an inscription and a nut allergy, then show you where the baker sees it and how the balance settles on collection. Ask them to weigh something on an integrated scale and sell it by the kilo, with the bag tared off. Ask them to sell one sausage roll eaten in and one taken away and show the different tax on each without two separate products. Ask them to mark down six items at 4pm and bin four more, then produce a report that distinguishes the two with times attached. Ask them to invoice a wholesale account for a month of standing orders on a customer-specific price list, including one credit for returns. Ask them to put the device offline mid-transaction.
Two more worth asking. Who owns the data and how do you export it, in full, if you leave? And what happens to your sales history if you stop paying? A vendor that hesitates on either of those has told you something useful. If you are replacing an incumbent, the mechanics of getting out are covered in our guide to switching POS systems.
Where to start this week
Do not begin by booking demos. Begin by counting, because you cannot judge a system against requirements you have not written down.
Take one normal week. Record how many transactions you do in each hour, so you know where the peak actually is rather than where you think it is. Write down every forward order that came in and how it was captured. At the end of each day, weigh what goes in the bin, by product, and note the time you started reducing prices. Add up what wholesale was worth that week as a percentage of the total. If you have a seating area, count what share of sales were eaten in.
Five numbers, one week, and they will tell you which of the six demands at the top of this article actually apply to your bakery. A shop that is 90 percent counter trade with no cake orders needs a fast till and honest waste reporting, and nothing else on the list. A bakery where wholesale is 40 percent of revenue and Saturdays are all christening cakes needs something closer to a small ERP, and should stop looking at cafe software immediately. Same trade, same word on the door, two completely different purchases.
Read next: how to open a bakery for the startup costs and equipment decisions, inventory system for the stock side in more detail, and food cost percentage for the margin arithmetic underneath it all.
