At a glance
Distribution histogram of stock levels across the catalogue: how many SKUs have 0 stock, how many have 1-5, how many have 6-20, etc. The healthy-stock baseline that contextualises every OOS / inventory alert. A store with 5,000 SKUs and 200 OOS reads differently from a store with 100 SKUs and 200 OOS; the histogram tells you which scenario you’re in. Pairs naturally with BC’s MLI to surface per-warehouse stock distribution.
| What it counts | Buckets of inventoryLevel across all SKUs in the catalogue. Default buckets: 0, 1-5, 6-20, 21-100, 100+. Counts SKUs in each bucket. Optionally filterable by category, brand, or channel allocation. |
| API endpoint | GET /v3/catalog/products and GET /v3/inventory/locations/{id}/items (when MLI is active). The OpenSearch products index materialises per-SKU inventory level per location. |
| VAT / tax treatment | n/a, inventory metric. |
| Shipping | n/a. |
| Discounts | n/a. |
| Refunds | n/a. |
| Cancelled orders | n/a. |
| Currency | n/a. |
| Channel coverage | All catalogued SKUs, regardless of channel availability. For per-channel inventory use BC Channel Inventory Split. |
| B2B Edition behaviour | B2B-only SKUs (case-pack quantities) appear normally; their inventory levels are typically much higher than DTC SKUs (warehouses stock cases). The histogram often shows a bimodal distribution on B2B-active stores: small DTC inventory for retail SKUs and large B2B inventory for case packs. |
| Multi-Location Inventory | When MLI is enabled, per-location distributions are available; surface per-warehouse to identify operational hot-spots. The default view aggregates across locations. |
track_inventory = false SKUs | Excluded by default since they have no meaningful inventory level. Configure under Settings → Inventory tracking if you want them included as a separate “untracked” bucket. |
| Variants | We count at variant level when products have variants; a multi-variant product can contribute multiple rows to the histogram. |
| OOS bucket interpretation | 0-stock SKUs are the catalogue’s OOS pool. The 0-bucket count should match BC Channel OOS per Channel aggregated across channels (within sync-lag). |
| Time window | RT (real-time, refreshed each catalogue sync). |
| Alert trigger | None on this card; pairs with BC Alert OOS Spike. |
| Roles | owner, operations |
Calculation
Calculated automatically from your BigCommerce data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A US homewares brand on BigCommerce Enterprise with MLI across two warehouses (A and B), B2B Edition active, and 2,400 catalogued SKUs. Snapshot at 09:00 UTC on 18 Apr 26.| Bucket | All locations | Warehouse A | Warehouse B | % of catalogue |
|---|---|---|---|---|
| 0 (OOS) | 142 | 38 | 104 | 5.9% |
| 1-5 | 360 | 220 | 140 | 15.0% |
| 6-20 | 720 | 480 | 240 | 30.0% |
| 21-100 | 980 | 720 | 260 | 40.8% |
| 100+ | 198 | 80 | 118 | 8.3% |
| Total | 2,400 | 1,538 | 862 |
- Warehouse B has 104 OOS SKUs vs A’s 38. This is the operational signal: B is structurally under-stocked. Decompose by category, are the OOS items concentrated in one product family (a slow restock cycle on a specific supplier) or distributed (a general under-stocking pattern)? In this case 78 of 104 were “throw cushions, all variants”, a single supplier’s batch had been delayed; the merchant could expedite a single replenishment to fix most of B’s OOS.
- The 100+ bucket has 198 SKUs, with 118 of those at warehouse B. B is over-stocked on some SKUs while under-stocked on others, a classic warehouse-allocation imbalance. Investigation revealed B was the merchant’s old centralized warehouse with legacy long-tail stock; A was the newer fast-mover warehouse stocked from a fresh supplier. Action: rebalance via inter-warehouse transfer.
- 5.9% OOS is meaningful but not catastrophic. Healthy benchmark for BC stores in homewares is 4-8% OOS; below 4% means you’re over-stocking working capital; above 10% means you’re losing revenue to OOS. 5.9% is well-balanced.
- The 1-5 bucket has 360 SKUs, the “low-stock” warning band. These will become OOS within a week if not restocked. Cross-reference with BC Stock vs Sales to identify which low-stock SKUs are also high-velocity (urgent restock) vs low-velocity (can wait).
- Warehouse B’s distribution is bimodal (heavy 0-bucket and heavy 100+ bucket). This is the warehouse-cleanup signal: B contains both legacy slow-movers (100+) and recently-stocked-out items (0). Old warehouse + slow restock = the worst-of-both-worlds operational state. Plan a rebalance + write-off cycle for B.
- Identify the OOS concentration. Per-product-family decomposition shows whether OOS is one supplier issue or a systemic gap.
- Audit the 1-5 low-stock bucket. Cross-reference with velocity to prioritise restock.
- For MLI stores, look for warehouse imbalance (one warehouse OOS-heavy, another over-stocked). Inter-warehouse transfers are the cheap fix.
- For long-tail 100+ stocks, evaluate write-off or clearance. Old slow-movers tie up working capital and warehouse space.
- Pair with BC Channel OOS per Channel to verify channel-level impact.
Sibling cards merchants should reference together
| Card | Why pair it with Inventory Distribution |
|---|---|
| BC Channel OOS per Channel | The OOS-bucket’s per-channel decomposition. |
| BC Channel Inventory Split | Per-channel allocation context. |
| BC Stock vs Sales | Velocity-weighted view; identifies which low-stock SKUs are urgent. |
| BC Alert OOS Spike | Real-time OOS-bucket transitions. |
| BC Top SKUs | Cross-reference: top-SKUs in low-stock bucket = urgent. |
| BC Top SKUs Revenue | Revenue-impact view of low-stock items. |
| BC Inventory Alerts | Store-wide inventory alarms. |
| BC Alert Fulfilment Delay | Low-stock at the wrong warehouse causes fulfilment delays. |
Reconciling against the vendor’s own dashboard
Where to look in BigCommerce Control Panel: Products → View, filter by Inventory Level, sort by inventory ascending. The 0-stock list is the OOS bucket. Reports → Inventory Snapshot (Plus / Pro) gives a daily snapshot of inventory levels but in less granular bucketing. For MLI: Settings → Inventory → Locations → individual location shows per-location stock per SKU. Why our distribution may differ from BC’s product list:| Reason | Direction |
|---|---|
| Variant aggregation. We count at variant level; BC shows products with any variant in stock as “in stock”. | Vortex IQ HIGHER granularity / different counts |
Untracked SKUs. We exclude track_inventory = false; BC shows them anyway. | Vortex IQ LOWER total |
| Sync lag. Inventory webhooks lag by 30-120 seconds during peak load. | Vortex IQ slightly LAGS |
| MLI aggregation. Default we sum across locations; BC may show per-location only. | Different denominators |
| Bundle treatment. We count the bundle parent; BC may count components separately. | Different SKUs |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
shipbob.sb_inventory_distribution | ShipBob’s per-warehouse stock buckets should match the warehouse-A/B slices | ShipBob’s reporting includes some staged-but-not-receipted units that BC doesn’t see. |
shippo.shippo_per_warehouse_stock | Should align with warehouse slices when Shippo manages warehouses | Shippo’s warehouse aggregation is different per integration. |
netsuite.netsuite_inventory_balances | NetSuite’s inventory balances should match within 1-2 units | NetSuite is the upstream system-of-record for many BC stores; gap is BC sync lag. |
inventory_quantity buckets) and Adobe Commerce (per qty buckets); merchant-facing semantics are equivalent.