Most explanations of this start with hardware, which is the least interesting part. A restaurant point of sale is really a chain of events that starts when a party sits down and ends when the money is in your account, and every problem you will ever have with one is a break somewhere in that chain.
Here is the chain, in order.
The table becomes an open check
A party is seated. Somebody assigns them to a table, and that creates an open check — a container that everything else attaches to.
This is the object the rest of the system hangs off. It knows the table, the party size, the server, and when it opened. That last field is what produces every turn-time report you will ever look at.
If a system does not model the table as a thing with state, it is a retail till that somebody has pointed at a restaurant. That distinction is the single biggest difference between a real restaurant POS and a general-purpose one.
Items go on the check
A server rings in a starter, two mains and a bottle of wine. Each item carries a price, a tax treatment, a course, and any modifiers — no onions, medium rare, oat milk.
Modifiers are where systems reveal themselves. A modifier has to be able to change the price sometimes and not others, be required sometimes and optional others, and print differently to the kitchen than it displays on the bill. A menu that cannot express "steak, medium rare, add prawns, no butter" cleanly will be worked around by staff typing things into a notes field, and anything in a notes field is invisible to every report you own.
The kitchen gets told
The moment items are sent, the kitchen needs to know. Traditionally on paper, increasingly on a screen.
What matters is not the medium but the routing: cold starters to one station, grill to another, desserts held until called. A system that prints the whole order to one printer makes the expediter's job a manual sort, every ticket, all night.
Coursing is the part that is usually configured badly. Sending everything at once and asking the kitchen to sort out timing works until you are busy, which is exactly when it stops working.
The check changes, repeatedly
Real service is not one clean order. Items get added. Someone changes their mind before it has been cooked, which is a void. Something arrives wrong and is not charged, which is a comp. A table splits into two. Two tables merge.
Voids and comps are worth understanding properly because they are the main way money leaves a restaurant without a sale. Both should require a reason and be attributable to whoever authorised them. We have written about comps and voids in detail — the short version is that a system which makes them frictionless and anonymous will be used to make mistakes disappear.
The bill is produced, possibly in pieces
Now the awkward part. Eight people, one check, and four of them want to pay separately. Two share a bottle of wine. One is paying for the table and the rest are buying their own drinks.
Splitting by item, splitting evenly, splitting unevenly, and moving items between checks are four different operations and a system needs all four. This is the function servers judge a POS on, because doing it badly at eleven at night in front of a waiting table is genuinely stressful.
Payment is taken and authorised
A card is tapped. The reader talks to the processor, the processor talks to the card network, an authorisation comes back, and the check is closed with a tender attached.
Two details people miss:
Authorisation is not settlement. The money is not yours yet. It moves when the batch settles, usually overnight, which is why a sale on Friday night appears in your bank on Tuesday.
Tips are added after authorisation. On a card the tip is adjusted before the batch closes. This is why an unclosed tip is a real problem rather than a cosmetic one, and why the end of the night has a step where somebody chases them.
The night is closed out
Sales are totalled, cash is counted against what the system expected, tips are allocated and tipped out, and the card batch is submitted.
The number that matters here is the variance — what the drawer holds versus what it should. A restaurant that never looks at that number does not know whether it has a counting problem or a theft problem.
Everything above becomes data
Once the night is closed, the same events are reports. Sales by item, by category, by server, by hour. Covers. Average check. Labour against sales. Void and comp totals by reason and by person.
This is the actual payoff of a POS, and it only works if the earlier steps were done properly. Items rung in as a generic "food" button produce a sales report that tells you nothing. Modifiers typed into notes produce a menu report with holes in it. The reports are only as honest as the ringing-in.
Where it usually breaks
- The menu. Built in a hurry, never revised, worked around by staff
- Kitchen routing. One printer doing four stations' work
- Comps and voids with no reason codes. So the money leaks invisibly
- Unclosed tips. Which means a batch that does not balance
- Nobody reading the reports. The most common failure of all
If you are evaluating systems, walk a whole check through each one — seat, ring, modify, course, split, tip, close. The differences show up in the middle of that sequence, not on the feature list.