Keeping UPI and cash in one book without losing track of either

A day's takings of ₹26,500 can be written down to the exact rupee and still not tell you whether the day balanced. If the book says only ₹26,500, it cannot answer either of the questions you have at closing: how much should be in the drawer, and how much should have reached the bank.

So the method goes on the entry along with the amount. In a notebook that is one letter in the margin, C or U. In a spreadsheet it is a column you can total, or a tag if you keep the book in an app like Khatamel, which can read a day's report as Cash alone or UPI alone. An entry with no method on it is one you will reconstruct from memory three weeks later.

Keep the split at the entry level, not the day level; a khata settlement is where that bites. A regular owes ₹7,000 on his shop-front account and clears it at month end with ₹4,000 by UPI and ₹3,000 in cash. One ₹7,000 line against his name says something true about the customer and nothing useful about your money: as cash it leaves the drawer ₹4,000 short of what the book expects, as UPI it leaves the statement ₹3,000 behind. Write two lines on the same date, one marked UPI and one marked cash, both naming the account settled.

Sales are not the only thing that moves cash. ₹200 goes out for the delivery boy's tea, ₹60 for an auto, ₹3,400 to a supplier's man who came at four, after the bank shut, and ₹2,000 goes home with you on Saturday. None of it is a sale, and all of it changes the count, so all of it has to exist as an entry: a debit where the shop spent it, a withdrawal where the money left the business for you.

The quietest leak is the customer who buys goods worth ₹500, pays ₹1,000 by UPI and asks for ₹500 back in cash. The problem is that two movements get recorded as one. Write it as a ₹1,000 UPI credit and a ₹500 cash debit noted "cash back". Skip the second half and the statement still agrees with your UPI entries to the rupee, because ₹1,000 really did arrive. It is the drawer that comes up ₹500 short, and the day's takings read ₹500 more than you kept. The half you can check against a statement looks perfect, so the blame lands on the drawer, or on whoever was standing at it.

If the QR on your counter is a personal handle rather than the shop's, every ₹4,500 that arrives on it is a receipt in your book that the business account's statement will never show, and the correction waits for month end.

Keep one receiving handle on the counter and take the others off it. A merchant QR is the tidier version of the same idea: one handle, one day figure to check against. When a payment does land elsewhere, as it will when the main one fails in a rush, put the destination in the note. "UPI, personal a/c" turns a vanished ₹4,500 into ₹4,500 you still have to transfer.

It runs in reverse too. The shop's account was empty on Friday and you paid the supplier ₹3,400 from your own: that is a ₹3,400 credit noted "paid by owner, personal a/c", and a ₹3,400 debit against the supplier. The drawer is untouched, the supplier is settled, and the ₹3,400 the shop owes you is on the page instead of in your head.

A refund is not an erasure. If a ₹1,250 shirt comes back on Thursday, leave Monday's sale where it is and record a ₹1,250 debit against it, noting the original. Delete the sale and a day you had already closed quietly changes its total.

Reversals arrive late. A customer's app shows the payment as failed, so he hands you ₹600 in cash and walks out; the UPI credit lands at eleven that night. Enter it, but not as takings: it is a second payment for a sale already settled in cash. Note it against that sale, treat it as money owed back to him, and write the refund as a debit the day you return it. The entry that will cost you is the one that quietly joins the day's sales: the customer remembers paying twice long after you have forgotten receiving it.

The mirror case is money promised and not yet moved: record what the bank has actually shown you. On paper that is a P in the margin with the figure written outside the column you total, so it is on the page and out of the sum; circle it when the money arrives. An app that lists promised entries while keeping them out of the balance does the same job; either way it covers the regular who says "kal pay karish" and the cheque that has not cleared.

When a customer says "I paid yesterday", the amount proves nothing. ₹500 comes in all day, and by evening there are several ₹500 lines in the book. The reference does prove something. Every UPI payment gets a reference number and your app shows it against the payment; in a bank statement it is the twelve-digit UTR. The last four characters and the time are enough to find that payment again, and writing "UPI 4471, 6:40 pm" takes four seconds. With the customer who sincerely believes he paid, or the supplier who insists he was not, you are then searching rather than arguing.

The drawer and the app never hold the same money, so neither total can confirm the other. That is the whole reason the method goes on the entry, and at closing it means reading two figures instead of one: what came in as cash, and what came in on every handle money can arrive on.

• Read the day's cash figure and the day's UPI figure separately. One combined total can look right while both halves are wrong.
• Check the UPI figure against every handle — the merchant app's day figure, and any personal one a payment slipped onto. Transfer what landed in the wrong account tonight, while you still know which payment it was.
• Find the day's refunds and reversals. Each should be a line of its own against the sale it belongs to: never a deleted sale, never a fresh credit sitting in the takings.
• Put the reference and the time on any UPI line that does not carry them yet.
• Leave a promised entry promised unless the bank has actually shown you the money.

The two halves fail differently, and it is worth knowing which is which before you go looking. A UPI entry can be checked against somebody else's record, so an error there gets settled by the statement. A cash entry can only be checked against notes, and notes carry no reference, so an error there gets settled by whoever was standing at the counter. Do the UPI half first for that reason — and do it the same evening. The ₹4,500 that went to a personal handle is one identifiable payment while the time is still sitting next to it; by Friday it is one of several ₹4,500 credits with nothing to tell them apart.

The moment a second person takes money, the book has to record who made each entry and when. Not out of suspicion: an unexplained ₹700 is a question, and if every entry carries its author and the time, you ask that person rather than the room.

It also helps to give the counter less rope than the owner. A helper who can add a credit and a debit, but cannot delete an entry or post one in somebody else's name, will not quietly correct his own mistakes out of existence. He will come and ask. Khatamel sets those permissions member by member; on paper you get part of the way with initials against every entry, and a mistake fixed by one line struck through with the new figure and initials beside it. Never an overwrite, never an erasure, never a page out of the book.

What paper cannot do is tell you an entry was altered after closing. One book, then; and when two of you are at the counter at once, the second writes on a timed slip that joins that book before the shutter comes down.