Retail POS software runs the counter: finding the item, building the sale, applying price and discount, taking payment in one or several methods, issuing the receipt, and handling the exceptions of holds, voids, exchanges and refunds. It also runs the shift: who was on the till, what they took, and whether the drawer agrees with the system at the end. With Pentoggle, a retailer can describe how the counter actually works and generate the starting application around it.
This page is about the retail counter. If your sales are invoices to account customers, wholesale buyers or businesses, with payment terms and tax on the invoice, that is Retail Billing Software. Many stores need both, and they can be one application.
Most retailers already run an accounting system such as QuickBooks, Tally or Xero, and a card terminal from their payment provider. Those stay where they are. What is often still managed outside them is the discipline of the counter: why a sale was voided, who authorised the discount, and whether the cash at close matches the cash the system expected.
Key takeaways
- The POS is where stock actually changes hands, which makes it one of the most important stock records in the store, not just a payment device.
- Voids, refunds and manual discounts are the three control points at the counter. Recorded with a reason and a name, they are normal. Unrecorded, they are where shrinkage can hide.
- End of day is a reconciliation, not a total. The system's expected cash against the drawer, and the system's expected card total against the terminal, is the point of closing.
- Speed at the counter matters. A POS that adds ten seconds to every sale is likely to be worked around, and workarounds are often where the record breaks.
- A useful number is the cash variance per shift, per cashier, over time.
The spreadsheet is often not the problem
Here the incumbent is usually not a spreadsheet but a basic POS or a card terminal with a receipt roll, and the same reasoning applies. If it records the sale accurately and fast, keep it.
The trouble starts at identifiable points.
When the POS does not know the stock
It records that an item sold and does not deduct it from anything, or deducts it from a stock figure nobody else uses. The counter and the shelf can drift apart from the first sale of the day.
When exceptions are handled by hand
A wrong scan is corrected by ringing the item up again with a minus. A refund is cash from the drawer with a note. A discount is a lower price typed in. Each is reasonable and each may leave no trace that anyone can audit.
When the end of day is a printout
The POS prints a total. Somebody counts the drawer. If they match, good. If they do not, the difference is written on the printout and the reason is rarely found because there is no record of what happened between opening and close.
When two cashiers share a till
Both were on the counter, the drawer is short, and it is hard to say during whose sales the shortage arose.
What retail POS software holds
Item lookup
Scan by barcode, search by name or code, with variants such as size and colour selected at the counter.
The sale
Items, quantities, price, line and bill discounts within defined rules, and the running total.
Hold and recall
A sale parked while the customer fetches something, recalled by any cashier without re-scanning.
Payment
Cash, card, wallet, gift card, store credit and split payment across methods, with change calculated.
Receipt
Printed or sent by message or email, in your format, with the return policy on it.
Exceptions
Voids before and after payment, refunds, exchanges and price overrides, each with a reason and the person who authorised it.
Shift control
Cashier login, opening float, cash in and out during the shift, and close with a counted drawer.
End of day
Expected cash against counted cash, expected card against terminal settlement, by shift and by cashier, with variance recorded.
The POS is where stock actually changes
A POS is usually bought as a payment tool. It is more useful understood as a stock tool.
Every sale at the counter is the moment stock leaves the store. If the POS deducts the item from the same stock record that receiving added it to, the stock figure stays close to true through the day without anyone counting. If it does not, every sale can widen the gap between the system and the shelf, and the gap is often only discovered at the next count.
This is why the POS should be built on the item master rather than on a separate price list. A separate price list is easy to set up and it makes it likely that the counter and the stock will disagree, because a new item added to one may not be added to the other, and a barcode corrected in one may stay wrong in the other.
It also means the POS needs the variant right. A sale of "blue shirt" when the stock is held as blue shirt in five sizes deducts nothing useful. The counter has to select the size, which takes a second and is the difference between knowing you are out of medium and finding out from a customer.
Holds, voids and refunds are the control points
Many counter losses do not come from theft at the drawer. They often come from transactions that were legitimate in form and not in substance, and the three that matter are voids, refunds and manual discounts.
A void cancels a sale. It is normal when a customer walks away or an item was scanned twice. It is a problem when a sale is voided after the customer has paid cash and left, because the cash is now unrecorded. Recording every void with a reason, the cashier, whether it was before or after payment, and an approver for the after-payment ones, helps separate the normal ones from the ones worth a look.
A refund returns money. It is normal when goods come back. It is a problem when there is no matching original sale, or when the refunded item never returns to stock. Linking the refund to the original receipt, and requiring a destination for the item, addresses both.
A manual discount lowers the price. It is normal within a policy: a damaged item, a price match, a loyalty tier. It is a problem when it is applied freely and nobody can say why. A small set of discount reasons, a limit per cashier, and an approver above that limit turns a free-text field into a control.
None of this should need to slow the counter much. A reason is one tap. An approval is a manager's code. What it produces is a record that shows, at the end of the week, which cashier's voids are running high, which refunds had no original sale, and which discount reason is being used more than the policy would suggest.
End of day is a reconciliation, not a total
The daily close in many stores is a sales total and a drawer count. That answers how much was taken. It does not answer whether it was the right amount.
A close that reconciles starts from what the system expected. Opening float, plus cash sales, minus cash refunds, minus cash taken out for expenses, plus cash added, equals expected cash. Counted cash against that is the variance. The same for card: the system's card total against the terminal's settlement report. And the same for each other method.
Done this way, the close produces a small number per method per shift, and the number means something. A cash variance is a specific amount on a specific shift under a specific cashier, and the void and refund log for that shift is where to look for it. A card variance is often a transaction that was rung on the POS and declined at the terminal, or the reverse, and the two records together usually find it.
The close should also produce the payment reconciliation record, which is the day's expected figures by method, ready to be matched later against the bank and the card processor's payout. That is covered on Retail Payment Reconciliation Software, and it starts with a POS close that is precise enough to reconcile against.
Where the counter looks different by business type
- Supermarket Software, where lanes are many, baskets are large, weighed items need scales and the queue is a large part of the customer experience.
- Convenience Store Software, where transactions are fast and small, age-restricted items need a check at the counter and shifts run round the clock.
- Liquor Store Software, where age verification is a step in every relevant sale and case pricing sits alongside bottle pricing.
- Fashion Retail Software, where the sale involves variants, alterations and a high rate of exchange.
- Jewelry Retail Software, where a sale may be priced by weight, involve a deposit and a balance, and take an hour.
- Hardware Store Software, where the same item sells by piece, by length and by weight, and contractors buy on account.
Why retailers choose Pentoggle for the counter
Built on the item master
The POS sells from the same record that receiving adds to, so stock stays close to true through the day.
Exceptions with a name and a reason
Voids, refunds and overrides recorded as controls rather than as gaps, without slowing the counter much.
A close that reconciles
Expected against counted, by method and by shift, producing a variance rather than a total.
Your receipt, your discount rules, your payment methods
The counter built around how your store sells, including the methods your customers actually use.
Sits around your accounting and your card terminal
QuickBooks, Tally, Xero and comparable systems continue handling the books and tax. Your payment provider continues processing cards. Pentoggle adds the counter and the shift control around them.
A useful number for the counter
Cash variance per shift, per cashier, over time.
Not the day's variance, which blends shifts and people. The shift figure, attributed, tracked over weeks.
Read the pattern rather than the amount. A small variance in both directions across all cashiers is often counting error and is normal. A variance that is consistently short on one cashier's shifts is a question. A variance that appears only on shifts where the void count is high is a different question with a likely answer.
Report it alongside the void and refund counts for the same shift. The three numbers together explain each other far better than any one of them explains itself.
Ready to build retail POS software?
Your till total matched the drawer on most days last month.
On the days it did not, it may have been hard to say which shift, which sale or which cashier.
Describe how your counter works, what payment methods you take and how you close the day to Pentoggle in plain English and generate a working first version in hours, then refine it around your process.
Related resources
- Retail Billing Software →
- Retail Inventory Management Software →
- Retail Returns Management Software →
- Retail Payment Reconciliation Software
- Retail Loss Prevention Software →
- Retail Promotion and Discount Management Software
- AI Software for Retail Businesses →