A restaurant POS is not a retail POS with a different theme. The workflow on the floor of a casual dining restaurant in Karachi or a quick-service outlet in Lahore looks nothing like a clothing store’s checkout counter, and the software you choose has to reflect that. If your evaluation shortlist is full of “general retail POS” products that happen to have a table feature bolted on, you are almost certainly going to regret the purchase within the first quarter.
This guide is the long-form, vendor-neutral buyer’s checklist we wish every restaurant operator had before they signed a 12-month contract. It covers the seven workflows that matter most — table layout, KOT routing, modifiers, allergy tracking, split bills, online-ordering integration with Foodpanda/Careem/Uber Eats, and inventory and recipe costing — and explains, for each, the questions to ask a vendor, the demos to insist on, and the trap clauses to refuse. Read it once before you book a single demo. Use it as a scoring sheet during the demos. Keep it open during contract review.
What Makes Restaurant POS Different
Restaurant POS has to solve four problems retail POS never sees:
- The order and the bill are separated in time. A retail customer scans, pays, walks out. A restaurant customer orders, the kitchen cooks, the customer eats, then pays — sometimes 90 minutes later, sometimes across multiple courses, sometimes split four ways.
- The product is not in stock — it is made. The POS has to convert a menu item (“Chicken Tikka Pizza, Large”) into the raw ingredients that come off inventory (160g chicken, 220g dough, 80g cheese, 30ml tikka sauce) every single time. Get the recipe wrong and your food cost reports lie.
- The order routes to multiple stations simultaneously. A single ticket might need to print a hot-line KOT in the kitchen, a cold-line KOT at the salad station, and a beverage docket at the bar, with different items on each printout — and the bill must still come out as one consolidated check.
- The customer can be in three places at once. Dine-in, takeaway, and three different delivery aggregators (Foodpanda, Careem Food, Uber Eats — and increasingly direct WhatsApp orders) all hit the same kitchen. Without a POS that consolidates these streams, the kitchen ends up working from four different screens and the inventory drifts inside a week.
These four realities define the entire feature checklist below. Any restaurant POS that does not handle all four cleanly is the wrong tool for the job, regardless of how nice the front-of-house screen looks in the demo.
The 10-Point Restaurant POS Buyer’s Checklist
Before any demo, score each candidate POS on these ten capabilities. A score of 7 or below should rule the vendor out for any restaurant doing more than 200 covers a day.
| # | Capability | Why it matters | Pass / Fail |
|---|---|---|---|
| 1 | Visual table-layout editor with seat-level ordering | Servers must see the floor, not navigate menus | Drag-and-drop, supports merging tables |
| 2 | Multi-station KOT routing with course-level firing | One ticket → multiple kitchens, in the right order | Hot/cold/bar routing + fire-on-demand |
| 3 | Modifier groups (forced + optional + multi-select) | Pizza toppings, doneness, no-onion exceptions | Nested modifiers, price deltas per option |
| 4 | Allergen tagging on menu items | Legal and reputational risk for any restaurant | Allergens propagate to KOT printout |
| 5 | Split bills (by item, by seat, by share) | Customers will demand all three | All three modes, ability to merge back |
| 6 | Online-ordering integration with Foodpanda, Careem, Uber Eats | Aggregator orders fed into KOT, not re-keyed | Native integration, not “API available” |
| 7 | Recipe / BOM costing tied to inventory | Track theoretical vs actual food cost | Per-item recipes, automatic depletion |
| 8 | Tab / running-bill management | Bar, lounge, hotel restaurants need open tabs | Pre-authorise, append, settle later |
| 9 | Offline mode with auto-sync | The internet will fail on a Friday night | Full order entry offline, syncs on reconnect |
| 10 | Daily-close / Z-report with cash drawer reconciliation | Without it, theft is invisible | Per-cashier, per-shift, with variance flags |
Any vendor who needs a follow-up call to confirm whether feature 1 or 2 exists has lost the round. Live demo or no contract.
Table Management and Floor Layout
The single biggest difference between a restaurant POS and a retail POS is the floor map. In a good restaurant POS, when your server taps the screen, they see your actual floor — booths along one wall, four-tops in the middle, the patio extension off to one side — and each table is a button with state colour-coded into it:
- Grey — empty, available.
- Blue — seated, ordered, food not yet served.
- Amber — food served, waiting on dessert or bill request.
- Red — bill requested but unpaid, server attention needed.
- Striped — reserved (with the customer name visible on hover).
The colour states matter because a captain walking the floor on a Friday at 9 pm cannot read text. They scan for red. The POS exists to make the floor legible.
What to test in the demo
Ask the vendor to do the following on a live demo, not slides:
- Build the floor. Drag-and-drop tables of different shapes (round, square, banquet), label them, assign capacity per table. Time it. If it takes longer than fifteen minutes to lay out twenty tables, the editor is too primitive.
- Seat a party of six on a four-top with a chair added. The system should let the captain bump the capacity of that table for the evening without rebuilding the floor.
- Merge two four-tops into an eight-top for a walk-in family. Test that the bill on the merged table consolidates correctly and that the un-merge later returns everything to the right state.
- Transfer a single seat to another table — the family that arrived together but now one couple wants to move to a quieter corner. The single-seat transfer is the one that catches weak software out.
- Show seat-level orders. Each chair around the table should be an “ownership” slot so that when the bill is split, the system knows seat 3 ordered the steak and seat 4 ordered the salad — no manual re-entry.
If the POS forces every order onto “the table” rather than “the seat,” budget for a frustrating split-bill workflow for the rest of the contract.
KOT (Kitchen Order Ticket) Flow
The KOT is the bridge between the dining room and the kitchen, and it is where most cheap POS systems collapse. There are five things a good KOT system has to do:
1. Route by item, not by ticket
Every menu item has a station property: hot line, cold line, bar, dessert, tandoor, grill. When the server fires the order, the POS does not print one ticket — it prints (or screens-up on a KDS) several, each at the right station, with only the items relevant to that station on the printout. The customer’s beverage prints at the bar, the salad at the cold line, the steak at the grill. Each station works in parallel.
A POS without per-item station routing forces every ticket to print everywhere, which means the salad guy is reading a printout that mostly does not concern him. He misses the salad. The chits pile up. The kitchen drifts.
2. Fire course by course
A captain should be able to fire courses sequentially: starters first, then a “fire mains” command when the table is ready, then a “fire dessert” command. The POS holds the un-fired course rather than blasting all three to the kitchen at the same time.
Good systems also let the captain edit a held course (the table changed its mind about dessert) without re-entering the entire ticket.
3. Show modifications prominently
When the customer says “no onions, extra cheese, well done,” the kitchen needs that information first, in bold, on the chit — not buried at the bottom in 8pt italic. Look at the KOT printout in the demo. If the modifier line is the same size as the item line, the kitchen will miss it under pressure.
4. Flag allergens at the kitchen, not just on the screen
If your menu has an allergen-flagged item and a customer with a recorded allergy ordered it, the KOT printout has to scream — bold red header, capitalised allergen name, ideally a printed stop-line that says “ALLERGY: NUT” at the top of the chit. The chef should not be relying on the captain to remember to mention it verbally.
5. Acknowledge back to front-of-house
When the kitchen fires the dish, the line cook hits “ready” on the KDS or rings a buzzer. The captain’s screen at the pass turns green for that item. This is the loop that prevents food sitting under heat lamps for ten minutes because no one knew it was up.
Almost every Pakistani restaurant POS does (1) and (2) reasonably well. Most fail (3), (4), and (5). Insist on a live demo with a real KOT printer or KDS screen — not screenshots.
Modifier Groups and Allergy Tracking
Restaurant menus are deceptively complex. A pizza menu with twelve items might actually be 12,000+ orderable combinations once you include size, crust, toppings, sauce variations, and “make it a meal” upsells. The modifier engine is what manages that explosion without bloating the menu.
What a competent modifier engine looks like
- Forced single-select — the customer must pick one (Pizza Size: 9-inch, 12-inch, 15-inch).
- Forced multi-select with min/max — must pick at least one but no more than three (Pizza Toppings: choose up to three from list).
- Optional add-ons with price deltas — extra cheese +150, jalapenos +60, no-onion +0.
- Negative modifiers that print but do not charge — “no onion,” “no mayo,” “cut into eight” — these go on the KOT but never appear on the bill.
- Nested modifiers — once the customer picks “Steak,” a second tier opens up for doneness (rare/medium/well) and side (fries/salad/mash). The second tier should not appear for other items.
The trap to avoid: a modifier system that only supports flat lists. You will end up with a 400-item menu just to capture pizza variations, and your reporting will be unreadable.
Allergen tagging
Allergens are not a marketing feature — they are a liability layer. Every menu item should carry tags from a controlled vocabulary (gluten, dairy, peanut, tree-nut, soy, egg, shellfish, sesame, sulphites, mustard). Two things must follow from a tagged item:
- On the front-of-house screen, allergen icons appear next to the item name when ordering, with a colour-coded warning if the table profile contains a recorded allergy.
- On the KOT, the allergen prints in a stop-line at the top of the chit so the chef cannot miss it.
If the POS lets you enter allergens but does not propagate them to the KOT, the feature is decorative. It does not protect the restaurant from the consequences of a missed warning. Reject any vendor whose demo cannot produce a sample KOT with an allergen stop-line on it.
Split Bills — All Three Modes
The single most common complaint about a bad restaurant POS is split-bill failure. Customers will ask for one of three things, and any restaurant POS worth buying handles all three with two taps:
- Even split. “Just divide the bill by four.” Trivial — every POS handles this.
- Split by item. “I had the steak and the wine, my friend had the salad — I’ll pay for mine.” The POS needs to let the server tap which items move onto bill A and which stay on bill B. Seat-level ordering (from the table-layout section above) makes this almost automatic; without it, the server is mentally tracking who ate what.
- Split by share. “We had a starter and dessert to share — divide those by four, but everyone pays for their own main.” This is the hardest. The POS has to flag shared items, evenly distribute them across selected payers, and then add the per-payer items on top. Half the systems in the market cannot do this without manual arithmetic.
Test all three in the demo. Then test the merge-back — “actually, just put it all on one bill” — and confirm the system handles the rollback without a 404.
Online Ordering Integration: Foodpanda, Careem, Uber Eats
This is the integration that separates 2026-era restaurant POS from 2018-era restaurant POS, and it is the single most important question to ask a vendor in Pakistan right now.
Aggregator orders represent 25-60% of revenue for most urban restaurants in Pakistan in 2026. If those orders arrive on a separate tablet — one per aggregator — they are functionally invisible to your POS. The kitchen has to re-key them. Inventory does not deplete. Reporting is broken. Staff make data-entry mistakes on every fourth order during peak.
A properly integrated restaurant POS pulls orders from each aggregator’s order-management API directly into the same KOT queue as dine-in and takeaway orders. The kitchen sees one queue. Inventory depletes automatically. The aggregator order shows up in your sales reports tagged by channel.
The questions to ask
- “Is the integration native or do I need a middleware?” Native means the POS vendor wrote and maintains the connector. Middleware (Deliverect, Otter, Chowly) is a separate paid layer — useful but adds 4,000-12,000 PKR/month and a second point of failure.
- “Can I edit my menu in one place and have it sync to all three platforms?” If the answer is “you have to edit each aggregator dashboard separately,” you will end up with price drift within a week and never reconcile it. Single-source menu management is non-negotiable.
- “What happens when an aggregator order arrives during a planned 86 (item sold out)?” A competent POS will auto-mark the item unavailable on every aggregator the moment the cook hits “86” on the KDS, preventing a refund-and-apology spiral.
- “Can I accept or reject aggregator orders from the same screen?” No more “tablet aside” — the captain accepts a Foodpanda order from the same screen where they take a walk-in order.
- “How do you handle aggregator order modifiers?” Foodpanda and Careem Food both let customers add notes (“less spicy,” “no onion”) that have to flow through to the KOT. Verify on a live test order, not a screenshot.
Margin reality on aggregator orders
While we are here: aggregator commissions in Pakistan run 22-35% on the food bill. If your dine-in dish costs PKR 800 and your food cost is PKR 280 (35%), you make PKR 520 of contribution. Sell the same dish through Foodpanda at PKR 800 minus 27% commission (PKR 216) and your contribution drops to PKR 304 — a 41% hit. A POS that does not let you set per-channel pricing (so the Foodpanda price can be PKR 950 to absorb commission) is costing you margin you cannot recover.
Inventory and Recipe Costing
This is where most operators discover, six months in, whether they bought a “POS” or a “restaurant management system.” The difference is recipe costing.
A real restaurant POS treats every menu item as a recipe (sometimes called a BOM — bill of materials). The Chicken Tikka Pizza is not “one unit” — it is 160g of chicken, 220g of dough, 80g of mozzarella, 30ml of tikka sauce, 12g of capsicum, and 20g of mixed peppers. When the customer orders one, every one of those raw inventory items depletes by the recipe quantity.
The output is theoretical inventory and theoretical food cost. The reconciliation, every week, with the physical stock count, is where you find the leaks — over-portioning, waste, or theft.
Without recipe-level inventory, you have a sales report and nothing else. You will not know whether your kitchen is bleeding 8% of food cost into the dustbin or into staff lunches or out the back door.
What to verify
- Multi-level recipes (a “house sauce” is a sub-recipe that several dishes use — change the sub-recipe once and every parent dish updates).
- Per-portion yields (one kilo of cooked chicken yields about 700g usable — the POS has to track yield, not just raw weight).
- Wastage logging (a separate “waste” entry that depletes inventory without depleting sales).
- Recipe versioning (you change the burger recipe in March; the system should let you reprice all March-onwards costs without rewriting February’s history).
Hardware: What You Actually Need
Restaurant POS hardware shopping is straightforward if you ignore vendor markup and buy off the open market:
| Hardware | Purpose | 2026 PKR range |
|---|---|---|
| Touchscreen POS terminal (15.6″) | Front-of-house order entry | 65,000 – 130,000 |
| Thermal receipt printer (80mm) | Customer receipts | 8,000 – 14,000 |
| Thermal KOT printer (80mm, kitchen-rated) | Heat-resistant unit for kitchen | 12,000 – 20,000 |
| Kitchen Display System (KDS) screen | Replace paper KOT, faster | 35,000 – 70,000 |
| Cash drawer (heavy-duty) | RJ11 trigger from receipt printer | 6,500 – 11,000 |
| Customer-facing display | Show order + price (now QR-pay enabled) | 9,000 – 18,000 |
| WiFi router + UPS | Five hours of battery for the POS only | 25,000 – 45,000 total |
Avoid: vendor-locked terminals that only run the vendor’s software. Standard Windows or Android touchscreen units are cheaper, repairable, and re-saleable.
Pricing Models and What to Negotiate
Restaurant POS pricing in Pakistan in 2026 sits in three bands:
- Entry / single outlet, basic features: PKR 3,500 – 8,000 / month, one to three terminals.
- Mid-tier with aggregator integration + recipes: PKR 8,000 – 18,000 / month, unlimited terminals at one outlet.
- Multi-branch / chain pricing: PKR 15,000 – 40,000 / month per branch, with central menu and consolidated reporting.
What to negotiate
- Free first month for setup and menu loading. Reasonable ask — vendor staff are loading the menu anyway.
- Locked rate for 24 months. Vendor lock-in cuts both ways — make the rate honour that.
- Free aggregator-integration setup. Saves PKR 15,000-30,000 typical setup fees.
- One free hardware swap per year. Thermal printers fail; cover one replacement.
- Source-data export clause. When (not if) you switch vendors, you get your full transaction history in CSV — not a screenshot.
Refuse: any pricing structured per-transaction-percentage. You are buying software, not a payment processor. If the vendor wants a percentage of your sales they are pricing for upside you do not owe them.
Frequently Asked Questions
How long does it take to roll out a restaurant POS? Single outlet, clean menu, no aggregator integration: 3-5 days end-to-end. Add aggregator sync: 7-10 days. Multi-branch with central menu: 3-4 weeks per branch in the first phase, then 5-7 days each thereafter.
Can I run a restaurant POS on iPad? Yes. The trade-off is durability and screen size. iPads work well for QSR and counter-service formats; for high-volume table-service kitchens, a fixed Windows or Android terminal at the captain’s station with iPads for floor servers is the most common 2026 configuration.
Do I need a separate KDS or are KOT printers fine? KDS is faster, quieter, paperless and lets the kitchen acknowledge orders back to the floor. For volumes above 200 covers a day, KDS pays for itself in a quarter. Below that, paper KOT is still fine.
What happens to my orders if the internet goes down? A properly built cloud POS keeps a local offline cache. Orders queue locally; they sync to the cloud the moment the connection returns. Anything that requires a live internet connection to take an order is unfit for purpose in Pakistan.
Can I integrate the POS with my accounting software? Yes — and you should. Daily sales totals, taxes collected, and tip pools should auto-post to your accounting ledger (QuickBooks, Xero, or a Pakistan-localised ERP like EloERP Suite) every night. Anything done manually will drift inside two months.
How do I get out of a contract if the POS does not work? The contract clause to insist on is Data Portability on Termination: within 14 days of termination, the vendor provides a full export of menu, recipes, customers, transaction history, and inventory snapshots in CSV. Without this clause, your data is hostage to the vendor’s renewal terms.
Final Recommendation
Restaurant POS is one of the few software categories where the cost of getting it wrong shows up daily and compounds. A bad table-layout decision slows every shift. A weak modifier engine forces double-keying. A missing aggregator integration drains margin. An absent recipe-costing module hides theft.
If you are buying for a single outlet, prioritise (in this order): table layout, KOT routing, modifiers, split bills, aggregator integration. Recipe costing and multi-branch features can be deferred to year two if the budget is tight.
If you are buying for a multi-outlet chain, recipe costing and centralised menu management move to the top of the list — chains hemorrhage margin invisibly without them.
Either way, treat the demo as the contract. Insist on live tests of every checklist item before you sign. Walk away from any vendor that needs a “follow-up call” to confirm whether a basic capability exists. The good systems show you, the weak ones promise you.
Want a hands-on walkthrough of a restaurant POS that handles all ten checklist items natively? Book a 30-minute demo with the EloERP Suite team — bring this checklist, score us live.