Billing software is chosen in a quiet room, with a salesperson demonstrating a clean transaction on good internet, and judged eighteen months later at seven in the evening with a queue and a customer who wants half the order returned.
The gap between those two conditions is where almost every real complaint about point-of-sale software originates. It is rarely about features. It is about what the system does when conditions are worse than the demo assumed — and the specific ways it slows down, blocks, or forces a workaround that quietly corrupts the record.
Speed is a feature, and it is measured in keystrokes
The number that matters is not how fast the software runs. It is how many actions a staff member performs to complete a normal sale.
Count them for your busiest transaction type. Every additional step is multiplied by the number of transactions per day and by the pressure of the queue. A billing flow requiring nine interactions instead of five does not cost four keystrokes — it costs four keystrokes several hundred times a day, performed by someone being watched by waiting customers.
This is also why systems get bypassed. When the official route is slow, staff find a faster one — a manual bill, a note to enter later, a "same as last time" shortcut. Every bypass produces a record that is incomplete, and the stock variance that follows is attributed to counting rather than to the interface.
Where the keystrokes actually go
Common and avoidable:
- Searching for items by scrolling rather than by code, barcode or short name
- Mandatory fields nobody needs on a routine sale — customer details on a cash purchase
- Confirmation dialogs on actions that are never accidental
- Re-entering the customer for a regular who buys weekly
- Switching screens to check stock or price mid-transaction
Each is defensible in isolation. Together they decide whether the system is used as designed.
Offline behaviour is not an edge case
Connectivity fails. Not rarely — routinely, and usually at the worst moment, because peak trading and network congestion often coincide.
What the system does then is a first-order requirement, not a footnote:
Does billing continue? If the answer is no, the business stops or reverts to manual bills. Manual bills are the single largest source of unrecorded sales.
Does it reconcile automatically? Transactions made offline must sync when connectivity returns, without someone re-keying them. Re-keying is where the errors enter.
Is the operator told which state they are in? Staff need to know whether they are online. A system that fails silently produces confident behaviour on stale data — a price or stock figure that is no longer current.
Ask about offline behaviour before anything else. It is the question that most reliably distinguishes software built for real counters from software built for demos.
The transactions nobody demonstrates
Demos show a clean sale. Operations are full of the other kind, and these are what generate the workarounds.
Partial returns. Three items bought, one returned, against a bill that had a discount applied to the total. How is the discount apportioned? If the system cannot do this, staff will improvise, and the numbers will not reconcile.
Split payment. Part cash, part card, part credit against an account. Common in almost every sector and frequently handled badly.
Price override. A manager authorises a reduction. Is it recorded as an override with a reason, or does it silently alter the line? This is exactly the price and discount drift that erodes margin invisibly.
Held and resumed sales. A customer steps away mid-transaction while others are served.
Items sold by weight or measure, where the quantity is not an integer and conversions apply.
Exchange rather than return. Two transactions or one, and what the record shows.
Ask a vendor to demonstrate these, not the clean sale. The answers are more diagnostic than any feature list.
What billing has to be connected to
A till that only records money is a cash register with a screen.
The transaction is the moment nearly everything else in the operation should update: stock decrements, the customer's history and balance change, the ledger moves, and the day's position shifts. If those are separate systems, someone performs the connection manually — which is the reconciliation burden described in what a business operating system actually is.
The practical test: after a sale, how many other things need updating by a person? If the answer is more than zero, the counter is generating work for someone else in the business.
Closing the day
The daily close is the most underrated part of billing software.
A good close reconciles expected cash against counted cash, surfaces the variance immediately, accounts for every non-cash tender, and produces a figure the business can act on before tomorrow begins.
A bad close is a report someone prints and files. The difference is whether a discrepancy gets investigated while anyone still remembers the day.
Our position is that every day must close clean — that operational health is measured by how quickly the day settles and how fast a problem becomes visible. It is one of three principles that shape what we ship, described in how Truffaire builds software.
What we have seen
Billing sits in most of the ten systems we have delivered, including a retail chain of more than thirty outlets and a billing and operations management system built specifically around this.
The consistent lesson is that counter software is judged by its worst moment, not its average one. A system that is pleasant at 11am and obstructive at 7pm will be worked around by 7pm, and the workaround becomes permanent because it was invented under pressure and never revisited.
This is why we test with the staff who will actually use it before launch rather than after, and redesign whatever is awkward while it is still cheap to change. The most common redesign is not adding a feature — it is removing a step.
Frequently asked questions
How important is hardware?
Less than most vendors imply, with one exception: input speed. A reliable scanner and a responsive screen matter more than the terminal's specification. Where hardware genuinely decides things is offline capability and whether the device keeps working on poor connectivity.
Can we use a tablet app instead of a proper POS?
Often yes, particularly at lower volumes. The questions are the same regardless of form factor: keystrokes per sale, offline behaviour, and whether the awkward transactions are handled.
What about GST and compliance requirements?
Non-negotiable and worth verifying directly rather than trusting a feature list. Confirm the specific formats and filing requirements your business faces, and ask to see them produced from real data.
Should billing and accounting be the same system?
They should share a record. Whether that is one application or two connected ones matters less than whether a sale reaches the ledger without anybody re-entering it.
How do we evaluate this properly?
Do not accept a scripted demo. Ask to complete your five most common transactions and your five most awkward ones, ideally on your own data, with someone from the counter operating rather than the salesperson.
Where to start
Before comparing products, document your actual transaction mix — including the awkward ones. Partial returns, split payments, overrides, weight-based items. That list is your real requirements document, and it is far more useful than a feature matrix.
Then ask three questions of any vendor: how many actions for our commonest sale, what happens when the internet drops, and show us these five awkward transactions.
A system that answers those well will survive peak hour. One that cannot will be bypassed, and the bypass will become the process.
SPEXA handles billing as one of six modules sharing a single record. If you want a read on what is actually slowing your counter, get in touch.