Keep each shop as a separate business inside the app, not as prefixed party names in one merged list. Two shops means two sets of parties, two sets of reports, and two balances you can actually compare — which is the entire reason for tracking them at all.
The shortcut everyone tries first is naming parties "Shop 1 — Sharma" and "Shop 2 — Sharma". It works for about a month.
The short version
- One business per shop. Switch between them; never merge them.
- The same customer in both shops is two parties with two balances.
- Record inter-shop transfers as two entries, same date, same note.
- Compare the two shops monthly — that comparison is the point.
- Decide early: separate business (you own it) or separate account (you share it).
Why prefixed names fail
Putting both shops in one list seems simpler. Here is what breaks, in the order you will hit it.
Every report covers both shops. You cannot answer "how did the second shop do last month?" because there is no boundary in the data. Your total receivables figure is the sum of two businesses, which is a number with no decision attached to it.
Balances become ambiguous. A customer who buys from both shops has one merged balance, so you cannot tell either shop's exposure. If you set an udhaar limit — and you should — a merged balance makes it meaningless.
Sorting and search fill with noise. Every party search returns both shops' entries. On a busy evening that is exactly the friction that stops people entering transactions at all.
Separating later is painful. There is no clean way to split a merged history. You end up re-entering opening balances for both shops and abandoning the old data — the migration you avoided, now with more data to move.
None of this shows up in week one, which is why the shortcut is tempting.
Setting up the second business
Add the second shop as its own business with its own name, type, and address. The app then keeps its parties, transactions, and reports separate, and you move between them with a switcher in the header.
Name them so you can tell them apart at a glance in the switcher — "Kirana (Main Road)" and "Kirana (Station)" rather than "Shop" and "Shop 2". You will be reading these names quickly, often, on a small screen.
Check which business is active before you enter
This is the one genuine risk of a multi-business setup: entering a transaction against the right party in the wrong shop. Glance at the header before saving. Amounts landing in the wrong business are the most tedious correction there is, because you fix them across two sets of books.
On cost: multiple businesses is a paid feature in most khata apps, LenDen included, where the free tier caps parties tightly enough that a second shop is realistically a subscription. Worth knowing before you design a workflow around it.
The same customer in both shops
Add them in each business, separately. Two parties, two balances.
That feels like duplication and it is not. The debts are genuinely separate: they are owed to different books, and if you ever sold one shop or took a partner into one of them, the two figures would need to part company cleanly.
If you want the combined picture — "how much does Sharma ji owe me across both shops?" — add the two numbers yourself. That is a five-second calculation you do rarely, and it is much cheaper than the merged-books problem you avoid by keeping them apart.
Where it matters most is limits. If Sharma ji's limit is ₹1,000, that is ₹1,000 per shop or ₹1,000 combined — decide which, and say it to him once. Otherwise he can quietly run ₹1,000 at each and you have doubled your exposure without noticing. Setting limits properly is covered in udhaar limits: how much credit should you give.
Moving money or stock between your shops
This is where two sets of books most often stop agreeing, and the fix is a discipline rather than a feature.
Treat the other shop as a party. When ₹5,000 of cash or stock moves from the Main Road shop to the Station shop:
- In Main Road: an entry showing ₹5,000 out, party "Station shop", note "transfer to Station 22 Aug".
- In Station: an entry showing ₹5,000 in, party "Main Road shop", note "transfer from Main Road 22 Aug".
Same date, same amount, same note wording. Both sides, always.
Recording only one side is the classic error. It leaves one shop looking ₹5,000 poorer than it is and the other ₹5,000 richer, and because each set of books is internally consistent, nothing looks wrong until you compare them and the totals refuse to reconcile.
A monthly check: the two transfer parties should mirror each other. If Main Road says it sent ₹18,000 to Station this month and Station says it received ₹13,000, you have a missing entry and you know exactly which month to look in.
Compare them monthly — this is the point
Separate books exist so you can answer questions you cannot answer with merged ones. Once a month, put the two shops side by side:
| What to compare | What it tells you |
|---|---|
| Sales | Which shop is actually growing |
| Udhaar outstanding | Which shop is financing its customers harder |
| Write-offs | Where credit discipline is weaker |
| Stock sitting unsold | Where cash is stuck |
The second row is the one that surprises people. Two shops with similar sales can have very different receivables, and it is almost always about who serves at the counter and whether limits get applied. That is a management problem you cannot even see with merged books.
If one shop is consistently worse on udhaar, the fix is usually not the customers — it is that nobody set limits or sends day-7 reminders there. The system for that is in the complete guide to managing udhaar.
Your own money, across two shops
One more separation, and it is the one that undoes everything if you skip it: your household money is not either shop's money.
With two shops the temptation is worse, because cash moves between them legitimately and it becomes easy for personal withdrawals to disappear into "transfers". Pay yourself a fixed amount on a fixed date from a defined shop, recorded as a withdrawal — not as a transfer, and not as an expense.
Get that wrong and both shops' profits are fiction, however well you have separated them from each other. Small shop bookkeeping covers how owner drawings feed into knowing what you actually earned — and why a withdrawal recorded as an expense lies to you twice.
Frequently asked
- Can I just add the shop name to each party instead?
- You can, and you will regret it. Prefixed names give you one merged set of books, so you cannot tell which shop is profitable, and every report covers both. Untangling it later means re-entering everything. Use separate businesses from the start.
- What if the same customer buys from both shops?
- Add them as a party in each business and keep the balances separate, because they are separate debts to separate books. If you want one combined figure, add the two balances yourself — do not merge the parties.
- How do I record moving stock or cash between my own shops?
- As two entries: money out of one business, money in to the other, on the same date with the same note. Treat your other shop as a party. Recording only one side is what makes two sets of books stop agreeing.
- Is multiple businesses a paid feature?
- It varies by app, and in LenDen's case the free tier is limited enough that a second business is realistically a paid setup. Check before you plan around it.
- Should a partner's shop be a separate business or a separate account?
- Separate account, if the partner needs their own access. A separate business inside your account means you control it and their entries carry your name — fine for a shop you own, wrong for one you share.