Selling on udhaar without the notebook

Almost every neighbourhood shop sells on credit, and almost none of them has a record of it that survives an argument. The khata works right up until it does not: it cannot be searched, it exists in one copy, and the only person who can read it is the person who wrote it.

Moving credit into the till is one of the highest-value things a small shop can do with software, and it is worth doing properly rather than as a note field on a bill.

What "properly" means

The balance is a consequence, not a number somebody types

A customer's balance should be the sum of what they took, what they returned, and what they paid — with every one of those pointing back at a document. If the software lets anyone type a balance directly, the balance is an opinion.

The limit is enforced when it matters

A credit ceiling that shows a warning after the sale is a report, not a control. The check has to happen on the write, at the moment the sale is recorded — otherwise two counters selling to the same customer at the same time can both pass a stale check and put them over together.

The same applies in the other direction: taking a payment for more than is owed should be refused, not quietly accepted and left as a negative balance nobody understands.

A partial payment cannot be recorded twice

If a payment is entered and the screen hesitates and somebody presses again, it must land once. That is not a matter of being careful; it is a matter of the software being built for a busy counter.

The part most software gets wrong: returns

Here is the case worth testing on any system you are considering.

A customer takes goods worth 5,000 on credit and pays 2,000 at the counter. Their account carries 3,000. Later they return the whole lot.

• If the software takes the full 5,000 off their account, you have just credited them 2,000 they never owed.
• If it takes off nothing because "the bill was part paid", you owe them a refund that is not recorded anywhere.

The correct answer relieves the unpaid part first and refunds the rest, and records what actually moved rather than what was asked for — because by the time the return happens the customer may have paid the balance down and there may be less to relieve than the return is worth.

Try it. It is four minutes of testing and it tells you whether the credit feature was thought about or bolted on.

Split payments are the normal case

A customer paying "some now, rest later" is not an edge case in a shop like this; it is Tuesday. The bill should be settleable several ways at once — part cash, part card, part on account — while remaining one bill for tax and for the receipt.

Two consequences follow, and both are worth checking:

• Only the part that went on account should become a receivable.
• Only the cash leg should count towards your drawer at close. A bill half settled by card is not cash in your till, and if the software thinks it is, every day will look like it is short.

Statements the customer can see

Half the value of moving credit into software is being able to hand somebody a statement instead of turning a notebook around. What is worth having:

• A per-customer ledger listing every bill, return and payment with its date and document number.
• A receipt for every payment received, numbered, so "I paid you last week" has an answer.
• The ability to export it, so a disputed account can be sent rather than described.

Practical notes for a shop starting today

• Start with the regulars. Do not try to enter three years of history. Enter each customer's current balance as an opening figure and go forward from there.
• Set limits from the start. They are much harder to introduce once customers are used to no limit.
• Take payments in the app, not in your head. A payment recorded a day later is a payment that will eventually not be recorded.
• Do not use credit for staff purchases. Give them an account of their own, or the two get tangled.

SalezFlow POS puts credit on a real customer account with an enforced limit, refuses an overpayment rather than absorbing it, relieves the unpaid part of a bill first when goods come back, and counts only the cash leg of a split bill towards your drawer. See POS for a kiryana store, or download it and try the returns case above on your own data.