Vendor Stock Forecast
Access from: Forecast → Logistics
For Vendor accounts, the forecast calculates, for each product and marketplace, how many units to ship to Amazon over the horizon you define. It starts from real consumer demand and corrects it for Amazon's ordering behavior, the stock already in place and your business rules.
Vendor vs Seller
In Vendor, Amazon buys from you and then sells to the consumer, so the model does not only look at what sells: it also learns how Amazon orders, which rarely matches real demand. The Seller forecast starts from a different premise.
How to run a forecast
- Go to Forecast → Logistics.
- Select the Vendor connections you want to include in the calculation.
- Define the horizon (dates or number of days) for which to compute the shipment.
- Adjust the parameters that apply to your operation: minimum final stock, minimum units to ship, units per box and, if you want to scope it, the countries or products.
- Generate the forecast and review the table by product and marketplace.
- Export to Excel to use it as an internal production-control and replenishment-planning tool.
First-time data collection
The first time you run a forecast for a Vendor connection, the system may take a few minutes to pull the required history from Amazon (up to 24 months). Subsequent runs are immediate because they start from the history already maintained by the system.
What data it takes into account
Real demand (consumer sales)
- Recent sales of the product (current trend).
- Seasonality: sales from the same period of the previous year.
- The model combines both so it is neither swayed only by the latest data nor blind to seasonal peaks.
Amazon's orders to the vendor
- What Amazon orders and receives from you (it can differ greatly from what sells).
- What you confirm versus what Amazon ends up receiving.
- Open orders and goods in transit (what Amazon already has on the way).
Inventory at Amazon
- Available stock currently in the fulfillment centers.
- Stock in transit.
- Aged stock (more than 90 days without selling), as a signal of overstock.
Stockouts
- Periods when the product was out of available stock, so real demand is not underestimated: it did not sell because there was none, not because there was no demand.
How it adjusts the recommendation
On top of consumer demand, the model applies a series of business corrections:
| Adjustment | Purpose |
|---|---|
| Amazon's ordering pattern | Amazon rarely orders 1:1 against what sells; it usually over-orders or under-orders. The model learns this from history and adjusts the figure to what Amazon will actually order. |
| Stock already available and on the way | Discounts what is already in the centers and what Amazon has already ordered, to avoid duplication. |
| Amazon's receiving rate | If Amazon only receives part of what is confirmed, the recommendation compensates for it. |
| Stockouts | If there were periods without stock, it adjusts demand upward to reflect unmet demand. |
Product states
The system classifies each product by its supply situation and shows the state as a colored tag in the table's State column. It describes the relationship with Amazon, not the current stock: replenishment urgency is flagged separately, with the ⚠ icon next to the period's starting stock. Hovering over the tag shows a description of the state.
With a shipment recommendation
In most cases the system issues a shipment figure and includes the state to give context to the commercial conversation.
| State | Signal | What it means |
|---|---|---|
| Stable | 🟢 | Amazon orders in line with what sells. Healthy relationship. |
| Over-stock (active) | 🟡 | Amazon orders more than what sells; tends to accumulate stock. |
| Over-stock + aged | 🟡 | Over-stock with aged inventory; Amazon will cut orders soon. |
| Correcting | 🟡 | Amazon's orders have varied a lot between periods; the forecast is smoothed. |
| Under-supplied | 🟡 | Amazon orders somewhat less than what sells. |
| Severely under-supplied | 🔴 | Amazon orders considerably less than what sells; risk of running short. |
| Systemic OOS | 🔴 | Frequent stockouts that depress observed sales. |
| Insufficient data | ⚪ | Too little history to classify; a conservative figure is issued. |
Without a shipment recommendation
In these cases the system deliberately gives no figure, because shipping stock would make no sense, and states the reason:
| State | Signal | What it means |
|---|---|---|
| PO suspended | 🔴 | Amazon has stopped placing orders for this product. |
| Returns-dominated | 🔴 | More is returned than Amazon receives. |
| Vendor off-boarded | 🔴 | Amazon has almost stopped buying this product from you. |
| Inactive | ⚪ | Very low sales; not enough sales activity. |
Parameters you configure
| Parameter | Effect |
|---|---|
| Horizon (dates / days) | Period for which the shipment is calculated. |
| Minimum final stock | Safety buffer below which not to fall. |
| Minimum units to ship | Floor for the recommended figure. |
| Units per box | Rounds the shipment to box multiples. |
| Countries / products | Defines the scope of the forecast. The connection's vendor codes are shown for reference but cannot be used to scope it: Amazon's data does not arrive at that level of granularity. |
What it returns
| Output | What it is |
|---|---|
| Sales forecast | Expected consumer demand over the horizon. |
| Units to ship | Final shipment recommendation to Amazon. |
| Estimated starting stock | Stock the period is expected to start with. |
| Product state | Operational situation and, if there is no figure, the reason. |
Grouped forecast across vendor accounts
What it is and when it helps
If you have several Vendor accounts (for example, one per country), Amazon often places a single order for the whole of Europe from one country. Calculating the forecast of each account separately is not enough: the demand and stock of one country may be covering others.
With the grouped forecast across accounts the system adds up the sales and stock of the accounts that sell the same products and calculates a single forecast per product, instead of one per account. It is worth turning on when your Vendor accounts share a catalog across different countries.
How the group is detected
The group is detected automatically, from the products in common between your client's Vendor accounts. It is not edited by hand: you cannot add accounts to the group or remove them.
In the settings of each account you will always see which accounts make up the group and how many products each one has in common, even when grouping is off. That lets you check whether the proposed group makes sense before turning it on. If an account shares no products with other accounts, there is nothing to group and the setting does not appear (the reason is explained).
How to turn it on
- Go to Forecast → Logistics and open the settings of one of the Vendor accounts. In the accounts table, click the more options button (the three dots) on the account's row and choose View details: the Specific configuration of that account opens.
- Check Grouped forecast across accounts.
- Choose the base account (Base account) from the accounts of the group.
- Save.
The base account is the reference account of the group: the rows of the forecast come out on the products of the base account, with the data of all the accounts added up. If you turn grouping on without choosing the base account, you will not be able to save (Choose the base account to be able to save.). The same happens if the saved base account is no longer part of the group: The saved base account is no longer part of the group. Choose another one to be able to save.
The setting affects the whole group
This setting applies to every account of the group: if you change it here, it also changes in the others. It does not matter which account you open it from: it is a single setting for the group.
Products that don't exist in the base account
Because the rows come out on the products of the base account, a product that exists in other accounts of the group but not in the base does not get a row and is left out of the forecast. When you configure grouping, the system tells you how many there are: N products of the group don't exist in X and will be left out of the forecast. You can choose another base account to reduce them.
If you would rather lose none, check Also include the products that don't exist in the base account. Then each product missing from the base appears in the forecast with the data of another account of the group where it does exist, and the row shows which account it belongs to. This option is unchecked by default.
What you see in the results table
+N accounts: a tag showing that the row adds up the data of N other accounts besides its own. Hover over it to see the accounts grouped in that row (Accounts grouped in this row:).Product from X: appears when the row is anchored in an account other than the base, because the product doesn't exist in the base and you turned on the option to include the products missing from it.
Warnings
When you create the forecast, the system warns you if grouping cannot be applied the way you configured it:
- If only one account of the group is enabled in this forecast: The grouped forecast won't be applied: only one account of the group is enabled and at least 2 are needed. Each account will be calculated separately.
- If you enable only some of the accounts of the group: The grouped forecast will include N of the M accounts of the group: only the accounts enabled in this forecast are grouped.
- If the base account is not enabled in this forecast: The base account of the grouped forecast isn't enabled in this forecast. Enable it, or turn grouping off in the account settings, to be able to generate it.
- If the saved base account is no longer part of the group: The base account of the grouped forecast is no longer part of the group. Check the account settings and choose another base to be able to generate it.
- Once generated, if the group was left with fewer than two enabled accounts: The grouped forecast wasn't applied: only N accounts of the group were enabled and at least 2 are needed. Each account is calculated separately.
In data collection, grouping needs the history of the accounts of the group. If an account other than the base is missing history, the group is applied without it. If the base is missing it, grouping is not applied and the other accounts are calculated separately. In both cases, the account named in the warning is left out of that forecast until its history is complete: launch the forecast again once it is.
| Situation | Warning |
|---|---|
| History is missing in an account other than the base and the group is applied without it | The account X was left out of the grouped forecast because its history is missing. |
| Downloading the Amazon data of an account other than the base fails and the group is applied without it | The account X was left out of the grouped forecast because downloading its Amazon data failed. |
| History is missing in the base, or the group cannot be applied without that account | The grouped forecast wasn't applied because the history of the account X is missing: that account is left out of this forecast and the others are calculated separately. |
| The download fails in the base, or the group cannot be applied without that account | The grouped forecast wasn't applied because downloading the Amazon data of the account X failed: that account is left out of this forecast and the others are calculated separately. |
| The base wasn't enabled in this forecast | The grouped forecast of the accounts X, Y wasn't applied: the base account wasn't enabled in this forecast. Each account is calculated separately. |
| At least 2 accounts of the group weren't enabled | The grouped forecast of the accounts X, Y wasn't applied: at least 2 accounts of the group had to be enabled. Each account is calculated separately. |
Credits
Credits are charged for all the accounts, the same as without grouping: grouping or not grouping costs the same, even if the result has fewer rows.
Example
A product that sells ~150 units/month, but for which Amazon historically orders considerably more than what sells and only receives part of what is confirmed. After applying the adjustments, the shipment recommendation lands above the real sales figure —around ~300 units— to cover Amazon's actual ordering pattern. The product state flags that Amazon is over-ordering: a useful data point for the conversation with the brand.