Amazon decides which fulfilment centres hold your inventory, and it scatters the same SKU across many of them. Add your own warehouse and the real question — where is this SKU, and where is it about to run out — stops being answerable from any single Seller Central report. This is how to get one picture of the whole network.
Inventory placement across fulfilment centres is Amazon's decision, not yours. That means the number of locations you are tracking grows on its own, and it grows fastest exactly when your volume is growing.
A network-wide figure averages away the specific centre that is about to hit zero. Regional demand is uneven, so the aggregate is the one number almost guaranteed to look fine while something underneath is not.
Local warehouse inventory usually sits in a spreadsheet with no link to FBA data. Reconciling the two is manual, so it happens weekly at best — and any decision made in between is made on stale numbers.
Stock that has left your warehouse but has not been checked in at a fulfilment centre is easy to count twice or not at all. Both errors are expensive in opposite directions.
The Analytics warehouse grid shows 15 days of inventory and shipment movement across every fulfilment centre and your own locations at once. Red cells flag stockouts, green cells confirm coverage. The SKU column stays pinned while you scroll the network horizontally.
Local stock sits alongside FBA rather than in a separate spreadsheet, and is netted against pending shipments so committed units are not double-counted as available.
Future Stock adds shipments already in transit to on-hand inventory, giving each location its real forward position instead of a snapshot that is out of date the moment a truck arrives.
Recommendations are computed per location, so the answer distinguishes between the centre that needs 240 units and the one already holding two months of cover. That is the difference between fixing an imbalance and deepening it.
Everyone works from one workspace with role-based access — Owner, Admin or Member — and every upload, shipment and change is recorded in the audit log with the actor and timestamp. Disagreements about the numbers stop being unresolvable.
Enough that it is not the constraint. A warehouse here means a distinct Amazon fulfilment-centre location code plus any of your own depots, and because Amazon scatters inventory on its own, that count rises without you choosing it. Plan limits are set generously for exactly that reason, and the Business plan removes the warehouse cap entirely.
Both, side by side. Local stock is tracked as a real location, netted against pending shipments, and included in per-warehouse recommendations rather than treated as an afterthought.
As current as your last data load. Upload a fresh Inventory Ledger CSV whenever you want a refresh, or connect SP-API and let it sync on a schedule so the grid stays current without anyone exporting anything manually.
Yes. Click any SKU to drill into its 30-day history, and filter the grid by category, date range or SKU range. That is usually how you find the product that is being damaged on every inbound, or the location that consistently runs dry first.
Yes. The dashboard supports time-travel to any date up to yesterday, so you can reconstruct the network position as it stood then — useful when reconciling a past shipment decision or investigating why a location ran out.
Every FBA and local location on one screen, with per-warehouse dispositions.
See the feature FeatureOne shared set of numbers, with a record of who changed what.
Explore roles Use caseTurning per-location visibility into replenishment that happens in time.
Read moreNo card · Built for Amazon India · Email support from the founder.