A restaurant or a shop runs on a till, and the till is usually the one system that does not talk to anything. Sales happen there all day, in cash and on cards, against stock nobody is counting in real time, and at some point in the evening a number gets carried across to the accounts — by export, by spreadsheet, or by somebody typing a day's total into a journal.
That carry-across is where the trouble lives. Not because the till is wrong, but because between the sale and the ledger there is a gap, and everything that matters to a food or retail business hides in it: what the food cost actually was, which items make money, whether the cash in the drawer matches the sales, where the wastage went.
This is about what it changes when the till is a module of the business system rather than a separate product that reports to it.
Three things the gap costs you
You cannot cost a dish or an item properly
A sale at the till moves stock. If that movement is not recorded against the same ledger as your purchases, then food cost or cost of goods is something you calculate monthly from a purchase total and a closing count — which gives you one number for everything and tells you nothing about which items are carrying the business and which are quietly losing money on every order.
Cash reconciliation becomes a daily argument
Drawer counted, sales totalled, the two disagree by a few hundred rupees. Without per-sale records posted as they happen, there is no way to find the discrepancy, so it gets written off. Written off daily, it becomes a real number nobody has ever added up.
Your busiest hours are invisible to purchasing
The till knows what sold at eight on Saturday. Purchasing works from a stock sheet updated on Monday. The information that would make ordering accurate exists and never arrives where the decision is made.
What “the till is a module” actually means
The claim worth testing is specific. Not that the POS integrates with your accounting, but that a sale at the till writes to the same movement ledger as a goods receipt, and posts its own accounting entry, with no export and no nightly job in between.
In Orbis the point of sale sits on the same record engine as inventory, purchase and accounts, alongside tables, a kitchen display, QR ordering and a kiosk. The consequence is the ordinary one: stock moves when the sale happens, the entry is posted when the sale happens, and the day's figures are not a thing anybody assembles.
For a restaurant specifically, that chain reaches further than the till. An order taken at a table or scanned from a QR code appears on the kitchen display, moves stock when it is served, and posts when it is paid. The diner with a QR code is a distinct kind of identity in the system with its own routes rather than a guest login with a flag on it — which matters the first time you think about what a stranger's phone can reach.
The offline question, which is the real one
Every POS vendor will tell you their system works offline. The question that distinguishes them is what happens on the way back.
Here is the failure that costs money. The network drops. The till keeps taking sales into a local queue. The connection returns, the queue uploads, and a sale that was already recorded during a partial reconnect goes up a second time. Now the day's takings are overstated, stock is understated, and somebody spends an evening finding out which of two near-identical records is the duplicate.
The design that prevents it is unglamorous: the sale's reference is minted at the till, before the money is taken, so the record has an identity of its own from the start and a retry cannot create a second one. Orbis works that way, and it is the thing worth asking any POS vendor to explain in those terms. “It syncs when it reconnects” is not an answer to the question.
Two more edge cases worth raising, because they are where real tills get awkward:
- What happens when an offline sale turns out to have oversold the stock? Refusing it after the customer has paid is not an option. Orbis accepts the oversell and surfaces it rather than refusing it, which is the honest behaviour — the sale happened, and the stock figure should say so.
- Can a sale be refused for want of a network at all? If the answer is anything other than no, you have a system that occasionally stops your business for reasons your customer will not accept.
What to test before you buy a POS
Do this on the actual hardware, in the shop, not on a laptop in a meeting. An afternoon of it is worth more than every demo.
- Make a sale, then immediately look at the stock figure for that item and the accounting entry. Both should already be there, with no sync to wait for.
- Pull the network cable. Take five sales. Plug it back in halfway through the sixth. Count what arrives — this is the test most systems fail, and it fails quietly.
- Sell something you do not have. Watch whether the system refuses the customer, accepts and flags it, or silently lets stock go negative with no record of why.
- Run a split bill, a part payment and a refund. These three expose more about a POS than the entire sales flow.
- Close the day. Count how many steps stand between the drawer count and a posted set of accounts, and how many of them involve a spreadsheet.
- For a restaurant: change an order after it has reached the kitchen display, and watch what the kitchen sees.
The part that is usually oversold
Loyalty, vouchers, memberships and campaigns are genuinely useful and they are also the easiest thing for a vendor to make sound transformative. The honest framing: they are worth having when they sit on the same customer record as the sales, because then a voucher redemption is visible against the margin it affected and a campaign can be judged against what it actually sold.
Bolted on as a separate product, they generate activity you cannot connect to revenue, which feels like marketing and is closer to spending. In Orbis loyalty points, packages, vouchers, memberships, a wallet and SMS and WhatsApp campaigns are a module on the same engine as sales, which is the arrangement that makes them measurable. Whether you need them in month one is a different question, and usually the answer is no — get the till and the ledger joined up first.
Start with one thing
If you take one point from this: the question to ask a POS vendor is not what the till can do. Every till can take a sale. The question is what has already happened to your stock and your ledger one second after the sale, and what happens to the day's takings when the network comes back.
If you would like to see those two answered on real hardware with your own menu or product list, book a walkthrough. Bring your worst reconciliation day and we will run it through.
Frequently asked questions
Does a POS need to be part of the ERP, or can it just integrate?
It can integrate, and the cost of that choice is specific: between the sale and the ledger there is a gap, and item-level costing, cash reconciliation and demand information all hide in it. The test is what has happened one second after a sale — if your stock figure and your accounting entry are both already correct, it is genuinely one system. If something syncs, exports, or runs nightly, you will be reconciling daily.
What should a POS do when the internet drops?
Never refuse a sale, and never double-count on the way back. The second half is the one to probe. Ask how the sale's reference is created: if it is minted at the till before the money is taken, the record has its own identity and a partial reconnect cannot produce two copies. “It syncs when it reconnects” does not answer the question — that is precisely the condition under which duplicates appear.
Can one system run a restaurant and a retail counter?
Yes, if the restaurant-specific parts are modules rather than a different product. What a restaurant needs on top of a till is table management, a kitchen display, and usually QR ordering; retail needs none of those and should not pay for them. On a platform where modules are sold and switched on individually, the same engine serves both and each business sees only what it bought.
How do we handle an offline sale that oversold stock?
Accept it and surface it. The sale has happened and the customer has paid, so refusing it retrospectively is not available, and letting stock go quietly negative with no record is worse — it destroys the one figure you needed. The right behaviour is to record the movement, let the on-hand figure reflect reality, and flag the oversell for someone to look at. Ask any vendor to show you this case specifically; it is revealing.
Is loyalty and WhatsApp marketing worth it for a small outlet?
It is worth it when it sits on the same customer record as the sales, because then a voucher redemption is visible against the margin it affected and a campaign can be judged against what it sold. Bolted on separately it produces activity you cannot connect to revenue. It is also rarely the first thing to buy — joining the till to the ledger changes more, and it changes it in month one.
