ERPNext demand forecasting with exponential smoothing: when planners need it
A production plan built only from open sales orders covers the demand customers have already committed to, and nothing else. Repeat demand for standard products often arrives without an order yet, so a planner who relies only on open orders will under-plan, then scramble with expedited purchases and rush work orders. ERPNext's Forecasting report addresses this gap by projecting future demand from past transactions. According to the ERPNext documentation, it can base its projection on historical sales orders, deliveries or quotations, so the first decision is which document type best reflects real consumption for each item group. Deliveries usually show what actually left the warehouse, while sales orders show what was committed and quotations show interest that may never convert.
Use the Forecasting report before running MRP when the same items sell in recognizable patterns over time and planners currently pad orders by feel. Reorder decisions for components, long-lead purchases and capacity bookings are where a forecast adds the most value, because those decisions must be made before customer orders arrive. Items with sporadic or project-based demand are poor candidates, and a forecast for them tends to produce phantom stock. Forecasts should feed planning as an input, not replace the customer order book, so confirm with the documentation for your ERPNext version how forecast figures are used by Production Plan and MRP, whether the options described here are available, and what the smoothing parameter does. Behavior varies between versions, so verify it in the documentation for the version you run before building any process around it.
Which demand source and smoothing setting fit each product family
This table compares the demand signal (sales orders, deliveries or quotations) and the smoothing approach that suit four product families: stable make-to-stock, seasonal, make-to-order and new products. Read each row for what the signal captures, what it misses, and what to confirm in the ERPNext documentation before you rely on the forecast in MRP.
| Product family | Best-fit demand source | What the signal captures and misses | What to confirm before adopting |
|---|---|---|---|
| Stable make-to-stock items | Deliveries, for actual shipped quantities | Captures what left the warehouse, so it reflects real consumption. Misses orders that were lost or backordered, which can understate demand. | Confirm how the Forecasting report reads delivery notes for your items, and whether a low smoothing constant gives steady output for your history length. |
| Seasonal items | Sales orders, with a review of the season window | Captures customer commitments by date, so timing shifts show up early. Misses seasonal peaks that the report does not model unless you adjust the period and forecast horizon. | Confirm the Forecasting report does not treat seasonality as trend, and test a higher smoothing constant against past seasons before you feed MRP. |
| Make-to-order items | Sales orders, filtered to the item and customer group | Captures confirmed orders that will drive production. Misses quotations that never convert, so forecasts can look thin when the pipeline is strong. | Confirm whether quotations or sales orders drive your Production Plan, and whether planned quantities should replace the forecast for these items. |
| New products | Quotations, as an early indicator | Captures interest before orders exist, which may be the only signal for a launch. Misses conversion rates and price effects, so quotation volume often overstates demand. | Confirm the history length the report needs, and set a manual planned quantity until enough sales orders exist to test the smoothing constant. |
| Items with intermittent demand | Sales orders, with a longer review period | Captures each order event, but long gaps between orders make exponential smoothing react unevenly. Misses the true pattern when orders are rare. | Confirm the output for zero-demand periods and compare it with planned orders before you accept the result in MRP. |
| Items with frequent order changes | Deliveries, with sales orders as a cross-check | Captures what shipped after changes were applied. Misses cancelled or amended quantities that were never delivered. | Confirm how amended and cancelled sales orders are excluded from the report, and reconcile a sample against your order book. |
Choosing the smoothing constant by demand pattern
When monthly volumes hover around a stable level, the forecast should mostly filter out noise. A lower smoothing constant gives older history more weight, so the forecast moves slowly and stays calm when one month spikes. A higher constant reacts quickly, which is useful only if the level has actually shifted. For steady items, a low-to-moderate value usually produces the smoothest forecast, but you should verify that against actual sales rather than assume it.
- Noise absorption: a lower constant keeps one unusually large order from pulling the next forecast up sharply.
- Lag after a real change: a low constant takes longer to follow a genuine step change, so watch for consistent under-forecasting.
- Backtest window: compare forecasts with actual sales over several past periods, not only the most recent one.
- Error measure: pick one measure, such as mean absolute error, and use it for every candidate constant.
- Review trigger: revisit the value when the product's sales level changes, not on a fixed calendar.
Confirm the allowed range and default smoothing constant in your ERPNext version before you set a value for each item group.
When sales rise or fall steadily over time, simple exponential smoothing lags behind the trend because each forecast is built from past levels. A higher smoothing constant narrows that lag by weighting recent periods more heavily, but it also makes the forecast more sensitive to random swings. The practical question is whether the trend is persistent enough to justify a faster response. Backtesting is the only reliable way to find the balance for a given item.
- Systematic lag: under a steady upward trend, forecasts that sit below actuals every period signal a constant that is too low.
- Overshoot risk: a high constant can chase a short promotion and then drop sharply afterwards.
- Trend-aware methods: if lag remains large, ask whether your version offers a trend-adjusted option before accepting a poor fit.
- Test on the recent window: weight the backtest toward the last several periods, since that is where the trend matters most.
- Seasonal confusion: a seasonal peak can look like a trend, so check whether the same pattern repeats each year before raising the constant.
Confirm which forecasting methods your ERPNext version offers for this report, and whether a trend or seasonal option exists, before concluding that a single constant is enough.
Items that sell in irregular bursts, or in some periods not at all, are hard to forecast with any smoothing constant. A high constant makes the forecast jump with each large order and then fall back to near zero, which then drives MRP to create uneven purchase or production signals. A low constant produces a stable figure that may hide real peaks. For these items, the smoothing constant is only one part of the decision, and the input history matters as much as the constant.
- Jumpy forecasts: a high constant turns one large customer order into a large forecast for future periods.
- Understated peaks: a low constant averages bursts away, which can leave you short when a big order arrives.
- Zero-demand periods: check how the report treats periods with no sales, since they affect the averages the constant smooths.
- Source document choice: confirm whether the forecast reads sales orders, deliveries or quotations, because each gives a different demand signal for the same item.
- Manual review: for items with few large orders, many teams keep a conservative constant and override the forecast with known customer commitments.
Confirm the report's handling of zero periods and the allowed constant range in your version, and agree with planners which items should bypass automatic forecasts entirely.
A new product has no sales history, so exponential smoothing has nothing to smooth. Any constant you choose will produce a forecast that is essentially a guess from the first available data, and the constant cannot be backtested meaningfully until several periods of actuals exist. The right approach is usually to plan these items from other inputs, such as quotations, customer forecasts or a comparable product's history, and to revisit the smoothing constant once real sales arrive.
- No backtest possible: without past actuals, you cannot compare candidate constants, so do not pick one on intuition alone.
- Proxy history: a comparable item with similar customers or channels can provide a starting pattern, if your team agrees the link is valid.
- Quotations as a signal: the forecast can draw on quotations, so check whether those are reliable indicators at your sales conversion rate.
- Transition plan: set a date or sales count after which the item moves to smoothing-based forecasts.
- Documented assumptions: record the source and the assumed level, so planners can revise it when actuals arrive.
Confirm with your ERPNext version how the Forecasting report handles items with too few periods, and whether it returns a usable figure or none at all.
Setup sequence from clean sales history to MRP input
This sequence turns past sales activity into a forecast that planning can trust. It produces a documented, tested forecast per item and warehouse, with the source document and smoothing constant recorded, before any figure reaches Production Plans or MRP. Each step ends with a check, so an error in master data or order history is caught before it inflates material requirements.
Confirm item and warehouse master data
Start by checking the Item and Warehouse records you plan to forecast. Confirm that each item is flagged as a stock item, that its stock UOM matches the units in which sales are recorded, and that the warehouse is the location where demand actually lands, since the forecast is keyed to both. Ask the item owner to confirm that sales units match planning units. Done when every item in the test list opens without missing fields and each warehouse appears once in the register you are working from.
Clean or exclude one-off and test orders
Review the sales history for each item and warehouse and mark orders that will distort the trend: test orders, samples, one-time bulk deals and orders later cancelled. Decide with sales operations whether to exclude these or to correct them at source, and record each decision in a short exclusion list. Reconcile the remaining order count and quantity against the sales register for the same period. Done when the cleaned list is approved and its totals tie to the register, with every exclusion explained.
Pick the source document for the forecast
Choose whether the forecast is based on Sales Orders, Delivery Notes or Quotations. Sales Orders reflect committed demand, Delivery Notes reflect what has shipped, and Quotations reflect pipeline that may or may not convert. Use the same basis you will later compare against actuals, and note it in the planning record. Check that the chosen document type holds the items and quantities from your cleaned list. Done when the basis is written down and a sample of source documents matches the cleaned list.
Run the Forecasting report for a test period
Run the Forecasting report in ERPNext for one item and warehouse over a past test period, using the source document and smoothing constant you chose. Keep the horizon short enough that you already hold actual orders to compare against. Confirm the parameter names and options in your version, since menus and labels change between releases. Export the output and save the run settings alongside it. Done when you have a saved forecast for each period with the settings recorded beside it.
Compare forecast output with actual sales
Set the forecast for the test period against actual orders from the same source document, item and warehouse. Calculate the gap for each period and in total, and reconcile the actual total to the sales register using identical cut-off dates. Look for systematic bias, where the forecast runs consistently high or low, as well as single-period misses. Done when the actuals reconcile to the register and the bias and error are recorded for each item in the sample.
Adjust the smoothing constant and retest
If bias or error exceeds the tolerance the business has agreed, adjust the smoothing constant. A higher constant weights recent periods more heavily and reacts faster to change, while a lower constant smooths noise and responds more slowly. Rerun the same test period with the same source document and compare the new errors with the first run. Keep the constant that performs best, and record who approved it and why. Done when the retest is documented and the approved constant is stored with the item's planning notes.
Feed the approved forecast into MRP
Only after the earlier checks pass, use the approved forecast as demand input for the Production Plan or MRP run covering the tested items. Confirm with the planner how forecast figures are pulled into the plan, and check that sub-assembly demand flows through the BOMs as expected. Make sure open sales orders are not counted twice alongside forecast demand. Run a small plan and reconcile planned quantities back to the forecast totals and the open order book. Done when the requirements tie out without unexplained differences and the planner signs off the sample items.
Feeding forecasts into MRP without counting demand twice
The main planning risk in this section is double counting. A forecast line and an open sales order can describe the same customer demand, so if both feed the same material requirements calculation, the plan orders too much stock and too many work orders. Before you include any forecast in planning, decide which demand each horizon represents. A common approach is to let confirmed sales orders drive the near term and to let the forecast cover only the period beyond the firm order book, so the two sources never overlap on the same dates. This split is a planning policy you set, not a switch in the software, and it should be written down before the first run.
Choose the forecast horizon from your lead times and how far your customers commit. Items with long purchasing or production lead times need forecasts that reach past the point where orders are typically placed, while make-to-order items with short lead times may need forecasts only for a few weeks. Review the horizon per item group rather than applying one cut-off to the whole catalogue. Record the cut-off date for each group so that planners can see which demand came from orders and which came from the forecast.
Separate forecast-driven planning from order-driven planning in the Production Plan. Confirm in the ERPNext Production Plan documentation for your version how forecasts are pulled in, which document types are read, whether forecast quantities are included by default, and how existing sales orders are netted against them. Test this with a small sample item in a non-production site, comparing the planned quantities with a manual calculation. Only then should the approach be applied to the full item master.
Access, audit and data quality controls for forecasts
A forecast is only as trustworthy as the people who can run it, the data it reads and the record of what changed. The cards below cover who can run the Forecasting report and edit planning inputs, how role permissions limit sales and cost visibility, how smoothing changes and manual adjustments are recorded, how historical data is protected, and how forecast runs are reviewed before MRP uses them. Confirm each point against the ERPNext version you deploy, because role names and defaults change between releases.
Who can run the Forecasting report
Running the Forecasting report and changing the planning inputs that feed it, such as the smoothing constant and the period filters, should sit with a named planning role, not with every user who can open Stock or Selling. Confirm which roles in your deployed version can open the report, and whether any of them can also create or submit the Production Plan that consumes its output. Separate the people who set forecast parameters from the people who approve purchase or production actions based on them.
Role permissions on sales and cost data
Sales orders, deliveries and quotations drive the forecast, and item valuation and cost fields can reveal margins to people who should not see them. Use ERPNext role permissions and user permissions to limit which customers, items and warehouses a planner can read, and check that the report does not expose rate or valuation fields to roles without cost access. Test this with a non-administrator account, because System Manager access bypasses most of these restrictions.
Recording smoothing and manual adjustments
Changing the smoothing constant or overriding a forecast figure changes what MRP will buy and make, so each change needs a record of who made it, when and why. Decide whether the team keeps a version history through ERPNext's document versioning on the planning documents, a change log in a controlled spreadsheet, or both. Confirm that document versioning is enabled for the doctypes where adjustments are saved, and that the reason for each override is a required field or a documented convention.
Protecting historical data in backups
Forecasts depend on years of submitted sales orders, deliveries and quotations, and a corrupted or lost history produces confident but wrong predictions. Schedule database and file backups that cover the full site, and test restores on a separate environment to confirm that the historical transactions and the planning records come back together. Ask your hosting team which backup retention applies to the site, and confirm where copies are stored and who can access them.
Reviewing each forecast run
Before a forecast feeds a Production Plan or material request, a second person should compare the output with recent actual demand, check for items with sparse or unusual history, and confirm that cancelled or test orders were excluded. Record the review outcome against the run, and agree a threshold for when a planner must explain a large change from the prior run. This review is a process control your team designs; it is not an audit or certification.
Limits to confirm in your ERPNext environment
Before a team relies on exponential smoothing from the Forecasting report, it should test where the method breaks down in its own data. Smoothing needs a usable history of sales orders, delivery notes or quotations for each item and warehouse combination that feeds the forecast. Short histories, new products and items with long gaps between orders give a forecast that looks precise but rests on very few observations. Run the report on a sample of items with known demand and compare the output against what actually shipped before you let it drive purchasing.
Intermittent demand and promotion-driven demand are the cases most likely to mislead a single smoothing constant. Items that sell in occasional large lots, or that spike during campaigns, will push the forecast up after each spike and then decay slowly, which can lead MRP to over-order. Plan for a separate treatment of these items, such as manual overrides, promotion calendars or a different method, and document which items are excluded. Multi-company and multi-currency sales also need a deliberate choice: confirm whether the report filters by company, how amounts are converted, and whether quantities from different companies or units of measure are mixed into one series.
Returns, credit notes and cancelled documents distort the signal in ways the report does not necessarily correct for you. Decide with your finance and sales operations leads which document types count as demand, and whether returns net against the original period. Confirm how cancelled and draft documents are handled in your version. For performance on large histories, measure report run time on a copy of production data before go-live, and confirm report limits, filter behavior and any version-specific changes in the ERPNext documentation and the ERPNext release notes for the version you run.
What buyers ask before using ERPNext forecasting
What does a demand forecasting project cost and what drives the effort?
Cost depends mostly on the state of your data and the number of item families you want to forecast, not on the ERPNext licence, which is free under GPL-3.0. Self-hosting carries no software fee, so the spend is labor: data cleanup, configuring the forecast settings, backtesting results against past periods, and training planners. Effort rises with messy sales history, inconsistent item codes, and many product families that each need their own review. Ask any partner for a quote built from a written scope that lists which item families, which document types (sales orders, deliveries or quotations) and how much backtesting is included. One-time work covers setup and cleanup; ongoing planner time recurs every planning cycle.
How long does a first forecasting pass take?
The duration depends on how good your history is, and no fixed timeline applies across organizations. A team with clean, consistently coded sales history and a short list of item families will move faster than one that must first reconcile cancelled orders, returns and renamed products. Plan the first pass in stages: confirm the data extract, run the forecast for a pilot family, compare it with actual demand over past periods, then widen. Ask your partner to state which stages are included in the fixed scope and what must be ready before each one starts.
What must our team provide before the forecast work starts?
Three things decide whether the forecast is usable: clean sales history, accurate item master data, and planner time. Sales history should cover the documents the forecast will read, with cancelled and duplicate orders removed or flagged. Item master data needs correct item codes, item groups, units of measure and any variants or replacements, because a renamed item splits its history. Planners must review forecasts, challenge outliers and approve the figures that flow into MRP. Name a business owner who can decide on exceptions, since no forecast is accepted without someone signing off the output.
Can our internal staff set up ERPNext forecasting without a partner?
Yes, a capable internal team can configure the Forecasting report and run exponential smoothing on its own, because the feature sits inside ERPNext and the code is open source. The harder part is the judgment: choosing a smoothing constant, testing it against history, and knowing when a forecast is misleading. Staff who already administer ERPNext, understand their sales cycle and can dedicate planning time usually cope best. Confirm that the people who will own the forecast have the time and skills, and that someone can maintain the setup through ERPNext upgrades.
When should we bring in an implementation partner for forecasting?
Bring in a partner when the forecast will feed production planning across several product lines, when history is spread over multiple companies or systems, or when your team lacks someone to run backtesting. A partner also helps when forecasts must be tied to purchasing and MRP decisions that affect cash and supplier commitments. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, and works from a written scope agreed before work starts. Ask for the deliverables, the backtesting method, the training included and who keeps the setup working after go-live.
How do we know if the forecast is accurate enough to use?
Judge accuracy by backtesting: run the smoothing method on past periods, compare each forecast with what actually sold, and review the error for each item family. Accuracy is a property of your data and product mix, so no universal target applies. Look for items with erratic demand, recent product launches, or seasonal patterns, since simple exponential smoothing does not model seasonality on its own. Treat the forecast as an input for planners, not a final order quantity, and review exceptions every cycle. Ask your partner which error measures they will report and how the results will be documented.
Does ERPNext forecasting meet our compliance or security obligations?
The Forecasting report itself is a planning feature, not a compliance control, so it does not by itself address regulatory obligations. Where forecasts influence production in regulated sectors, your compliance team should confirm how the forecast is documented, who can change its inputs, and how changes are logged. ERPNext's role and permission model can restrict who edits sales history and forecast-related records. Confirm requirements for your sector with your compliance lead and the relevant standard or regulator before relying on the system in a controlled process.
How DeployOpen scopes and delivers forecasting in ERPNext
DeployOpen plans, configures and hands over ERPNext demand forecasting inside your own infrastructure, starting from the sales history your team already keeps. We agree the forecasting method, data sources and MRP link in writing before any build starts, then document and test the result so your planners can run it without us.
How we scope
- Review which sales orders, deliveries or quotations hold usable demand history for each item group
- Agree the forecast horizon, item and warehouse levels, and how forecasts will feed MRP
- Define who owns smoothing constant choices and how forecast accuracy is reviewed
- Record the scope, deliverables and timeline in writing before work starts, as engagements are fixed-scope
How we build
- Configure the Forecasting report inputs and check the historical data for gaps, duplicates and cancelled documents
- Test candidate smoothing constants against held-back history and document the values chosen
- Connect forecast outputs to Production Plan and MRP settings in a staging site before production use
- Run the build on the ERPNext version and hosting model your organization operates
How we hand over
- Deliver a written configuration record covering data sources, smoothing settings and MRP links
- Provide a test log showing forecast results compared with actual demand for agreed items
- Document the planner procedure for reviewing, overriding and approving forecast figures
- Train the planning and supply chain staff who will operate the forecast after go-live
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer
- Review forecast accuracy periodically and propose changes to smoothing settings with evidence
- Plan and test changes when ERPNext minor or major releases affect the Forecasting report or MRP
- Confirm with your team which support scope and response arrangements apply before signing
