Module

True Demand

What you would have sold if the shelf had never been empty.

Beta — live for pilot tenants₹22,000 / month
See pricing

What it produces

  • Every demand period marked in stock, censored, or too censored to recover
  • Days out of stock per period, replayed from your own movement ledger
  • The units and the money the recorded history understates by

A worked example

CB-LIP-014, August — recorded 620, true demand nearer 961
out of stock 11 of 31 days, replayed from the stock ledger
620 sold across 20 sellable days = 31 a day
31 a day over 31 days = 961, assuming demand was spread evenly
the history understates this month by ₹81,840

Illustrative figures. On your tenant the same page shows yours.

Why it is hard

The part that is not a report.

Recorded demand is a censored signal: it can only ever count what there was stock to sell. A month with a fortnight off-shelf does not report that half the demand went unmet — it reports a smaller number, indistinguishable from a quiet month. That is worse than a one-off error because it compounds in a direction nobody notices: a model fitted on that history learns the stockout as weak demand, forecasts lower, replenishes smaller and causes the next stockout, while its measured accuracy improves the whole time. This module replays your own stock movements to find the days each material could not be sold, corrects the periods where enough of the month was sellable to recover a rate honestly, and refuses the ones where it was not. What it does not do is judgement: the arithmetic cannot tell a stockout over a festival from one in a quiet fortnight, so every corrected period is shown beside the recorded one and a planner who knows better should overrule it.

Opened by the supply chain manager and the procurement lead — what each of them sees first.

Said before you ask

What we don’t do.

SIAARU decides from your records and nothing else. It carries no copy of the world’s data, states no figure your systems have not, and acts in nobody’s name. Where your data does not support an answer, it says so by name rather than producing a confident one — which is the whole reason a decision taken on it holds up later.

The uplift assumes demand was spread evenly across the period, and that is the method's whole weakness: a stockout over a promotion is not the same as one in a quiet fortnight, and this arithmetic cannot tell them apart. So every corrected period is shown beside the recorded one with its multiplier, and a period with too little of the month sellable is refused outright rather than recovered from noise. It does not write the correction back into your forecast — it tells you which periods a model should not be fitted to.

Where this sits

One of 35 modules, on one engine.

True Demand reads the same reconciled data as everything else SIAARU runs — connected read-only to your ERP, scored on the way in, measured in SQL. How that engine works is a page of its own. The other 34 modules, each with the state it is really in and the reason where it is not switched on, are on the module list; what this one costs, and what it costs beside the rest, is on the pricing page.

Get started

Bring one month of data. Leave with your own control tower.

A demo runs on your material master, your purchase orders and your stock — not on ours. Thirty minutes, and you see your own exceptions rather than a scripted one.

Ask a question

Book a demo

Thirty minutes, on your own data. Six fields — the rest only helps us prepare.

Not binding. Tell us the size and we will say which one fits.

The demo connects to it, so this shapes the whole session.

Add context, and the demo runs on your problem rather than a scripted one

We reply within one working day.