POS software that runs on the phone already in your pocket

Search for POS software in Bangladesh and the first results sell you a machine. That is the shape of this market: the till is a box, the box costs money, and the software is what comes with the box. It is also the single largest cost of opening a counter, and it is optional.

The till here is a web application you install to the home screen from the browser. A staff phone or a cheap Android tablet is a working till and the camera is the scanner. There is no terminal to buy and no per-till hardware licence.

The market figures in that table come from Bangladeshi vendor and retailer listings rather than from a vendor's own rate card, because in this category the vendors do print numbers. They are the shape of the market rather than a quotation, and the pricing guide sets out where each came from.

Every POS vendor in this market claims offline mode and almost none of them explains it, so here is the whole of ours including the part that disqualifies us for some shops.

When the line drops mid-shift the till keeps ringing sales into a queue on the device itself, and drains that queue on reconnect. A sale that was already committed on the server before the connection died is recognised as the same sale and not charged twice, which is the failure mode that actually costs shops money.

The double-charge case is worth spelling out because it is the failure that actually costs money. If the till sends a sale and the connection dies before the answer comes back, the sale may or may not have committed on the server. A naive queue re-sends it and the customer is charged twice. Here the queued copy carries the same identity as the original, the server recognises it, and the sale lands once. The till also only falls back to offline when the server genuinely could not be reached, never when the server answered with a refusal, so a declined sale is shown to the cashier rather than quietly queued.

1. 01Before you roll out: get barcodes onto your catalogue. Without them, offline mode has nothing to sell. This is the single most common reason an offline claim disappoints in practice, and it is not a software problem.
2. 02Scan your fast-moving lines online on each device once, so their prices are cached where the till can reach them.
3. 03Know what offline cannot do: no bundles, no loyalty redemption and no product search. Barcode only. And the discount cap is server-side, so offline the till accepts an over-cap discount and the sale is rejected at drain.
4. 04Expect VAT to be recalculated on the server when the queue drains, not on the device.

One sale can be settled across several payments: part cash, part card, part mobile wallet. The till tracks the balance due and prefills the next tender. The tender list itself is operator configuration per outlet, not a fixed menu, so you can add the payment methods you actually take.

A till that does not reconcile is a till that quietly loses money. A cashier opens a shift with a counted float and closes it against a counted drawer, tender by tender, with denomination counts.

• /The expected cash figure nets off change given and refunds paid out of the drawer. A shift that took a return does not close false short, which matters because a number that is wrong in a predictable direction is a number everybody learns to ignore.
• /Closing outside the variance tolerance needs a manager's single-use approval rather than a manager's name typed into a box.
• /X reports during the shift and a daily Z report at the end come from the same figures the reconciliation used.
• /Cashier is a real role that opens and closes its own shift, rings sales, takes counter returns, and holds no approval key. Shift supervisor and store manager sit above it.

Completing a sale deducts the stock from the outlet's own warehouse inside the same transaction that completes the sale. Bundles deduct their components rather than the parent. If the stock move cannot be made, the sale does not quietly complete anyway. That sounds obvious and it is not: a till whose sales draw no stock is a surprisingly common defect, and the symptom is a stock figure that is always optimistic.

At the counter, BizRP allocates a gapless Mushak 6.3 number from an operator-configured series inside the transaction that completes the sale, so a sale cannot reach completed without one, a rollback returns the number rather than burning it, and a void keeps its number and is marked voided. Credit sales land in the same register carrying their sales invoice number from a separate sequence, not from that series, and cancelling a credit invoice does not currently mark its register rows voided. Every line of both channels lands with its taxable value, VAT rate and VAT amount, and the period exports as CSV in NBR column order. Two limits to know: supplementary duty is recorded as zero on every row today, so a business levying SD cannot rely on this register for it, and the buyer's BIN is captured at the counter but not yet on credit sales.

• Any phone is a tillShips today

  The till is a web app installed to the home screen from the browser, so a staff phone or a cheap Android tablet is a working till. There is no terminal to buy and no per-till hardware licence.

• Camera barcode scanningShips today

  The phone camera is the scanner. It uses the browser's native barcode detector where the device has one and falls back to a bundled decoder on iPhones, which do not. If the camera is refused, the counter falls back to typing the code rather than failing.

• Selling through a connection dropShips in part

  When the line drops mid-shift the till keeps ringing sales into a queue on the device itself, and drains that queue on reconnect. A sale that was already committed on the server before the connection died is recognised as the same sale and not charged twice, which is the failure mode that actually costs shops money.

  Where it stops. Offline selling is barcode-only, and the device can only sell items it has already scanned online at least once, because that is when it caches the price. There is no bulk pre-download of your catalogue yet. Offline you also cannot sell bundles or redeem loyalty points, and VAT is recalculated on the server when the queue drains rather than on the device. The discount cap is the one to watch: it is enforced by the server, so offline the till will accept a discount above the cashier's cap and the whole sale is then rejected when the queue drains, which is a conversation with the customer after they have left. If your products have no barcodes recorded, offline mode has nothing to sell.

• Split payment across tendersShips today

  One sale can be settled across several payments: part cash, part card, part mobile wallet. The till tracks the balance due and prefills the next tender. The tender list itself is operator configuration per outlet, not a fixed menu, so you can add the payment methods you actually take.

  Where it stops. A bKash or Nagad payment is recorded against the sale with its reference number typed in. The till does not initiate or verify the payment with the wallet. Live gateway integration with SSLCommerz and bKash exists on the online storefront checkout, not at the counter.

• Shift open, close and reconcileShips today

  A cashier opens a shift with a counted float and closes it against a counted drawer, tender by tender. The expected cash figure nets off change given and refunds paid out of the drawer, so a shift that took a return does not close false short. Closing outside the variance tolerance needs a manager's single-use approval, not just a manager's name. X and Z reports are produced from the same figures.

• Stock moves on the saleShips today

  Completing a sale deducts the stock from the outlet's own warehouse inside the same transaction that completes the sale. Bundles deduct their components rather than the parent. If the stock move fails, the sale does not quietly complete anyway.

• Returns and exchangesShips today

  Counter returns look up the original receipt, cap the quantity against what has already come back, restock the goods to the outlet and post the refund. An exchange deducts the stock for what the customer walks out with, and refuses the whole return if that stock move cannot be made rather than handing over goods it has not accounted for.

• Mushak 6.3 number at the counterShips today

  Every completed counter sale takes a Mushak 6.3 number from a series you configure, allocated inside the transaction that completes the sale, so a sale cannot complete without one. A rollback returns the number instead of burning it and a void keeps its number and is marked voided, so the register reads as an unbroken run.

  Where it stops. Sales completed before the numbering series was configured have no number, and none is invented for them retrospectively.

• Multi-branch and multi-tillShips today

  Tills belong to outlets, one open shift per cashier per outlet, each device identified separately. Concurrent tills are a plan ceiling rather than a per-seat charge, and the ceiling is enforced correctly when two tills open at the same moment.

  Where it stops. Concurrent tills are capped by plan. The entry plan runs one till at a time; unlimited tills is the top plan.

• Receipt printingShips in part

  Receipts render server-side and print to a thermal printer through a small print helper you install on the machine the printer is attached to.

  Where it stops. Thermal printing needs that helper installed. It is not driverless. There is no cash-drawer kick: the drawer in this product is an accounting concept, not a wired device.

• A real cashier roleShips today

  Cashier is a defined role that opens and closes its own shift, rings and completes sales, takes counter returns and redeems loyalty, and holds no approval key. Shift supervisor and store manager sit above it. Nobody has to trade on an administrator login.

A POS-only product can be excellent at being a POS. What it cannot be is the place your VAT registers come from, or the place your stock valuation lives, or the ledger your accountant closes the month in. So somebody exports, somebody imports, and the two systems disagree by an amount nobody can explain.

• /The sale deducts stock from the same inventory the purchase order filled.
• /The Mushak 6.3 register the counter feeds is the same register the VAT return figure is computed from.
• /The shift close posts into the same ledger the bank reconciliation runs against.
• /The product the till scanned is the same catalogue record the storefront sells.

That is the whole case for buying a till as part of a system rather than on its own, and it is worth exactly as much as the number of hours you currently spend moving data between two things.