Amazon Inventory Forecasting: Build a SKU Demand Estimate You Can Review

Quick answer: forecast demand before deciding what to order

Define the SKU, marketplace, unit and forecast dates. Reconcile sales with actual selling availability, build a simple comparable-period baseline, and record adjustments for known events. Compare frozen forecasts with later observations at the horizon you need. Send the result, assumptions and unresolved exceptions to a reviewer before translating demand into a replenishment decision.

Judge the process on six criteria: comparable inputs, availability-aware history, traceable adjustments, out-of-sample evaluation, visible uncertainty and accountable follow-up. A model is not useful merely because it produces an exact number. Someone must be able to explain what that number means, which conditions it assumes and what would make it unreliable.

Define the target: demand, recorded sales or a replenishment quantity

Choose one unit and one product boundary

Forecast units rather than revenue when the immediate task is inventory planning. A price increase can raise revenue without increasing the number of units customers require. Specify whether one unit means one sellable pack, one component or one case. A six-pack sale is not automatically six units of the SKU sold to the customer; component planning needs a separate conversion.

Keep marketplace and SKU mappings explicit. Combining child variations can hide a shortage in one size behind excess in another. Combining channels can be appropriate for shared-stock planning, but only after each order is counted once and the channel allocation is understood. Retain the underlying series so the aggregate can be explained.

Recorded sales do not reveal every unfulfilled request

Observed sales depend on whether a customer could buy the product and on the offer they saw. Zero sales during a verified stockout do not establish zero demand. Conversely, zero sales while a product was fully available may be important evidence of genuinely intermittent demand. Missing data is a third condition, not a synonym for either case.

If the immediate problem is inconsistent historical fields, first use the Amazon business report analysis guide. Forecasting cannot repair an unexplained switch from ordered units to shipped units or from one marketplace to several.

Match the horizon to the decision without confusing supply and demand

A forecast created today for next week answers a different question from one created today for the next twelve weeks. Record both the creation date and the periods predicted. Supplier production, transit and receiving time help determine how far ahead the business needs visibility; a late shipment does not by itself multiply customer demand.

Replenishment adds information a demand forecast does not contain: usable stock, commitments, inbound timing, supplier constraints and business risk choices. Even a sound 280-unit forecast is not an instruction to buy 280 units. A procurement decision also needs cost and contribution context; the SKU profitability guide addresses that separate review.

Assemble a source ledger before choosing a forecasting formula

Keep the raw export unchanged and build a dated working table from it. The following fields describe a planning dataset, not a promise that every Amazon report contains them together. Where a field comes from a separate operational record, retain its owner and timestamp.

Swipe horizontally to view all table columns.

Reconcile totals before investigating patterns

For a selected period, match the working table total to its chosen source. Investigate differences before fitting a model. A pipeline that reads the same export twice can create a convincing but fictitious sales spike. A date boundary mismatch can shift units between weeks without changing the monthly total.

Keep returns separate from the chosen demand target unless the target explicitly calls for net units. A returned item does not erase the original customer request. Whether that unit becomes usable stock again is a separate inventory-status question. Document any cancellation or return adjustment so future comparisons use the same convention.

Record the quality of availability evidence

An end-of-day stock snapshot is not necessarily proof that a listing was purchasable throughout the day. Mark partial or uncertain exposure instead of assigning a full day automatically. If reliable hourly records are unavailable, use a coarser estimate and state the limitation rather than inventing precise selling hours.

The official AWS forecasting sample notes that treating unavailable periods as ordinary zero sales can bias a forecast downward. That is a useful data distinction, not permission to remove every zero from a seller's history. Preserve genuine zero-sale periods and record any missing-value treatment separately. AWS sample guidance

Establish a baseline that another person can reproduce

Start with comparable selling exposure

A simple baseline is the units recorded during a defined set of comparable, fully sellable periods divided by their duration. Multiply that rate by a future duration only when the assumed conditions are reasonably comparable. Store the included dates and exclusions, not just the resulting average.

This is a reference calculation, not a universally unbiased estimator. If the stockout occurred on unusually busy days, the remaining days may not represent the missing ones. If all observed days included a promotion, their rate may overstate normal demand. If there are no usable comparable days, stop the calculation; dividing by zero or substituting an arbitrary rate creates false confidence.

Compare recent behavior with an appropriate reference

For a stable item, a recent rolling average may be a useful starting point. For recurring patterns, compare like weekdays or corresponding seasonal periods as well. A seasonal reference needs relevant historical coverage: a few weeks cannot establish an annual cycle. A more recent window responds faster to change but may also overreact to a short disruption.

Do not choose the window solely because it best describes the period you already know. Evaluate candidate windows on later periods that were not used to select their inputs. If an apparently sophisticated method cannot beat a simple reference on the relevant horizon, investigate the data and assumptions before adding complexity.

Keep adjustments outside the original observation

Separate observed units, the baseline calculation and editorial or planner adjustments. An assumption such as a planned event uplift belongs in an adjustment field with a reason and an owner. Do not rewrite the historical sales column to make the forecast easier to produce.

This separation matters during review. A poor outcome may come from the baseline, an event assumption or a supply interruption. When those elements are mixed into one overwritten value, the team cannot learn which decision needs changing.

Worked example: 210 recorded units can support different forecasts

Consider a fictional SKU over 28 calendar days. It recorded 210 units during 21 comparable, fully sellable days and zero during seven verified unavailable days. Assume the 21 observed days are suitable for this demonstration; that assumption would need examination in a real account.

Compare the denominators, not just the totals

Dividing 210 by all 28 days gives 7.5 units per calendar day. Dividing the same 210 units by the 21 comparable selling days gives 10 units per selling day. Extending the latter rate across a fully sellable future 28-day window gives 280 units under unchanged conditions.

Neither calculation proves how many customers would have ordered during the stockout. The difference is an assumption about exposure, not a measurement of 70 lost sales. It also does not establish that the next month will reproduce the available-day rate.

Swipe horizontally to view all table columns.

Treat the range as scenarios, not statistical certainty

The 224, 280 and 336 figures use assumed rates of 8, 10 and 12 units per day. They are not calibrated percentiles, confidence bounds or evidence that actual demand will fall inside that range. Their purpose is to show how sensitive the decision is to a plausible rate change chosen for review.

Ask what evidence would support each scenario. A confirmed change in price or promotion may justify examining a different rate, but it does not identify the exact effect automatically. When no credible basis exists for the chosen sensitivities, label them as exploratory and avoid treating the middle value as a validated forecast.

Write the next check before placing an order

For this example, the next check could be whether the reference days match the future weekday and promotion mix. A second check could establish the product's expected availability over the new window. Assign those checks and retain the calculation version.

If the forecast changes, save the replacement alongside the original. This allows the team to distinguish an informed revision from a model that only appears accurate because its earlier predictions were overwritten.

Adjust for seasonality and promotions without counting them twice

Align comparable events, not merely calendar labels

A recurring demand pattern needs comparison with relevant prior periods. Event dates can move, and the same month can contain a different mix of selling days. Compare the commercial conditions as well as the calendar: availability, price, assortment and advertising may differ.

Amazon's inventory-management guidance identifies sales history and seasonality as relevant planning inputs. It does not make one stock target appropriate for every seller. Your forecast should explain which historical pattern you believe will recur and what has changed since it was observed. Amazon inventory-management guide

Separate a promotion scenario from normal demand

If a recent sales average already includes a promotion, adding another promotion multiplier may count the same effect twice. Build a normal-period reference where possible, then show the proposed event adjustment separately. If normal-period evidence is insufficient, state that the event effect cannot be cleanly separated.

An advertising budget change is not a guaranteed proportional change in unit demand. Price, offer competition and customer behavior can move at the same time. Use explicit assumptions rather than promising a fixed sales response to each extra advertising dollar.

Escalate when the old pattern no longer represents the product

A redesigned product, a changed pack size or a discontinued variation may need a new baseline. Preserve the mapping history and do not join old and new units without a defensible conversion. A sudden increase also deserves a source check before it becomes the new normal.

For longer horizons, separate near-term evidence from later assumptions. A detailed weekly curve can look precise even when most future events are unknown. Make the uncertainty visible rather than disguising it with extra decimal places.

Forecast new products and intermittent sellers differently

A new SKU needs an explicit analogy, not invented history

For an item with no sales history, select any comparison products deliberately. Record differences in price, pack size, positioning and launch support. An established item with reviews and stable availability is not automatically a good proxy for a new listing.

Use the analogy to create assumptions for a limited test, then replace those assumptions as actual evidence becomes available. If the question is whether the market exists at all, start with Amazon product demand analysis. Category interest and competitor estimates are not measurements of the new SKU's future sales.

Keep genuine zero-sale periods for slow-moving products

An intermittent item may be available for several days between orders. Removing those zeroes inflates its rate. Examine both order occurrence and order size, and consider whether a weekly view helps review the pattern without losing the timing needed for the operational decision.

Do not force a continuous daily-rate story onto very sparse evidence. A specialist method may be appropriate, but it still needs an honest comparison against a simple reference. If the available history cannot support a useful estimate, a scenario with explicit uncertainty is preferable to a falsely precise model output.

Separate a temporary disruption from end of life

Inventory exhaustion, a listing issue and deliberate product discontinuation have different implications. Mark the reason for each interruption where known. A discontinued item should not receive a demand continuation assumption merely because the forecasting script fills missing dates.

Stop automated recommendations when the product boundary, availability status or source quality is unresolved. The output can still be a useful investigation task; it should not become an executable buying instruction.

Measure forecast error on predictions saved before actuals arrive

Use the horizon that the business actually needs

Save the forecast before its target period begins and compare it with later observations using the same unit and date definition. A one-week-ahead forecast should not be presented as evidence that a twelve-week-ahead decision is reliable. Use several historical cutoffs when possible, with each forecast restricted to information available at its own creation time.

Forecasting: Principles and Practice emphasizes evaluation on unseen data rather than fit to training history. It also explains why percentage errors become problematic when actual values are zero or near zero. Those principles matter for slow-moving SKUs. Forecast evaluation reference

Zero average bias can hide substantial misses

Here is a separate fictional example with four completed, available periods. For this worksheet, signed error means forecast minus actual; positive values therefore mean overforecasting. Other systems may use the opposite sign, so label the convention.

Swipe horizontally to view all table columns.

The signed errors sum to zero, but the absolute errors sum to 60. Mean absolute error is 60 divided by four, or 15 units per period. The model was not perfect: opposite misses cancelled in the signed average. For an inventory decision, their timing can matter even when the total forecast equals the total observed units.

Separate numerical performance from operational outcomes

Compare methods on the same periods and scope. Record unavailable periods rather than silently dropping inconvenient outcomes. When sales were constrained, explain that observed sales may not reveal unconstrained demand; keep any estimated lost-demand series separate from actual observations.

There is no universal accuracy percentage that makes every SKU ready for purchasing. Inspect the size and direction of errors, the horizon and the consequences of being wrong. A forecast can also be reasonable while a late receipt causes a stockout. Conversely, excess stock can prevent a stockout without demonstrating good forecasting.

Choose manual, native, automated or agent-assisted methods deliberately

Manual spreadsheet: useful when the review remains manageable

Start with a protected raw-data tab, a calculation tab and a versioned forecast log. Reconcile one SKU, mark exceptions and save the next-period prediction. The result should be reproducible without relying on the original author's memory.

This approach fits a small number of understandable series. It becomes fragile when copied formulas, undocumented adjustments and changing mappings overwhelm review. At that point, automate repeatable preparation first; do not assume that replacing a spreadsheet also fixes its assumptions.

Native tools: inspect what your account actually provides

Amazon's FBA page points sellers to its dashboard and restock tools for inventory planning. Use available recommendations as an input to review, retaining their date and relevant settings rather than assuming they answer every custom forecasting question. Amazon FBA tools

Report access also matters. The SP-API documentation labels the Vendor Forecasting Report as available to vendors; that is not proof that an ordinary Seller Central account has the same forecast endpoint. Verify the report and role before designing an integration. Amazon analytics report documentation

Scripted automation: make exceptions visible before scaling

An authorized pipeline can standardize imports, identify duplicate rows and produce repeatable baselines. Specify the accepted schema, time zone, mapping version and freshness requirement. On a missing input or failed reconciliation, stop the affected output and retain an error record instead of publishing the previous result as current.

Choose software by the evidence it preserves: original forecasts, editable assumptions, source lineage, exception handling and evaluations at your required horizon. A product's use of machine learning does not establish that it will improve your own SKU forecasts. Trial it against a saved baseline using comparable inputs and periods.

Agent-assisted review: coordinate the work without surrendering the decision

An agent can be considered for the surrounding review workflow: organizing authorized evidence, drafting explanations and routing unresolved questions. The forecasting calculation should remain traceable to a defined method. A fluent explanation is not proof that the input data or model is correct.

Scale only after reviewers can detect stale data, reject unjustified adjustments and recover prior versions. Purchasing, advertising or shipment changes should remain outside the pilot unless their authority and controls have been separately agreed. The right escalation may be a request for better evidence, not a larger order.

Where OpenMax can fit in a forecast-review workflow

Use a collaboration layer when the handoff is the bottleneck

OpenMax describes its product as a human-agent collaboration platform. A relevant use case to discuss is coordinating forecast reviews across inventory, marketing and operations. That positioning does not establish a native Amazon demand model or a ready-made connection to your seller account.

The proposed workflow is to supply an authorized forecast packet, request a summary of changed assumptions and route exceptions to named people. Confirm data access, retention, permissions and the required integrations before implementation. Keep the calculation and source records available for inspection instead of asking a language model to invent missing quantities.

Start with a portable forecast-review record

Use this structure in an existing document first. It is an editorial template, not a claim about an OpenMax import format. Include only the data needed for the review; customer-identifying details are not necessary for the aggregate example.

Decision: review the next demand forecast, not place an order
Scope: marketplace, SKU, pack unit, channel
Created: date, time zone, forecast version
Horizon: target dates and aggregation period
Sources: export names, extraction times, owners
Availability: sellable, unavailable and unknown periods
Baseline: formula, included dates, exclusions
Adjustments: reason, evidence, owner
Scenarios: assumed rates and resulting units
Validation: saved forecast, actual basis, error convention
Exceptions: missing evidence and next investigation
Review: responsible person, deadline, accepted changes

Keep a simpler process when coordination is not the problem

For a few stable SKUs, an inspected spreadsheet and a short review meeting may be sufficient. OpenMax should not be added simply to make the forecasting process sound more advanced. Nor should the team expect an agent to recover demand that was never observed with certainty.

If the handoff does need improvement, use the Amazon seller workflow automation guide to scope a narrow pilot. Review one packet, compare its explanation with the underlying data and resolve the limitations before expanding access or responsibilities.

FAQ: Amazon inventory forecasting

How much sales history do I need?

There is no universal number that fits every SKU and horizon. You need enough comparable observations to establish a reference and evaluate later periods. Annual seasonality requires relevant seasonal history; a short launch record cannot prove it. With limited data, use clearly labeled assumptions and update them as evidence accumulates.

Should stockout days count as zero demand?

No: a verified unavailable day is not evidence that customers wanted nothing. Preserve the observed sales, label the availability condition and document any adjustment. Do not remove all zero-sale days, because genuine zeroes while an item is available are part of its demand pattern.

How do I forecast a new Amazon product with no history?

Use carefully chosen analogues and explicit launch assumptions, explaining differences in product, price and selling conditions. Treat the result as a scenario for a limited reviewable test, not a measured demand series. Replace assumptions with the product's own evidence as it becomes available.

How should I handle seasonal demand and promotions?

Compare relevant events and selling conditions, not only matching month names. Separate the normal-period baseline from any event adjustment and avoid adding an uplift already embedded in the observed rate. Keep a record of why the event is expected to repeat and what would invalidate the assumption.

Do I need inventory forecasting software?

Not necessarily. A reviewed spreadsheet may be adequate for a manageable set of SKUs. Software becomes more useful when data preparation, version control and exception handling exceed that process. Evaluate it against your saved baseline and required forecast horizon rather than choosing solely by an AI label.

Is forecast demand the quantity I should reorder?

No. Forecast demand estimates future units under defined conditions. A replenishment decision also considers usable inventory, commitments, inbound timing, supplier rules and business constraints. Review those separately before turning any forecast into a purchase or shipment instruction.

What is a good forecast accuracy target?

A useful target depends on the SKU, horizon and consequences of error. Inspect absolute error and directional bias against a comparable baseline. Percentage metrics can be misleading near zero actual demand, and a low aggregate error can hide misses in individual periods. Define the evaluation before comparing tools.

How often should I update the forecast?

Choose a cadence that matches data freshness and the decision cycle, with additional review for material changes in availability, promotions or product identity. Keep each original version even when you revise more frequently. Updating a number often is not a substitute for checking whether its assumptions still hold.

Next step: save one forecast and review the next completed period

Select one SKU with understandable source records. Define its unit and horizon, reconcile availability, record a baseline and save the forecast before the target period begins. Assign the next review date and the person responsible for investigating differences.

At that review, distinguish data problems, assumption changes and genuine forecast error. If the process is still unclear, improve the record before expanding to more SKUs. If coordination is the limitation, bring the same packet to an OpenMax workflow discussion with a specific question: what evidence can be organized, who must review it and which actions remain under human control?