Khata — selling on credit

A distributor loads a van and drives a round. At each shop he leaves three loaves on credit; three days later he stands at that same counter and does three things at once — takes back the one that spoiled, leaves today's delivery, and collects money. Sometimes all of it, sometimes half, sometimes none.

That is what the khata is for. A shop that sells over a counter and takes the money there does not need any of this.

Opening an account

Khata → Open a khata. Pick any shop off the customer book and it joins the trade list. A reason is kept on the record.

The ceiling is set next, on the account itself — Khata → the shop → Credit terms:

• Credit limit — leave it empty for no ceiling, which is a real answer and not a gap. A limit of zero would refuse every sale, so the two are never read for each other.
• This shop buys on account — unticking it takes them off the trade list.

Only somebody who may write a debt off may set the terms it runs on. That is the owner, and anyone the owner grants it to. A branch manager cannot: a credit limit is worth money forever.

Every change is on the record — who moved the ceiling, from what to what, when and why. "Who gave this man a two-lakh limit" is the first question an owner asks, and the current figure cannot answer it.

An account that still owes money cannot be closed, and the refusal names what is on it. Nothing would be lost — the ledger never deletes — but a shop taken off the list while it owes forty thousand disappears from every screen that shows who owes what, and the debt goes with it.

What they owed before Sellify

Khata → the shop → Opening balance. Once per shop, ever. Positive is a debt; a shop that is in credit with you is entered as a negative.

It sits on the statement like every other row, so a khata that arrived with the shop reads the same way as everything since — and the button is only there while the account has no rows yet. An opening is what a khata STARTS at; one that has been sold into since is corrected with an adjustment, where the reason and the record are.

Selling on account

At the till, name the shop and choose On account as the payment. That is the whole change — everything else about the sale is an ordinary sale: the same cart, the same tax, the same stock coming off the shelf, the same figure on the Z report.

Part cash, part on account is an ordinary split. Rs 3,000 handed over and Rs 2,000 on the khata is two payment rows, and only the Rs 2,000 reaches the ledger. The tax follows the mix exactly as a cash/card split does.

The drawer is untouched. Money on a khata is not cash, so no till is ever expected to hold it and no day close asks about it.

Over the limit

A sale past the ceiling is stopped, and the refusal names the balance, the limit and the shortfall — so nobody does subtraction at a shop's counter.

A manager can lift it with their PIN, and who let that sale through is recorded on the order. Set approvals.credit_limit_override off and the ceiling is absolute: nobody passes, and no manager is fetched — being sent for one only to be refused in front of the customer is the worst version of that screen.

An owner or a branch manager ringing it themselves needs no PIN, and is still recorded.

Hand over now, or send with the van

A credit sale asks once, when it is placed:

• Hand over now — the goods leave with the customer. Stock comes off the shelf there and then, like any retail sale.
• Send with the van — the order goes on the dispatch board, and the shelf is charged when the van actually leaves. Goods in a van while the shelf still says they are in the building means the next till sells something that has physically gone.

A drop that fails voids the sale, puts the stock back and reverses the khata entry. Nothing was delivered, so nothing is owed.

The visit — three things at one counter

Khata → the customer → Start a visit. One screen:

1. What came back — off any open bill, priced at what that bill actually charged.
2. Today's delivery — an ordinary cart, put on the khata.
3. What they paid — cash, card, or a bank transfer with its reference.

All three save together or none of them do. A shop is never left having handed goods back against a delivery that then failed to save.

The order they are applied in is deliberate: the return first, so the credit it raises is off the queue; then the sale; then the money, so it runs down the real queue. A shopkeeper who hands over exactly what they owe is square when the salesman walks out.

Goods that came back

A return is its own document on its own day. Monday's three-loaf bill stays a three-loaf bill and a one-loaf credit note sits under it — the balance is what comes right. Rewriting the invoice would leave the shopkeeper's own copy of the paper disagreeing with ours, and would move figures out of a sales report somebody has already read.

Three loaves out can never be four loaves back. The ceiling counts every return ever raised against that line.

Each line says what condition the goods came back in:

• Good — back on the shelf, sellable.
• Damaged / Expired — back on the shelf and then written off again, as two separate movements. "How much came back" and "how much was WASTED" are different questions, and a shop that only ever sees the net figure cannot tell a slow-selling stockist from a careless one.

A cash sale can be returned too, and the return says which: cash back now, or credit to the ledger.

No return window unless you set one. credit.return_window_days is empty out of the box — the bread man comes back in three days and a wholesaler in two months, and a product that picked one would refuse a real return at a real counter with the goods already on it.

Money coming in

Khata → the customer → Take money. One figure is typed: the amount. Which bills it clears is worked out here, oldest first.

An account cannot be settled with more credit. Cash, card, or wallet for a cheque or a bank transfer with its number in the reference.

Money left over is not an error. An overpayment stays on the account as an advance — the balance goes negative, which is what "in credit" means — and the next sale is what it lands on, by itself.

Taken at the counter, or collected on the round

One field decides, and it matters:

A salesman usually has no login, so he is an employee row — the same as a rider.

Settling the round

A day will not close with a collector's cash in his pocket, and the refusal names him. Nothing else in the day close can see that money: the bills he was paid against were rung in days ago and counted since.

The collector declares what he counted; the server works out what was expected and the variance. Short is a negative number, the same convention as everywhere else in Sellify.

credit.settle_collectors turns the guard off, for a shop whose salesmen pay straight to the owner.

Re-allocating a receipt

Oldest-first is right almost always, and wrong exactly when a shopkeeper insists a payment was for a particular delivery. A manager can move it: no money moves, only which invoice reads as paid — which is what a month-end statement gets argued over.

What the khata is made of

Every row on the statement is one of seven things, and each carries the date, the branch, the document behind it, who wrote it and why:

opening · sale · credit note · payment · allowance · write-off · adjustment

A mistyped receipt is corrected with an adjustment, which is the owner's act with a typed reason on it. Nothing is ever deleted.

The five reports

Reports → Credit.

• Customer statement — one shop, the page that gets handed over at month end. It opens with what was brought forward rather than at zero, because a March statement starting at nothing tells a shopkeeper they owed nothing on the 1st.
• Receivables aging — 0–30 / 31–60 / 61–90 / 90+. It buckets the bill, not the balance: a shop that pays every delivery a fortnight late and one that has not paid since January owe the same figure, and only the buckets tell them apart. A shop in credit is its own column, not netted in.
• Sales by party — bought, returned and paid on one line. One who buys forty thousand and returns eight is not the same customer as one who buys forty thousand and returns nothing.
• Sales returns — good against damaged and expired.
• Collections — per collector: what they took, what they declared, and the variance.

The first three name a shop and its number, so they are never shown to the assistant.

The van's own till

Admin → Terminals → Credit customers. Off by default.

A salesman standing in a shop doorway with no signal has to be able to name the shop, so his till carries this branch's credit customers. A counter till never does — a customer book on a tablet that can be left in a taxi is a decision somebody should have made on purpose.

It carries who they are, never what they owe. Name, phone and address ride down; the balance and the limit do not. Those are counted from rows another till is moving while this one is dark, so a figure shipped to a tablet would be wrong the moment it landed — and a limit checked against a stale balance is not a limit.

So on a dark till: the shop can be named and the sale can be rung, but what they owe and the sale on account both need the server, and the screen says so in a sentence rather than greying a button out.

What the khata does not do

• No per-customer price list. A trade customer is charged the shelf price, and where a rate was agreed the counter types it — which records the price it replaced and refuses anything below cost. A real wholesale price list has to reach the menu, the offline bundle and every report at once, and is its own piece of work.
• No routes. Which shops a van visits in what order is not something Sellify plans.
• No van as a stock location. The order is what takes goods off the shelf.
• No batch or expiry tracking on a return. Returned goods are counted, never traced.
• No interest and no ageing charges. Nothing is added to a balance for being old.

Buying it

Credit sales is a module and it is off by default — every other module in Sellify is on, because switching gating on must never take something away from a shop that already had it, and that cannot apply to a module nobody has yet. A shop selling over a counter must not find a credit button on its till because somebody added a feature.

Buying Bookings brings it with it: a deposit lands on a customer's ledger, so the diary cannot work without the khata underneath it.