AI and forecasting
What an AI-Driven ERP Actually Does for a Growing UAE Business
Forecasting, anomaly detection and automation explained with real workflows, plus the data you need in place first.
· 8 min read
Key takeaways
- AI demand forecasting learns from history, so clean data comes first: one code per product, consistent units and returns kept apart.
- Flag stock-outs and promotions, or the model learns false lows and false peaks.
- Ramadan and Eid move about 11 days earlier each year, so give the model an event calendar, not just month numbers.
- Track MAPE and bias together, and compare the model with a simple benchmark before trusting it.
- Start with one category, run the forecast in parallel, then connect it to reordering rules with human review.
AI demand forecasting promises fewer stock-outs, less dead stock and purchase orders that follow real demand. For UAE retailers and distributors that is an attractive promise: long import lead times, thin margins and a calendar shaped by Ramadan, Eid and the summer make guesswork expensive. But a model is only as good as the history it learns from, and most ERP sales data was never recorded with forecasting in mind.
This guide covers the groundwork: the data you need first, the right level of detail, how to measure accuracy with MAPE and bias, how forecasts should feed reordering rules, when planners should override the model and how to start small.
What AI Demand Forecasting Actually Does
A forecasting model looks for patterns in past demand, such as trend, weekly and yearly seasonality, holiday effects, promotions and price changes, and projects them forward for each product and location. Machine learning models can combine many of these signals at once, including ones a spreadsheet would ignore, and express the forecast as a range rather than a single number.
What a model cannot do is find information that is not in the data. If stock-outs are recorded as zero sales, promotions are not flagged and one product appears under three codes, the model learns the wrong lessons with great confidence. That is why the data work comes first.
Start with Clean Sales History
Demand is what customers wanted; sales are what you managed to sell. The closer your history gets to demand, the better the forecast. Before any model sees your data, work through this checklist:
- Enough history. Aim for at least two full years where you can, so every season and holiday appears more than once.
- One code per product. Merge duplicates and link replacement items to the products they replaced, so a new code inherits its predecessor's history.
- Consistent units. Convert cartons, packs and pieces to one base unit before comparing periods.
- Returns kept apart. Record returns as returns, not as negative sales on a later date.
- Unusual orders flagged. Mark one-off bulk orders, tenders and inter-company transfers, so they do not inflate normal demand.
- Prices and discounts recorded on every line, so the model can see how price affects volume.
- Channel and location kept. Store, warehouse, online and wholesale demand behave differently.
If that history is scattered across spreadsheets and a basic accounting package, consolidating it comes first; our article on the signs you have outgrown spreadsheets explains when an ERP becomes worth it.
Flag Stock-Outs, or the Model Learns That Nobody Wanted the Product
When a product is out of stock, sales drop to zero, but demand does not. If those weeks go into the model as zero sales, the forecast falls, you order less and the next stock-out arrives sooner. Forecasters call this censored demand.
A simple worked example: a product normally sells about 100 units a week. It is out of stock for two weeks in a ten-week period, so recorded sales total 800 units, an average of 80 a week. Plan on 80 and you are 20 units short every week, which makes the next stock-out more likely.
The fix is to record availability alongside sales. Your ERP knows the quantity on hand by day and location, so mark every product, location and day with zero stock, and let the model either exclude those days or estimate the lost demand. Lost-sale records from the counter, or orders you could not fill, are even better.
Have a question about this guide? Ask the engineers who wrote it.
Promotions, Prices and Events
A promotion lifts sales while it runs, often pulls demand forward from the weeks after and can take sales from similar products. If the history does not say when promotions ran, the model treats the spike as normal demand and over-forecasts the same weeks next year. For each promotion, keep:
- the products and locations included;
- the start and end dates;
- the mechanism, such as a price cut, a multi-buy or a free gift;
- the promoted price against the normal price;
- any display, leaflet or online support.
Keep a separate log of events outside your control, such as a competitor opening nearby, a road closure or a supplier shortage, so that both the model and the planner can explain the past.
UAE Seasonality: Ramadan, Eid, Summer and the Shopping Calendar
Seasonality in the UAE does not follow the Gregorian calendar alone. Ramadan, Eid al-Fitr and Eid al-Adha follow the Hijri calendar and are confirmed by moon sighting, so they move about 11 days earlier each year. In the UAE in 2025, Ramadan began on 1 March and Eid al-Fitr fell on 30 March; in 2026, Ramadan is expected to begin in mid-February, subject to moon sighting.
A model that only knows the month will look for the Ramadan effect in March next year and miss it. Give it an event calendar with the actual dates instead, including the days before and after each event, because demand for many categories changes in the run-up to an event, not only during it. Other patterns worth encoding:
- Summer: heat, school holidays and residents traveling abroad change both the volume and the mix of demand.
- Back to school: late August and September for stationery, uniforms, electronics and lunchbox lines.
- National Day and year-end: 2 December, followed by the winter shopping festival season.
- Pay cycles: month-end salary dates for consumer-facing retail.
- Weather and tourism for outlets that depend on visitors or outdoor activity.
The UAE government portal lists the official public holidays, a good starting point for the calendar.
Choosing the Right Granularity
The level at which you forecast decides both accuracy and usefulness. Detailed forecasts are noisier; aggregated ones are steadier but cannot place an order.
| Level | Good for | Watch out for |
|---|---|---|
| Product, location and day | Fresh and perishable lines in busy stores | Very noisy for slow movers |
| Product, location and week | Replenishment for most retail and distribution | Needs reliable stock-out flags |
| Product and month | Supplier orders with long import lead times | Hides short peaks such as Eid |
| Category and month | Budgets, buying plans and capacity | Cannot be ordered directly |
Many businesses forecast at product and week for replenishment, then add the results up to check them against category plans. Slow movers that sell a few units a month are often better served by simple rules, or forecast at group level, because a model has little to learn from them.
Measuring Forecast Accuracy: MAPE and Bias, Explained Simply
Two measures cover most needs. MAPE, the mean absolute percentage error, is the average size of the error as a percentage of actual demand, ignoring whether the forecast was too high or too low. Bias shows the direction: total forecast minus total actual, divided by total actual. A positive bias means you over-forecast and build stock; a negative bias means you under-forecast and run short.
| Week | Forecast | Actual | Error | Absolute % error |
|---|---|---|---|---|
| 1 | 100 | 90 | +10 | 11.1% |
| 2 | 100 | 110 | -10 | 9.1% |
| 3 | 120 | 100 | +20 | 20.0% |
| 4 | 110 | 100 | +10 | 10.0% |
| Total | 430 | 400 | +30 | MAPE 12.6% |
Over these four weeks the MAPE is about 12.6% and the bias is +7.5%, that is 30 divided by 400. The errors are moderate, but the forecast leans high, so stock will build up unless the model is corrected.
Three practical points. MAPE breaks down when actual demand is zero or very small, so for slow movers use a weighted version, total absolute error divided by total actual demand, which here is 50 divided by 400, or 12.5%. Measure accuracy at the level and horizon where decisions are made, usually product and week over the supplier lead time. And always compare the model with a simple benchmark, such as the same week last year or a moving average: if it cannot beat the benchmark, it is not adding value. The free textbook Forecasting: Principles and Practice explains these measures in more depth.
From Forecasts to Reordering Rules
A forecast only pays off when it changes what you buy. The usual link is the reorder point: order when stock on hand plus stock on order falls to the demand expected during the supplier lead time, plus safety stock for uncertainty.
A worked example: a distributor forecasts 120 units a week for a product with a three-week lead time and keeps one week of safety stock. Three weeks of demand (360 units) plus one week of safety stock (120 units) gives a reorder point of 480 units. If it orders every two weeks, the order-up-to level is 480 plus 240, or 720 units. In a reordering rule, those become a minimum of 480 and a maximum of 720, rounded to the supplier's carton or pallet quantity.
When the forecast changes, for example ahead of Ramadan, the minimum and maximum should change with it. Odoo Inventory, for instance, keeps a minimum and maximum per product and location in its reordering rules, and can either create a request for quotation automatically or list the need in its replenishment report for a buyer to review. In StarBiz, reorder rules and min/max levels sit alongside AI reorder suggestions based on consumption, lead time, cost changes and target margin, and a person can always review them.
Human Overrides: When Planners Should Step in
Planners know things the history does not: a new tender, a store opening, a product being delisted, a supplier rationing stock or a promotion planned for next month. Overrides for reasons like these improve the forecast. Overrides because a number looks high usually do not.
- Record every override with the planner, the date and the reason.
- Measure the accuracy of the model and of the overridden forecast separately.
- Review overrides monthly and keep only the kinds that help.
- Set thresholds, so small changes apply automatically and large ones need approval.
Start Small: A Pilot in One Category
Rather than switching every product to AI forecasts at once, run a pilot:
- Pick one category or one warehouse with steady demand and at least two years of history.
- Clean its data, including stock-out flags and the promotion calendar.
- Measure the accuracy and bias of your current method as the baseline.
- Run the AI forecast in parallel for at least one full replenishment cycle, without acting on it.
- Compare the results, then connect the better forecast to the reordering rules for that category only.
- Extend to the next category once the gains hold, and keep measuring.
The clean-up pays off even before a model goes live, because ordinary stock and sales reports become more reliable. Our article on what an AI-driven ERP does for a growing UAE business covers the other prerequisites, including role-based access and keeping a human in the loop.
How Star Bit Solutions Can Help
Star Bit Solutions builds and implements ERP for UAE retailers and distributors from Ajman. We can:
- audit your sales, stock and promotion history and fix the gaps a model would trip over;
- set up demand forecasting in StarBiz, whose time-series models project demand per product from your sales, seasonality and lead times, with confidence ranges;
- connect forecasts to reorder rules, with thresholds and approvals your buyers control;
- prepare the same groundwork in Odoo Enterprise or Community through OdooStar if you already run Odoo.
See how we approach trading and distribution, then tell us about your categories through the contact page, and we will suggest where a pilot would pay off first.
Written by the Star Bit Solutions team
Star Bit Solutions is a software company in Ajman, UAE, founded in 2014. We implement and customize Odoo Enterprise and Odoo Community, and build StarBiz (AI-driven ERP), StarHub (life super app), StarBot (conversational AI), StarLearn (adaptive learning) and StarSense (AI and IoT platform). About us
