A restaurant runs on two evenings. The first ends when the last table leaves and the cashier counts the till. The second happens later, when someone copies the day's sales into the accounts and tries to explain why the cash, the kitchen and the report do not quite match. Most owners only ever see the second evening's version.
The counter problem nobody solves with a better billing machine
The usual response is a faster billing system. That speeds up the counter but leaves the real gaps where they were:
- The kitchen works from shouted orders. A note from the guest is lost between the table and the stove.
- The till is short, and nobody knows why. The difference is absorbed at day end instead of recorded.
- Discounts have no rule. Coupons and happy hours show up as one unexplained number in the report.
- Stock moves by menu item, not by ingredient. The kitchen's real consumption is a monthly guess.
- Sales reach the accounts by export. POS revenue is in the books only after someone imports it.
The gap is not speed. It is that the till, the kitchen, the stock and the books are four separate records.
What changes when the counter is part of the books
The shift starts with a name and a float
A cashier session opens on a terminal with an opening float, against a named cashier. Everything billed in that shift belongs to that session, so the count at the end has something exact to compare with.
The order reaches the kitchen with its notes
An order taken at a table appears on the kitchen display as a KOT, with the notes the guest gave. Tables can be merged, shifted or split, and the running bill follows. The menu, the till and the kitchen read the same rows, including the QR menu a guest opens on their phone.
The bill moves stock by recipe
The bill carries the GST breakup from the tax master and the HSN on the item, and payment is split by mode — cash, card, UPI or wallet. When a dish is sold, its recipe consumes the ingredients from stock, not just the menu item. Retail counters work the same way, with variants for sizes and portions.
Day close records the difference
At day close, cash is counted against the system figure and the difference is recorded, not absorbed. Sales, tax, settlement by mode and the cash book then post to the ledger for the business date, exactly as counted.
What this looks like in practice
Consider a restaurant group with three outlets, each with its own counters, printers and menu.
At one outlet, table 7 orders two dishes, one with "less spice". The KOT reaches the kitchen display with the note. The bill is raised with GST and settled partly by UPI and partly by card. The sale reduces the ingredients by recipe. At 11 pm, the cashier closes the session:
- The counted cash is ₹340 short of the system figure.
- The difference is recorded against that session and that cashier.
- The day's sales, tax and payment modes post to the ledger.
The owner sees the short till the same night, not at month end. Over a week, the gap between recipe-based consumption and the physical count of ingredients gives the kitchen its first honest wastage figure.
Nothing here makes the kitchen cook faster. What it does is stop the loss between the till and the books — which is where most restaurant margin quietly disappears.
Promotions and loyalty that finance can still read
Coupons, offers and happy hours are set up with their own rules and validity, and loyalty points are earned and redeemed on rules you set per outlet. Customer discount categories cover staff, institutions and regulars. Because every discount has a rule behind it, the day-end report shows a line with a reason, not a mystery number. Refunds carry a recorded reason too.
Where this meets the rest of the business
A counter bill is still a GST document, and it touches every other record.
- Accounts: POS revenue, taxes and receipts are in the trial balance as they happen.
- Stock: ingredients and retail items leave stock on the bill, with the batch where it is tracked.
- Customers: khata-style running balances cover regulars who settle weekly or monthly.
- Multiple outlets: each outlet has its own users, printers, menus and promotions, and the reporting rolls up to one set of books.
That is the practical argument for the POS sitting inside the same system as stock and accounts rather than beside them.
A note on connection and devices
The POS needs an internet connection today. Offline billing is on the roadmap, and we would rather you knew that now than during a power cut. A mobile POS is also on the roadmap. Today, the POS runs on the web app and the desktop app for Windows, macOS and Linux, where USB and thermal printers are driven through the Unnati print agent. A wired connection with a local printer is the most stable setup.
Unnati's POS module covers outlets, counters, cashier sessions, KOT and kitchen display, tables, menu, recipes, variants, promotions, loyalty and day-end reports. The POS feature page shows the screens, and the catalogue and menu page covers the published QR menu.
Key takeaways
- A till that does not post to the books creates a second evening of work.
- Every cashier session needs a named cashier, an opening float and a counted close.
- A short till should be recorded the same night, not absorbed.
- Selling a dish should reduce its ingredients by recipe, not only the menu item.
- Every discount should have a rule behind it that the day-end report can show.
- The POS needs a connection today; offline billing and mobile POS are on the roadmap.