A khata where every rupee points at a bill.

01 · The gap

A running total is not a ledger

Most khata apps store one number per customer. That tells you someone owes four thousand rupees and nothing about which purchases make it up, so when they dispute it you are back to memory. Here credit is created by the bill that gave it, which means every rupee of a balance points at a dated bill with items on it.

• Balances built from bills, not from typed entries
• Every amount traces to a dated invoice
• Nothing to enter twice, so nothing to disagree with
• The customer can be shown the bill behind any figure

02 · Settling

Two hundred rupees against four old bills

Part payments are the normal case in a udhaar book and the hardest thing to keep straight on paper. When a customer pays, you choose which bills it clears and how much goes against each. What remains stays visible on the bill it belongs to instead of dissolving into one balance, and a receipt prints for what they just handed over.

• One payment split across several invoices
• Part-paid bills keep their remaining amount
• A printable or shareable payment receipt
• The original bill is never rewritten

03 · Chasing

A reminder that arrives when you agreed it would

Reminding a customer on a day you had not asked them to pay is how a shopkeeper loses a customer, and it is why generic overdue alerts get switched off within a week. Each customer can carry one date you expect to be paid by. Nothing is said about them until it is close, and the customer list shows it only as a short note on a line that already exists.

• One expected-payment date per customer
• Presets of a week, fifteen days, a month, two months
• Silence until the date is near or past
• Overdue customers grouped, oldest first

04 · Offline

The khata does not need a signal either

Recording credit, taking a payment against it and printing the receipt all run from the phone. The entry is made the moment the customer is standing there, not when the network comes back, and it reaches the web dashboard on its own afterwards.

• Credit and payments recorded offline
• Receipts print with no connection
• Syncs by itself, with nothing to press
• A payment sent twice is still one payment

05 · Trust

Nobody can quietly change what someone owed

A ledger is only worth anything if it cannot be edited behind your back. Payments and corrections are appended rather than written over the top, so the history stays readable, and every change carries the name of whoever made it and the value it had before. That record cannot be deleted by staff, and it cannot be deleted by you either.

• Corrections appended, never overwritten
• Who changed what, and what it was before
• Staff roles decide who can settle a payment
• The activity log is append-only for everyone