Walk into a kirana in Coimbatore at seven in the evening and watch what happens when a regular picks up rice, oil and a packet of tea. There is no card machine moment. There is a nod, a name, and a line written in a notebook — the khata. The customer pays at the end of the month, or when the salary lands, and both sides know the arrangement.
This is not a fringe case. In a great many Indian shops, and in trade counters across the Gulf, a meaningful share of turnover leaves the building before any money arrives. Yet if you look at what point-of-sale software offers at the moment of payment, you will usually find cash, card, wallet, maybe UPI — and nothing for the transaction that actually happened.
What shops are told to do instead
The standard advice is: raise an invoice in the back office. Go to Sales, create a document, set the terms, send it. Which is fine for a contractor ordering by email, and absurd for a customer standing at the counter with a bag in their hand and four people behind them.
So the shop does what shops do. The sale goes in the notebook. The notebook is not the accounting system. And three things follow, every time:
- Revenue is late or invisible. The sale happened today; the books hear about it when someone reconciles the notebook, if they do.
- Nobody knows the exposure. How much is out on credit right now, across all customers? The honest answer in most shops is a shrug and a number that is roughly right.
- Collection is memory-based. Who is overdue, by how long, and who has quietly drifted past what you would ever have extended them deliberately?
The notebook is not the problem. The notebook is a rational response to software that will not model the sale.
What "on account" should mean at the counter
The fix is not exotic. An on-account tender is simply the honest statement that no money moved:
- The sale posts in full — a numbered tax invoice, the revenue, the GST, the stock movement, all of it, immediately.
- No payment record is written, because nothing was paid. The invoice stays unpaid, and the balance sits on that customer's receivable where it belongs.
- Collection happens later, through the ordinary receipts process, with terms, statements and ageing — the machinery accounting systems have had for decades.
The accounting is unremarkable. It's the placement that matters: the decision to extend credit happens at the counter, in front of the customer, so that is where the software must support it.
Two things the counter has to know before it says yes
Extending credit blind is how a khata becomes a bad debt, so a counter that offers it owes the cashier two facts before they commit:
- Who is this? A walk-in has no account to charge. An on-account sale without a named customer is a receivable owed by nobody — so it should simply be refused, at the server, not merely discouraged in the interface.
- How much are they already carrying, and what did you decide their limit was? Not a number in someone's head: the balance outstanding right now, and the headroom left against the credit limit the business set. If the sale would pass that limit, the counter should say so — with the figure — and offer the obvious alternative: take part of it in cash, or raise the limit deliberately.
Both are refusals a cashier can act on in the ten seconds they have, which is the only kind of control that survives a queue.
The part most systems get wrong afterwards
Here is a subtler failure. Once a counter can sell on credit, the end-of-day reconciliation has to understand what it is looking at.
A naive implementation compares what the counter reported against what the payment ledger received, tender by tender, and flags the difference. Sell ten thousand rupees on account and that report now shows a ten-thousand-rupee "gap" — an alarm for something that is not wrong at all. Worse, the invoice with no payment against it looks like a sale that failed to post.
A receivable is not a missing payment. It should be reported as its own figure — charged to accounts today, and how much of it is still owed — sitting beside the cash and card columns, never inside them. The cash reconciliation stays exact, and the credit exposure becomes a number the owner can watch rather than a distortion they learn to ignore.
Why this matters more in India right now
Three things are happening at once in Indian retail. GST has made the tax invoice non-negotiable, so the old arrangement — no bill for the khata sale — is no longer viable. UPI has made some payments instant and traceable, which raises the contrast with the part of the business that is still on paper. And credit remains a competitive instrument: the shop that carries its regulars keeps them.
A point of sale that handles UPI beautifully and cannot handle a khata is solving the easy half of the problem.
How BIZA handles it
"On account" is a tender in BIZA's point of sale, beside cash, card, UPI and the rest. The goods go out, the tax invoice posts with GST and HSN as usual, and the balance stays on the customer's receivable. The counter shows the cashier what that customer already owes and what their credit limit leaves before they commit; a walk-in is refused, and so is a sale that would pass the limit — by the server, not just the screen. Part cash and part account on the same sale is ordinary.
Afterwards, the balance is collected through Customer Receipts with the terms, statements and ageing that were always there, and the POS dashboard reports the day's credit separately: charged to accounts, number of sales, still owed.
The notebook was never the problem. It was the only place the sale would fit.
See the POS feature page, the POS guides, or talk to the team.