Restaurant POS Software in Nepal: What a Café Actually Needs

A retail till records a sale at the moment money changes hands. A restaurant till has to track a customer’s entire visit — from sitting down, through several rounds of ordering, to a bill that might get split three ways an hour later.

That difference is why grocery billing software fitted to a restaurant always ends up with someone keeping a parallel notebook of which table ordered what.

Table state is the core object

In a restaurant, the thing the system tracks is not a bill. It is a table, and a table has a life: occupied, ordered, partially served, bill requested, settled, cleared.

Everything else follows from that:

• Orders are added to an open table over time, not entered all at once
• The kitchen needs to know about each round as it is placed, not at the end
• A bill is generated from the table’s accumulated orders when the customer asks
• Between “bill requested” and “settled” the table is still occupied and cannot be reseated

A system that models a restaurant order as a single retail transaction cannot represent any of this, so staff work around it — usually by holding the order in their head or on paper until the customer leaves, at which point the kitchen has been running on shouted instructions all evening.

Kitchen tickets are not receipts

When an order is placed, the kitchen needs a ticket. Not the whole bill — just the items it has to cook, in the order they were placed, with the table number and any modifications.

Practical requirements that get missed:

• Route by station. Drinks go to the bar, food to the kitchen, grills to the grill station. One order can produce several tickets.
• Only new items. A second round of orders should produce a ticket with only the new items, clearly marked as an addition to an existing table.
• Cancellations print too. If an item is voided after the ticket printed, the kitchen has to be told, on paper, or they will cook it.
• Modifiers are prominent. “No onion” is the difference between a served dish and a returned one. It cannot be small text at the end of a line.

Modifiers and variants

Retail items have a price. Restaurant items have a base and a set of choices: portion size, spice level, add-ons that cost extra, substitutions that do not, and instructions that are free text.

The system needs modifiers as structured data — a set of options attached to an item, some of which change the price — rather than as a comment field. Once modifiers are structured, two useful things follow: the kitchen ticket is unambiguous, and you can report on which add-ons actually sell.

Splitting and merging bills

Groups split bills. The system has to handle:

• Splitting by item — each person pays for what they ordered
• Splitting evenly by headcount
• Splitting across payment methods, where one person pays cash and another by card or wallet
• Merging tables when a group grows and takes over the next table

Splitting is the single most common reason restaurant staff abandon a POS. If it takes five taps and a calculator, they will do it on paper and enter one lump sum, and your item-level sales data becomes fiction.

Shift-wise cash, not day-wise

Restaurants run shifts, and cash accountability has to follow the shift, not the calendar day. A shift opens with a float, takes cash, card and wallet payments, has voids and discounts, and closes with a count.

The close should be a proper reconciliation: expected cash from the system, counted cash entered by the person closing, variance recorded with a reason. Not a report someone reads and nods at.

Two numbers worth watching closely because they are where losses hide: voids after the kitchen ticket printed, and discounts applied without a manager code. Both are legitimate operations that are also the two easiest ways to remove money from a restaurant.

Menu costing, if you want to know what makes money

Most restaurants in Nepal price by feel and competitor comparison. If the POS is connected to a recipe and stock, it can do better: each dish consumes defined quantities of raw material, so the system knows gross margin per dish and can rank the menu by contribution rather than by popularity.

The results are usually uncomfortable and useful — the best-selling item is frequently not the most profitable one, and there is often something on the menu losing money on every sale.

This requires recipe setup, which is real work. It is worth doing for the top twenty items and skipping for the rest.

Offline is not optional

A restaurant at peak service cannot pause because the ISP is having a problem. Billing, kitchen tickets and table state all have to run on the local machine, with the cloud copy catching up afterwards. We wrote about how that works in offline POS software in Nepal.

Before you buy

Watch a demo of these specifically, in this order:

1. Open a table, order, fire to kitchen, add a second round, split the bill three ways, settle two by cash and one by wallet
2. Void an item after the kitchen ticket printed
3. Close a shift with a deliberate cash variance
4. Unplug the network and repeat step one

If the demo survives all four, it is a restaurant POS. If it survives the first three but not the fourth, it is a restaurant POS for somewhere with better internet.

We build accounting, inventory and operations software for food businesses in Nepal with table management, kitchen routing and offline billing. If your service depends on a notebook, talk to us.