What is demand forecasting software, and who needs it?
Demand forecasting software predicts future sales quantity for each product, location and time period, then turns that prediction into a purchase or production suggestion. It replaces the buyer's spreadsheet of “last year plus a bit” with a repeatable calculation that updates every week.
You need it when stock decisions have become too many for one person to hold in their head. A kirana-style store with sixty items does not. A distributor carrying 1,500 SKUs from twenty suppliers, a garment wholesaler with thousands of design and size combinations, or a manufacturer planning raw material for seasonal orders almost certainly does.
The signs are easy to spot: money locked in slow-moving stock while fast movers sell out; emergency purchases at worse rates; a godown that is full and empty at the same time. Forecasting does not remove uncertainty, but it makes each buying decision start from evidence rather than habit.
- Retailers with many SKUs across one or more stores
- Distributors and stockists buying from several principals
- Manufacturers planning raw material and finished goods
- Online sellers managing stock across marketplaces and their own store
How demand forecasting cuts dead stock and stockouts together
Dead stock and stockouts look like opposite problems, but they share a cause: buying the same way for every item. Forecasting splits the catalogue so each item gets the attention it deserves.
Fast movers need frequent, accurate forecasts and a safety buffer, because a stockout costs a sale today and often the customer tomorrow. Slow movers need the opposite: smaller, less frequent orders and a hard look at whether they belong in the range. Items that sell only in a season need an early buy and a planned exit before the season ends.
Good demand forecasting software makes these differences visible in one report. It ranks SKUs by value and movement, often as ABC (value) and XYZ (predictability) classes, and applies different rules to each. The owner then sees, for example, that 200 items drive most of the revenue and deserve weekly attention, while 600 items have not sold in months and are tying up cash.
What forecasting cannot do is fix a supplier who delivers late, a product nobody wants, or stock that exists in the software but not on the shelf. We check stock accuracy during setup because a forecast built on wrong closing balances will buy wrongly with great confidence.
Buy or build demand forecasting software: a decision rule
Buy first when your ERP is well supported, your demand follows common patterns and you want a ready interface quickly. Build when the data or the seasons make packaged tools awkward, or when you want to stop paying per user for something central to your business.
Choose a packaged tool when
Your stock system is a mainstream cloud ERP or store platform that the vendor connects to out of the box, your team is comfortable with a new interface, and a trial on your own data gives forecasts your buyers accept. Check pricing for your SKU count and number of users, and ask how you export your data if you leave.
Choose a custom build when
Your stock lives in Tally, Busy or a mix of spreadsheets; your peaks follow festival and wedding dates that shift every year; you need forecasts in a particular format, such as by supplier and godown; or you want the logic and data fully in your hands. A pipeline from ₹40,000 is often enough to start.
Choose neither yet when
You carry under a hundred active SKUs with steady sales, or your stock records are unreliable. Clean up closing balances and item masters first; a simple min-max rule may serve you for another year.
What data does demand forecasting software need?
At minimum: sales quantity by SKU by day or week, stock on hand, and supplier lead times. Two years of sales history is ideal because it contains two of each festival season; one year works with more caution.
In a Tally-based business most of this already exists. Sales vouchers give quantity and date per stock item; stock items and godowns give the catalogue and locations; purchase orders give open quantities; and supplier lead times can be calculated from the gap between purchase order and receipt dates. The main cleanup tends to be item masters: the same product created twice, sizes stored as separate items in one year and as variants the next, or discontinued codes still marked active.
Useful extras include promotions and discount periods, stockout days (sales of zero because the shelf was empty, not because nobody wanted it), new product launch dates, and price changes. Stockout days matter most. If the system treats an empty-shelf week as zero demand, it will forecast low, order low and create the next stockout.
- Sales quantity per SKU, per location, per day or week
- Stock on hand and open purchase orders
- Supplier lead time and minimum order quantity
- Price changes, schemes and promotional periods
- Days an item was out of stock
- Launch and discontinuation dates
Festival and wedding-season demand: forecasting India's moving peaks
Indian retail peaks do not sit on fixed calendar dates, and that is the single biggest reason generic forecasts go wrong here. Diwali follows the Hindu lunisolar calendar, so it can fall in October one year and November the next; Eid moves through the Gregorian year; wedding demand clusters around auspicious dates that change annually.
A model that only knows “October was big last year” will stock up in the wrong weeks. The fix is an event calendar: each festival, school reopening, harvest period and your own sale dates recorded with its actual date for past and future years. The model then learns “the three weeks before Diwali” rather than “October”.
Open-source tools support this directly. Prophet, released by Facebook's Core Data Science team and available in R and Python, describes itself as fitting non-linear trends with yearly, weekly and daily seasonality plus holiday effects, which suits moving festival dates. We often use it or a similar method as one candidate, alongside simpler approaches.
Region matters too. Onam drives Kerala demand, Durga Puja drives Bengal, Pongal drives Tamil Nadu, and wedding peaks differ between north and south. For businesses selling across states, the calendar is maintained per region.
Which forecasting models does demand forecasting software use?
The right model depends on each SKU's sales pattern, and good software tests several rather than trusting one. Every method must beat a simple benchmark before it earns a place.
The textbook Forecasting: Principles and Practice by Rob Hyndman and George Athanasopoulos recommends exactly this: compare any new method with simple ones such as the seasonal naive method, which forecasts each period as equal to the same season last year, and if the new method is not better, it is not worth considering. We report that comparison for your data in plain language.
Beyond benchmarks, the usual candidates are exponential smoothing (ETS) for items with steady trend and seasonality, ARIMA for series with more complex patterns, Prophet-style models for strong holiday effects, and gradient-boosted “global” models that learn across many SKUs at once using price, promotion and event features. Global models are useful when individual items have short histories, such as new designs in fashion.
- Seasonal naive: the benchmark every model must beat
- Exponential smoothing: steady sellers with regular seasons
- ARIMA: longer histories with more complex patterns
- Prophet-style: strong, moving festival effects
- Gradient-boosted global model: many SKUs, short histories, promotions
- Croston-type methods: slow, lumpy, intermittent items
Forecasting slow movers and spare parts
Slow movers need different treatment, because weeks of zero sales break most standard methods. A spare part that sells two units, then nothing for five weeks, then four units, is not noise around an average; it is intermittent demand.
Forecasting: Principles and Practice explains Croston's method, a widely used approach that splits such a series into the size of non-zero demands and the time between them, forecasts each with simple exponential smoothing, and divides one by the other. The same text notes its limits: it has no underlying stochastic model for prediction intervals and is known to be biased. So we use it, or its variants, carefully and check results against actual sales.
For many slow movers the better business answer is policy rather than prediction. Keep a minimum of one or two units if the item is important to customers, order only against confirmed demand if it is not, and flag items for discontinuation when they have not moved for a period you choose. Demand forecasting software should make those policies explicit per item rather than hiding them inside a formula.
From forecast to reorder point and safety stock
A forecast becomes useful only when it turns into an order quantity. The standard bridge is the reorder point: expected demand during the supplier's lead time plus a safety stock for uncertainty.
Say an item is forecast to sell 20 units a week and the supplier takes three weeks to deliver. Lead-time demand is 60 units. Safety stock depends on how much demand and lead time vary and on the service level you want; high-value A items might target fewer stockouts than C items. If safety stock works out at 15 units, the reorder point is 75. When stock on hand plus open orders falls to 75, the software suggests an order, rounded to the supplier's minimum or case size.
These numbers are illustrative, not a benchmark for your business. The point is that every suggestion in the software should show its working: forecast, lead time, safety stock, stock on hand, open orders. Buyers trust what they can check, and a purchase manager who can see why the system wants 120 cartons will either accept it or override it with a reason that improves next month's model.
- Reorder point = demand during lead time + safety stock
- Order quantity respects minimum order, case size and budget
- Different service levels for A, B and C items
- Lead times measured from real purchase order and receipt dates
Connecting demand forecasting software to Tally, ERPNext or your ERP
Forecasts should read from and write back to the system your accountant and godown staff already trust. Otherwise two versions of stock appear, and people stop believing either.
For TallyPrime, Tally Solutions' own integration documentation lists JSON, XML and ODBC as ways for other applications to exchange data, including syncing sales, inventory and accounts. We use those to pull stock items, godowns, sales and purchase vouchers on a schedule, usually overnight. Reorder suggestions can be returned as a report, a Google Sheet or draft purchase orders for a buyer to confirm; we avoid posting vouchers into your books automatically unless you explicitly want that.
ERPNext and Odoo have documented APIs, so forecasts and reorder levels can be written into item records directly. For marketplace sellers, sales exports from each channel are combined so a SKU sold on three platforms is forecast once. If you are still choosing an ERP, our comparison of Odoo and ERPNext covers inventory features, and Tally to Google Sheets covers the lightest option.
How to track forecast accuracy in demand forecasting software
Measure accuracy every week on the forecasts that were actually used, grouped by category, supplier and ABC class. A single company-wide percentage hides the items that matter.
Choose metrics carefully. Forecasting: Principles and Practice warns that MAPE, the popular mean absolute percentage error, becomes infinite or undefined when actual sales are zero and gives extreme values when they are close to zero, which is common for slow movers. For a catalogue with many such items, weighted error across a group (often called WAPE) or the scaled error MASE, which the same text recommends for comparing across series, are safer choices.
Bias matters as much as error. A forecast that is consistently 10% high builds dead stock slowly; one that is consistently low causes repeated stockouts. The dashboard should show both, plus the business outcomes you care about: stockout days, stock cover in days and value of non-moving stock. When buyers override the forecast, record the reason and measure whether the override beat the model. That record is the fastest way to improve both.
How much does demand forecasting software cost in India?
Packaged demand forecasting software is usually a recurring subscription priced by users, SKUs or locations, and quotes vary widely between vendors, so compare them on your own catalogue size. A custom build with BtechWaleTech is a one-time project plus optional upkeep.
A forecast pipeline that reads your data, forecasts SKUs weekly and writes reorder suggestions to a Sheet or ERP starts at ₹40,000 (US$600). A purchase planning web app with logins, approvals, overrides and accuracy dashboards starts at ₹60,000 (US$900). Both include 2 months of free upkeep; after that maintenance starts at ₹8,000/mo.
- Number of SKUs and locations to forecast
- Data sources: Tally only, or Tally plus marketplaces and a POS
- Item master cleanup needed before forecasting
- Output: Sheet and report, or write-back to ERP
- Screens, user roles and approval steps for buyers
- Forecast frequency: weekly batch or daily updates
Your quote itemises these, arrives in about 2 working days, and nothing is billed before your written approval. The pricing page lists every plan's starting price.
Build timeline: from Tally export to first purchase suggestions
A forecast pipeline usually goes live in 2–4 weeks once data access is ready; a full planning app takes 6–12 weeks. Most of the early time goes into item masters and stock accuracy, not the model.
Week 1: data and catalogue review
Sales, stock and purchase history are pulled, duplicate items and variants mapped, stockout periods identified and the event calendar drafted with you.
Week 2: back-testing
Candidate methods are tested on past seasons they did not see, including last Diwali or last wedding season, against the seasonal naive benchmark.
Week 3: reorder rules
Lead times, minimum order quantities and service levels by ABC class are agreed, and the first reorder list is produced for your buyer to review.
Week 4: go-live
The weekly schedule is switched on, suggestions land in the chosen Sheet, report or ERP, and the accuracy dashboard starts recording.
Following months
Overrides and errors are reviewed monthly, the calendar is updated for the coming year, and models are refitted as new data arrives.
Another of us handles data and models, one of us builds integrations and any buyer screens, and the third of us runs the schedule and your weekly review call.
Owning your demand forecasting software
Everything we build is yours: source code, forecasting scripts, the event calendar, documentation and the cloud account it runs on. There is no licence to renew and no per-user charge.
This matters because stock planning becomes more valuable the longer it runs. Two years of recorded forecasts, overrides and outcomes is an asset; with a subscription, that history can be hard to extract if you switch. With your own build, it sits in your database and your accountant or a future developer can read it.
Handover includes a written guide to the data flow, a list of every rule (service levels, minimums, event dates), and steps to update the calendar each year. After the 2 free months, you can keep us on maintenance from ₹8,000/mo, move it to an in-house developer, or run it as is.
Common mistakes when choosing demand forecasting software
Most disappointments come from the setup, not the algorithm. These are the mistakes worth avoiding whether you buy or build.
- Forecasting from sales that include stockout weeks, which bakes in shortages
- Using calendar months instead of actual festival dates
- Judging accuracy by one company-wide MAPE figure
- Ignoring supplier lead-time variation when setting safety stock
- Treating every SKU with the same model and service level
- Letting buyers override without recording why
- Buying a tool that cannot read your actual stock system
- Skipping an item master cleanup, so duplicates split demand
If a vendor or developer demonstrates forecasts without asking about your lead times, stockout history and seasons, they are showing a chart, not a planning system.
Worked example: a hypothetical Surat saree wholesaler
Say a Surat wholesaler sells sarees and dress materials to retailers across several states, with around 2,400 active design codes and stock records in Tally. The owner's complaint: every wedding season, bestselling designs run out in the second week while older designs gather dust.
Individual designs have short lives, so forecasting each code separately would fail. Instead, demand is forecast at the level of fabric, price band and colour family, using two years of sales with actual festival and wedding-season dates tagged. A gradient-boosted global model is compared with seasonal naive and exponential smoothing on the previous wedding season. Forecasts are then split down to individual designs in proportion to their early sales in the current season.
The output is a weekly Google Sheet: for each fabric and price band, the forecast, stock cover in days and a suggested reorder from the mill, adjusted for lead time. A second tab lists designs with no sales for a chosen period so the owner can plan clearance before the next season. Buyers override freely, but each override needs a note.
This scenario illustrates the approach and is not a client story or a result. Your categories, lead times and seasons decide the actual design.
Checklist before you buy or build demand forecasting software
Answer these before speaking to any vendor or developer. The answers decide whether you need software at all, and which kind.
- How many active SKUs and locations do you plan for?
- Where is sales and stock data kept: Tally, Busy, ERPNext, marketplace exports, Excel?
- Do you have two years of sales history, and do you know when items were out of stock?
- What are your main supplier lead times and minimum order quantities?
- Which festivals, wedding periods and sale events move your demand?
- Who places purchase orders, and how should they see suggestions?
- How will you measure success: fewer stockouts, less dead stock, lower stock value?
- Do you want to own the tool, or rent one?
Send your answers on WhatsApp and we will say honestly whether a packaged tool, a light pipeline or a full app fits. If automation of purchase orders themselves is the next step, see purchase order automation.
Demand forecasting software across India
Stock patterns differ sharply between India's trading and manufacturing centres, and we build for each remotely. Textile hubs such as Surat, Tiruppur and Ludhiana plan around fashion cycles, export orders and winter or wedding demand. Wholesale markets in Delhi and Kolkata juggle thousands of SKUs for retailers across whole regions. Warehousing clusters like Bhiwandi serve many clients' inventory at once. Craft and festive-goods towns such as Sivakasi, Firozabad and Moradabad live with extreme seasonal peaks.
Working remotely suits this kind of project because the inputs are data exports, not site visits. We discuss your catalogue on video calls in Hindi or English, share progress on WhatsApp, and deliver forecasts into Sheets, reports or your ERP. Payment is by UPI or bank transfer. What we do not do: physical stock counts, barcode hardware installation, or warehouse operations. Those need people on your floor.