The short version. Keeping stock for multiple firms in one godown, on top of batches with different costs and expiry dates, breaks most inventory software within a month of setup. Those tools assume one firm, one flat stock count, and units that are identical once they're on the shelf. The fix is not a stricter counting schedule. It is a system built around how the godown actually works: by firm, by batch, and by the GST invoice each unit eventually leaves under.
If your business runs more than one firm out of the same warehouse — a common setup when a family business grows and splits billing across entities, or when a distributor carries stock for more than one principal — you already know the physical problem. The shelf doesn't care which firm owns which carton. A worker picking an order sees one pile of a product, not three ledgers behind it. Off-the-shelf inventory apps are built around a single legal entity and a single flat SKU count, so the moment your reality includes "this batch belongs to Firm A, that one to Firm B," the software and the warehouse stop agreeing with each other.
Why the mismatch keeps coming back
Most teams try to solve this with discipline: separate shelves, colour-coded bins, a stricter counting routine before month-end. It works for a while, then a new worker doesn't know the colour code, or a rush order gets picked from whichever carton is closest. The stock count in the system and the stock on the ground drift apart again, and the only way to find out by how much is a full physical count — usually right when you can least afford to stop and do one.
The deeper issue is that the split lives in your head and on paper, not in the software. Your Tally books are already separate per firm, because the invoices have to be. But the physical inventory system, if you have one, usually isn't — it was built, or bought, assuming a single firm owns everything in the godown. Batch and expiry make the same problem worse: a generic stock count tells you "40 units," not "25 units from the batch expiring next month and 15 from the one after," which matters the moment you need to decide what to dispatch first.
Month-end is where this surfaces hardest. Each firm's accountant wants a stock figure that reconciles against that firm's own purchase and sales entries, but the godown itself was never split that way physically. Someone ends up doing the division by hand, on a spreadsheet, from memory of which lot arrived under which firm's purchase order — and that spreadsheet becomes the real record, even though nothing in the warehouse enforces it.
What a system built around this actually does
This is exactly the kind of operations software we build: software for inventory management that matches how your distributor or wholesale operation actually runs stock, not how a generic template assumes it does.
The starting point is tagging stock by firm and batch at the moment it enters the godown — on a phone or a basic scanner, not on a separate spreadsheet that someone has to remember to update. From there, the system can hold a live stock position split by firm and by batch at the same time, so "how much do we have" and "how much of that is Firm A's, and how much of that is ageing" are both answers it already has, not counts someone has to go and do.
Picking can follow rules you set — oldest batch first, or a specific firm's stock first when an order specifies it — instead of relying on whoever is standing closest to the shelf. And because your accounting is already split by firm in Tally, the system can be built to hand off stock movements firm by firm through your existing accounting and billing setup, instead of asking your accountant to reconcile two different versions of the same warehouse every month.
None of this needs you to rebuild how the godown is laid out, or retrain staff on a new counting ritual. A system like this is built to carry that complexity in the software layer, instead of leaving it to staff and spreadsheets to work out by hand.
What this doesn't fix
It won't fix a habit of picking stock without logging it, and it won't fix a warehouse with no process at all — software built around a process that doesn't exist has nothing to track. What a system like this is built to close is the specific gap between "what the ledger says" and "what the physical count would show," because a generic ledger was never built to know about firms and batches in the first place.
It's also not a reason to throw out Tally or whatever accounting system you already run. The firm-wise books stay exactly where they are; the inventory layer is what gets built to speak the same language as the godown floor.
Where to start
If this is your situation, the useful next step isn't shopping for another inventory app off the shelf — every one of them will run into the same firm-and-batch gap yours already has. Start with a plain description of how stock actually moves through your godown today: how many firms draw from it, how batches get picked, and where the current count usually goes wrong first. That's enough to show you, with a working demo built on your own stock data, whether a system like this is worth building before you pay for anything.
No discovery call is required to start that conversation — a short description of your godown is enough to see whether the fit is real.