The problem
Price oversight in procurement and retail is the kind of work that compounds when ignored. A supplier raises a price quietly; the team approves the PO at the new price; the variance shows up months later when someone runs the report. By then the cumulative exposure is in the tens or hundreds of thousands. The variance is detectable at posting time — the data has the historical price band — but the AP clerk doesn't notice because the new amount looks plausible.
The same data that detects the variance can also estimate the fair price for a new SKU or a new supplier. "What should this Acme widget cost given the catalog, the supplier mix, and the historical price band for similar SKUs?" The conditional expected value is computable; the team is just not asking.
How it works
In the e-commerce demo the fair-price band is plain arithmetic on each SKU's realised prices: mean ± 1.5σ. A list price outside it is flagged only when the band rests on at least six observations, so a band from two sales is not presented as a finding. Supply shows the band on every row and lists the outliers.
What a price would do is the prediction. The Product view's Pricing tab sends one _estimate of units_index per list price (the regression model, with the product and the price in the where) and turns the units into revenue and profit. A price the product has not been sold near gets no number, so the best price is picked among the prices the data has seen. The discount what-if beside it is _predict purchased on impressions, once per discount band.
{
"from": "monthly_sales",
"where": {
"product_sku": "SKU-PT-0003",
"price_index": 1.0
},
"estimate": "units_index",
"model": "regression"
}For the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application.
See it live
This use case runs in the 🛒 E-commerce demo today. Click through to the live application and inspect the queries that produce the result.
Frequently asked
How does this compare to dedicated procurement-analytics SaaS?
Dedicated tools have richer dashboards (waterfall charts, supplier scorecards) and more sophisticated variance categorisation. _estimate is the prediction primitive; the dashboards live in your existing reporting. The two compose: Aito does the math, your BI tool does the visualisation.
What about catalog items with no price history?
In the demo a band from fewer than six sales is not judged at all, and a price the product has not sold near gets no estimate. A prediction can lean on similar SKUs, suppliers and categories, but with wider bands. New-SKU prices are surfaced as suggestions, not anomalies.
How does this handle bulk-discount tiers?
Add order_qty to the where clause; the predicted price conditions on quantity. Bulk-discount bands emerge from the conditional probability automatically. For SKUs with very tiered pricing, the prediction respects the tiers as long as the historical data shows them.
Can the prediction recommend a counter-offer price?
Yes — the predicted fair-price band IS the counter-offer reference. The buyer sees "this supplier quoted X; predicted fair-price band is Y to Z; variance of N%." The negotiation conversation has a citable anchor instead of an intuition.
Does this work for service catalogs (consulting rates, SaaS pricing)?
Yes. _estimate works on any numeric column. Consulting rate per role, SaaS price per tier, license fee per seat — all run the same conditional-probability machinery against the historical pricing data.
