retailer data
Why POS, Orders, Inventory, and Forecasts Disagree
Check scope, timing, supply, and ordering patterns to explain why POS, orders, inventory, and forecasts differ before changing the plan.
Point-of-sale (POS), retailer orders, inventory, and a sales forecast measure different things: recorded sales, requests for product, stock at a point in time, and estimated future demand. To compare them, use the same item and location detail, calendar, units, cutoffs, and refresh times. Check supply and ordering conditions before attributing a difference to demand or changing the plan.
A useful comparison explains which differences need action and which come from the way each measure is recorded.
Start by naming what each signal measures
| Signal | Working question | Common comparison mistake |
|---|---|---|
| POS | What sales were recorded for this scope and period? | Treating recorded sales as unconstrained demand |
| Orders | What quantity was requested, for what delivery timing? | Treating an order spike as a matching consumer-sales spike |
| Inventory | What stock was recorded at a defined location and cutoff? | Comparing a point-in-time balance with a period total without alignment |
| Forecast | What future demand did the planning process estimate at a defined grain and horizon? | Comparing one forecast version with actuals from a different scope or period |
The U.S. Census Bureau defines retail inventory as merchandise held for sale at the end of a reporting period, while sales cover activity during a period. Comparing that ending balance directly with a sales total mixes a snapshot with activity over time. Check this distinction before applying retailer-specific definitions.
Diagnose the disagreement in five steps
TrueShelf suggests the following review sequence. Walmart does not require it.
1. Make the measures comparable
Write down the definition beside each number:
- item and hierarchy level;
- store, distribution center, channel, or total-business scope;
- units, dollars, or cases;
- daily, Walmart-week, calendar-week, or fiscal-period boundaries;
- order, requested-delivery, ship, receipt, sale, and inventory-snapshot dates;
- filters, exclusions, and forecast version.
If one dataset is item-store-week and another is category-month, retain the item-store detail before aggregating. Grouping products, locations, or periods together can hide differences between orders and sales within those groups.
For Walmart reporting, use a consistent fiscal-period mapping. The Walmart calendar can help align weeks and periods, but it does not resolve differences in source definitions.
2. Check data state before business cause
Confirm that every source is complete enough for the comparison:
- latest available timestamp and expected refresh;
- missing files, dates, items, or locations;
- duplicate records or changed keys;
- restatements and late-arriving transactions;
- inventory snapshot timing;
- forecast creation date and version.
If the gap disappears when you apply the same cutoff and forecast version, record that comparison error before investigating demand.
3. Test availability and distribution
POS can fall while underlying customer interest is unchanged if fewer stores can sell the item or stock is not available when customers shop. Check whether the comparison scope changed and whether recorded inventory supports the sales opportunity.
Lower POS alongside lower inventory or distribution gives you places to investigate. It does not tell you how many units would have sold with more stock or wider distribution.
4. Explain order behavior
Order timing and quantities can differ from consumer purchases. Review:
- order and delivery timing;
- batch size and cadence;
- lead time;
- inventory already in the network;
- constrained, delayed, canceled, or duplicated orders;
- initial fills, resets, or distribution changes.
Planning systems also differ in how they relate orders to forecasts. SAP documents one design in which incoming sales orders consume forecast quantities at configured levels. That example shows why a team must know its own planning configuration: adding orders and forecast together may double-count demand in one design, while another workflow may define the relationship differently.
5. Test the demand explanation last
After the first four checks, review the forecast assumptions. Look for a repeated pattern across comparable periods and the relevant item-location detail. Check whether evidence about price, promotion, seasonality, assortment, channel mix, or known events explains the pattern.
The bullwhip effect describes order or upstream-flow variability exceeding sales variability. It does not occur in every industry or explain every order-versus-POS gap. Measure that variability before using the term.
A worked example: the same totals, different timing
Suppose weekly POS is steady, retailer orders double in one Walmart week, recorded inventory rises the next week, and the latest forecast is unchanged.
An unsupported conclusion would be: “Demand doubled, so raise the forecast.”
Check the timing and scope:
- Are POS, orders, inventory, and forecast on the same item-location scope and unit?
- Is the order dated by creation, requested delivery, or receipt?
- Did the inventory snapshot occur before or after the receipt?
- Was this a larger, less frequent order or a distribution fill?
- Does comparable POS evidence persist after the timing effect passes?
If the larger order was a batched replenishment received into inventory one week later while POS stayed stable, the evidence supports an order-timing explanation. The team can keep the forecast, document the exception, and recheck after the next comparable period.
End with a decision record
For every material mismatch, record:
- the signal and aligned comparison;
- evidence checked at each step;
- best-supported explanation;
- competing explanation and uncertainty;
- action, owner, and recheck date.
Keep tentative explanations separate from confirmed findings. At the next review, the record lets the team check the definitions, files, and assumptions behind its earlier decision.
TrueShelf is being designed to organize recurring retailer data while keeping definitions, grain, calendars, refresh state, and incomplete evidence visible around the analysis. Explore the platform or talk through your data.
Frequently asked questions
Should POS and retailer orders match in the same week?
Not necessarily. They represent different events and may use different dates, locations, units, and cadences. Align those definitions before interpreting the gap.
Does lower POS mean the sales forecast is too high?
Not by itself. Check data completeness, inventory availability, distribution, timing, and comparable periods before changing the forecast.
Can orders and forecast be added together?
Only if the planning design explicitly calls for it. Some systems use actual orders to consume forecast quantities; adding both without understanding that configuration can double-count demand.
What is the first field to check when inventory disagrees with sales?
Start with scope and cutoff: which locations and items are included, and when the inventory snapshot was taken relative to sales, orders, and receipts.