Search for inventory management software in India and the market answers immediately. SoftwareSuggest lists twenty options; Zoho Inventory, TallyPrime, Marg ERP, Vyapar, BUSY, and Unicommerce all rank for the same query. Marg alone claims more than ten lakh businesses across retail, distribution, and manufacturing. The feature lists are near-identical — real-time stock sync, barcode scanning, automated reorder alerts, multi-location support, GST-ready invoicing, GSTR-1 reports — and the pricing sits between ₹2,000 and ₹10,000 a month. For that money, these tools are a genuinely good deal, and most SMBs that hold stock should buy one.
It is worth being honest about why they are cheap and good at the same time. Recording a stock-in, recording a stock-out, scanning a barcode, raising a GST invoice, and printing a low-stock report are the parts of holding inventory that are uniform — they look the same at a pharma distributor in Indore, an auto-parts trader in Pune, and an electronics wholesaler in Delhi. Uniform work is commodity work, and commodity work gets built well and priced low by a packaged vendor. But a business does not run out of money because its barcode scanner is slow. It runs out of money in the gap between what the ledger says and what the warehouse actually holds — and that gap is exactly where the packaged tool stops matching reality. This is a field guide to where the generic stock tool stops fitting.
The ledger layer is genuinely solved — rent it
Start by conceding the obvious: do not build a stock ledger. Do not build a barcode module, a GST invoice generator, or a min/max reorder report. These are solved problems with cheap, mature products behind them, and any custom build of the ledger layer is money set on fire. The packaged tool earns its few thousand rupees a month because it does the uniform recording work well and you never have to think about it again.
The mistake is assuming that because the ledger is solved, the warehouse is solved. It is not. The packaged tool models the parts of inventory that are the same everywhere and leaves the parts that are specific to you in a spreadsheet, in a WhatsApp group between the godown and the order desk, and in the head of the senior storekeeper who knows which numbers to trust. That parallel workflow — the reconciliation someone does by hand every evening, the "let me check and call you back" before a big order is confirmed — is the actual map of where the packaged tool stopped matching. Closing those seams is the kind of internal operations tooling that does not exist as a product you can subscribe to, because the shape of your units, your locations, and your costing is specific to your business in a way a barcode never is.
The SKU is never one clean SKU
Open any packaged inventory tool and the item master assumes a clean story: one SKU, one unit, one price, a quantity that goes up when you buy and down when you sell. That story is true for almost no real warehouse.
What is actually true is messier. You buy in cartons and sell in pieces, so the same item has a purchase unit and a sale unit and a conversion the system has to hold without losing a count. You stock batches with expiry dates, and FEFO — first-expiry-first-out — is not optional in pharma, food, or chemicals. You carry variants — size, colour, grade, voltage — that are one product to the catalogue and forty distinct stock positions to the warehouse. You receive the same item from three vendors at three rates. The packaged tool can usually bolt one or two of these on as a setting, but the moment your real buying-and-selling pattern needs all of them at once, the item master cannot hold it, and the conversions move into a spreadsheet the storekeeper maintains by hand. A unit-of-measure and batch model that matches how you actually buy and sell — multiple units, expiry-aware picking, real variant depth — is often the highest-value thing a stock-heavy SMB can build, because it makes every downstream number trustworthy instead of approximately right.
On hand is not the same as available
Here is the question that decides whether you keep a customer: when the order desk says "yes, we have forty in stock," is that true? The packaged tool reports quantity on hand — a single number that quietly includes stock already committed to other open orders, goods received but not yet booked in, and units sitting in a godown across town that cannot be picked before the cutoff.
So the order desk promises against a number that is not actually free, the warehouse comes up short, and you either oversell and disappoint a customer or hoard buffer stock to cover the uncertainty — both of which cost real money. The fix is to stop treating inventory as one number. Available-to-promise is on hand minus what is reserved against open orders plus what is genuinely inbound within the promise window — computed per location, not company-wide. Modelling reserved, in-transit, and location-level availability as separate, visible things is unglamorous and it is exactly what turns "let me check and call you back" into a number the order desk can quote with confidence.
Where the stock physically is
The packaged tool knows you have 200 units. It rarely knows where the 200 units are in a way that helps someone pick them. Multi-godown support in most products is a label on a transaction, not a map of the warehouse — it cannot tell you that 120 are in the main rack, 50 are in the overflow godown, and 30 are on a delivery vehicle that left this morning.
For a single small shop, the label is enough. For a distributor running two or three godowns and a fleet of delivery vehicles, the gap between "we have 200" and "we have 120 you can pick today" is where stockouts and emergency purchases come from. Bin-level location, godown-to-godown transfers that actually move the count, and in-transit stock treated as a real state rather than a black hole — these are the things a growing operation needs and the packaged tool flattens. Wiring barcode scanning to location rather than just to the item, often through a simple warehouse floor app the picking staff actually use, is what makes a multi-location count real instead of aspirational.
The cost of a unit is not its purchase price
Ask an SMB owner what a unit actually costs and the answer is usually the supplier's rate. But the supplier's rate is not the landed cost. By the time a unit is on your rack and ready to sell, it has absorbed freight, loading and unloading, godown rent, the GST you paid and may or may not fully recover as input credit, and — for imports — duty and clearing charges. The packaged tool records the purchase price and computes margin against it, which means the margin it shows you is optimistic, sometimes badly so.
This matters most where it is least visible: the low-margin, high-volume line that looks profitable at purchase price and is quietly loss-making once landed cost and the cost of carrying it are counted in. A landed-cost engine that apportions freight and overhead across a consignment, holds a moving-average or FIFO valuation honestly, and tracks input-tax-credit so the GST is not double-counted, turns "we think this line makes money" into a number you can actually price against. That is the difference between a stock system and a system that protects your margin.
The procurement loop the reorder alert can't close
Every packaged tool fires a reorder alert at a min/max threshold. That threshold is a static number someone set once and rarely revisits, so it over-orders slow movers and under-orders fast ones, and it has no memory of how long a particular vendor actually takes to deliver.
A real reorder decision is dynamic: consumption velocity over the last few weeks, the actual lead time of the vendor you would order from, the minimum order quantity that vendor enforces, and the cash you want tied up in stock this month. Beyond the trigger, the loop has to close — the purchase order goes out, goods arrive, a goods-receipt note checks them against the PO, short-supply and quality rejections get recorded, and the vendor's account reconciles to what was actually received, not what was ordered. The packaged tool fires the alert and abandons the loop; the rest happens over phone calls and a spreadsheet. Closing that loop is a piece of process automation that pays for itself the first time it stops an over-order of a dead SKU or catches a vendor's short-supply the manual check missed. It is the same instinct behind wiring parts inventory to live jobs — stock decisions are only as good as the demand signal they are connected to.
Four systems, four truths
Most SMBs do not have one inventory number; they have four. Tally knows what was invoiced. The marketplace or D2C panel knows what sold online. The POS knows what left the counter. The warehouse knows what is physically on the rack. The four disagree every single day, and the disagreement is where oversell, double-counting, and hours of dead reconciliation come from.
The instinct is to buy a fifth tool that promises to "sync everything." The better answer is usually to decide which system owns inventory truth and make the others read from and write to it, so on-hand is computed in one place rather than guessed across four. Stock movement and GST are the same event — a sale is a stock-out and an invoice; a purchase is a stock-in and an input-tax-credit claim — and once a business crosses the e-invoicing turnover threshold, those invoices must be reported to the government portal in a prescribed format. A thin inventory layer that holds the single truth and keeps stock and books as one event, rather than two that drift apart, is often the highest-leverage thing a multi-channel SMB can build.
What a thin custom layer looks like
None of this is an argument to throw out the packaged tool. It is an argument for a hybrid: rent the ledger, build the seams.
In practice that means keeping the off-the-shelf product for stock movements, barcode capture, GST invoicing, and basic reporting, and building a thin layer over it that owns the business-specific logic — a unit-of-measure and batch model that matches how you really buy and sell, an availability layer that separates committed from free stock, location-aware multi-godown logic, a landed-cost engine that tells you true margin, and a single inventory truth the channels reconcile to. The layer reads from and writes to the packaged tool where it can, and owns the truth where the packaged tool is thin. Because peak season, a new godown, and a new sales channel all stress-test it, the layer is usually best kept on a light ongoing support arrangement rather than built once and abandoned.
Where this leaves you
If you hold stock for a living, the honest read is this: the cheap packaged tool is doing exactly what it should, and you should keep paying for it. But it solves the uniform part of holding inventory, and you do not lose money on the uniform part. You lose it in the gap between on hand and available, in the landed cost you cannot see, and in four systems that never agree. Those are the seams — specific to your warehouse, which is why no product will ship them, and exactly why building them thinly, on top of what you already run, is where the return is.
If you can see your own operation in the evening reconciliation your storekeeper does by hand, that is the map. Tell us what that spreadsheet is doing, and we will tell you honestly which seams are worth closing and which to leave to the packaged tool.