Most shops start with a billing program at the counter and a stock list somewhere else: a spreadsheet, a notebook, or the owner’s memory. It works while the shop is small. Then a customer asks for something the list says you have, and the shelf is empty. Nobody can say whether it was sold, returned to the supplier or never arrived.
Why the numbers drift apart
When stock and billing are kept apart, every sale and every delivery has to be recorded twice, and sooner or later one of the two copies is missed. The signs are familiar:
- The stock list says ten, the shelf holds seven, and nobody knows where the other three went.
- Someone corrects the count by hand, and the difference simply disappears.
- What customers still owe is kept in a separate book, so nobody chases it until month end.
- Working out last month’s profit means a weekend with the bills and the supplier invoices.
- Prices typed in at the counter don’t always match the price list.
None of this is carelessness. It’s what happens when the same fact lives in two places.
One record for every movement
The fix is to let stock change for one reason only: something happened. A purchase from a supplier adds stock. A sale takes it away. Deleting a sale puts it back. Nobody edits the number directly, and every change is written down with what caused it, so the history always explains the count on the shelf.
Two rules keep this honest. A sale can’t take more stock than you have. And a purchase can’t be deleted once some of that stock has already been sold, because the history would no longer add up.
Billing that can’t disagree with the stock
At the counter, speed matters: find the product by name or barcode, add a discount, take the payment and print the bill. Behind that, the system does the careful part. The price comes from the product record, not from whatever was typed in. The discount is applied before tax, and both are spread across the lines so the line totals add up to the bill. Tax, whether it’s GST, VAT or sales tax, is worked out the same way every time.
If a customer pays part now and part later, the balance is recorded as a due against their name, and the next payment is set against it. The bill on screen, the printed copy, the receipt and the PDF all come from one template, so they can’t disagree with each other.
Reports you don’t have to build by hand
Once every purchase and sale is in one place, the reports cost nothing extra. Sales, profit, purchases, stock, customer dues, supplier payments: each one for today, this week, this month or any dates you pick, and each one downloadable as a spreadsheet. Profit is worked out from what each item actually cost when it was bought, not from a guess.
Not everyone should see all of it. Counter staff need to sell and see their own sales; they don’t need your profit margins or supplier costs. Who sees what is a question of its own, and we’ve written about access levels in a business web application.
A working example, and how it is built
We built a stock and billing system for a computer shop to show how this fits together. It covers products, customers and suppliers, purchases and supplier payments, counter sales with GST and discounts, dues, invoices on A4 paper, thermal receipts and PDF, reports, and a dashboard comparing this month with the same days last month. A super admin, admins and staff each see only what their role allows, and an activity log records who did what. It’s built with CodeIgniter, and you can see the application itself, which opens on its sign-in page.
For technical readers: stock changes only through one service, which updates the quantity and writes the movement record in the same step, so the two can’t disagree. Each sale line keeps the cost price at the time of sale, which is what makes the profit report honest. Permissions are named by page and action and checked on the server for every request. Every piece of shop data is escaped on output, and a strict Content Security Policy blocks scripts the application didn’t send.
When you don’t need this
If you sell a few dozen products and your current billing program already tracks stock well, you may not need anything new. A system of your own earns its place when the off-the-shelf tools don’t match how your shop works, when stock and bills keep disagreeing, or when you need reports nobody has time to build by hand. If you’re still deciding, start with when your business needs a custom web application.
Stock and billing systems are part of custom web application development. You tell us how your shop runs. We ask about your users, your business goal and your constraints, then recommend a scope and an approach, including whether something you already use would do. Describe what you are working with and we’ll reply by email.