The Weeks of Supply Formula: An Operator's Guide

A common Amazon inventory review starts the same way. One SKU is moving faster than expected, another has been sitting at FBA too long, and the spreadsheet on someone's desktop still mixes sellable units, inbound stock, and trailing sales from different date ranges.

That's why the Weeks of Supply formula matters. It converts inventory from a raw unit count into a time-based operating metric. For an Amazon seller, that shift changes the conversation from “How many units are left?” to “How long will this ASIN stay in stock at the current pace?” That's the number buyers, operators, agencies, and agent workflows can use.

For teams working inside Amazon, the challenge usually isn't understanding the concept. It's getting consistent inputs. FBA inventory sits in one place, order velocity in another, MCF demand in another, and native Seller Central reporting often turns a simple calculation into a manual reporting task. A structured data layer fixes that by making the formula repeatable across SKUs, channels, and reporting cadences.

Table of Contents

• Why Weeks of Supply Is a Critical Metric for Amazon Sellers
• Calculating the Weeks of Supply Formula
  • What belongs in current inventory
  • How to choose the sales denominator
• Practical WOS Calculations for FBA and MCF
  • Example one for a standard FBA SKU
  • Example two for a shared FBA and MCF pool
• How to Interpret WOS and Set Inventory Targets
  • Tie the target to lead time
  • What high and low WOS actually mean
• Limitations of the WOS Formula and Advanced Methods
  • When trailing WOS gives the wrong answer
  • Where FWOS fits
• Automating WOS Reporting with agentcentral
  • The exact data inputs needed
  • Example MCP workflows for WOS reporting
• Integrating WOS into Your Operational Workflow

Why Weeks of Supply Is a Critical Metric for Amazon Sellers

Amazon operators usually aren't short on inventory data. They're short on a metric that turns that data into a clear replenishment signal.

A raw unit count doesn't tell much by itself. 500 units of one ASIN can be dangerously low, while 500 units of another can be months of excess stock. Weeks of supply fixes that by normalizing inventory into time. That's why it's one of the most practical inventory health metrics in retail operations.

For Amazon sellers, that time-based view matters in several ways:

• Cash control: Excess weeks of supply tie working capital up in inventory that isn't moving.
• Replenishment timing: Low weeks of supply can expose a fast-moving ASIN before the next PO or shipment arrives.
• FBA storage discipline: Long cover on slow movers tends to create storage pressure and harder clean-up decisions later.
• Catalog prioritization: WOS makes it easier to compare products with very different sales rates.

WOS works because it answers the operational question that matters most: how long current stock lasts if sales continue at the present pace.

Inside the Amazon ecosystem, this metric becomes more useful when it's calculated consistently from the same inventory and order sources every week. That's the point many teams miss. The problem usually isn't the formula. It's unreliable inputs, mixed definitions, and manual reporting habits that make the metric hard to trust.

When a team standardizes how it pulls FBA stock, FBM stock, inbound units, and order velocity, weeks of supply becomes a real operating KPI instead of a slide-deck number. That's especially important for agencies, aggregators, and larger seller teams that need one method across many accounts.

Calculating the Weeks of Supply Formula

A planner opens Monday's inventory sheet and sees 1,200 units for an ASIN. The next question is the one that matters. How many weeks does that cover at the current sales rate?

Weeks of Supply = Current Inventory ÷ Average Weekly Units Sold

The math is simple. The work is in defining both inputs the same way every time, especially for Amazon catalogs where one SKU can pull demand from FBA, FBM, and sometimes multi-channel orders.

If a SKU has 500 units available and sells 50 units per week, WOS is 10. If the same SKU sold 500 units over 13 weeks, the weekly average is 500 ÷ 13, and WOS should use that derived weekly rate as the denominator. That part is standard.

What changes in Amazon operations is the definition of "current inventory."

What belongs in current inventory

Use the inventory pool the business can fulfill from during the planning period. For many sellers, that starts with sellable FBA units. For others, it also includes FBM stock, or inbound units if the team consistently counts inbound as usable cover.

That choice has to stay consistent across the report. If one tab uses sellable FBA only and another adds inbound or reserved units, the WOS number stops being comparable from one week to the next.

A clean setup usually follows these rules:

• Use one inventory definition per SKU report: sellable only, or sellable plus selected inbound, but not a mix.
• Keep reserved units separate unless they are operationally available: reserved inventory can make coverage look better than it is.
• Match the inventory pool to the fulfillment model: if the SKU is fulfilled through Amazon only, use that pool. If the business also ships from its own warehouse, include that stock only if those units support the same demand stream.
• Confirm the fulfillment boundary first: teams that need a refresher on the difference between FBA inventory and Amazon fulfillment workflows should settle that definition before calculating WOS.

How to choose the sales denominator

Average weekly units sold sounds straightforward, but operators often create bad WOS numbers when calculating this.

The denominator should reflect real depletion. A fast-moving SKU with recent promo lift may need a short lookback window. A stable replenishment item usually benefits from a longer window that smooths out one-off spikes. A stockout period often needs to be excluded, because suppressed sales make inventory cover look longer than it really is.

Use judgment, but document the rule. A team that uses 4 weeks for one ASIN, 12 weeks for another, and changes windows without explanation will spend more time arguing about the metric than acting on it.

A practical approach looks like this:

• Shorter lookback for volatile SKUs: products affected by promotions, ranking shifts, or recent launches.
• Longer lookback for steady items: replenishable ASINs with stable order patterns.
• Adjusted history for stockout periods: remove or annotate weeks where demand was capped by lack of inventory.
• One sales scope per calculation: if inventory serves Amazon orders plus MCF demand, the denominator has to include both order streams.

For teams pulling data through agentcentral, this is the point of using a shared data layer. Pull current inventory from the same source each week, pair it with the same order logic, and WOS becomes a repeatable operating metric instead of a spreadsheet estimate.

The formula is easy to remember. Reliable WOS depends on disciplined inputs.

Practical WOS Calculations for FBA and MCF

A common failure case looks like this. An operator sees 500 units in Amazon, divides by Amazon marketplace sales, and concludes there are plenty of weeks left. Then MCF orders keep shipping from the same pool, and the SKU runs short earlier than the report suggested.

The formula did not fail. The inventory scope and demand scope did not match.

Example one for a standard FBA SKU

Start with the clean case. A SKU sits only in FBA, and only Amazon orders deplete that inventory. In that setup, Weeks of Supply is a direct calculation: current sellable FBA units divided by average weekly Amazon units sold for that same SKU.

For sellers still sorting out the operational boundary, this overview of how Amazon FBA works helps define what inventory belongs in the calculation. That boundary matters because WOS only works when the stock figure and the demand figure refer to the same fulfillment path.

A practical example is simple. If FBA sellable inventory is 500 units and the SKU averages 50 Amazon units per week, WOS is 10. That number is usable because both inputs describe the same channel and the same pool of inventory.

Example two for a shared FBA and MCF pool

The harder case is a shared pool. Amazon holds the inventory, but the SKU is shipping to Amazon buyers and to orders from Shopify, wholesale portals, or other channels through MCF.

In that situation, Amazon order history alone is incomplete. The numerator still comes from the FBA inventory pool, but the denominator needs total weekly depletion from every order stream drawing from that pool. If analysts leave out MCF units, WOS will read too high and replenishment decisions will lag.

Here is the same contrast in a working table:

The math is straightforward. The discipline is in the setup.

For SKU-A, 500 units divided by 50 weekly units gives 10 weeks of supply. For SKU-B, the calculation only holds if 38.46 represents combined weekly demand from Amazon and MCF. If the team used Amazon sales alone, the reported WOS would overstate coverage.

That distinction matters in day-to-day planning. Shared-pool SKUs are often the ones that create false confidence because the inventory count is easy to pull, while cross-channel depletion is spread across multiple reports.

A workable operating method looks like this:

1. FBA-only SKU: Pull current FBA sellable units and pair them with Amazon order velocity for the same lookback window.
2. FBA plus MCF SKU: Pull the same FBA inventory pool, then add Amazon and MCF shipped units before calculating average weekly demand.
3. One rule per SKU class: Define which ASINs are FBA-only and which use shared inventory, then keep that classification fixed unless the fulfillment setup changes.
4. Check the source system: If the inventory number comes from one system and MCF demand comes from another, reconcile SKU mapping before publishing WOS.

Teams using agentcentral can make this repeatable instead of rebuilding it in spreadsheets every week. Pull FBA inventory from the Amazon data layer, join it to Amazon order history and MCF order records at the SKU level, then calculate WOS from a single, consistent model. That is the practical shift from inventory theory to an operating report people can trust.

How to Interpret WOS and Set Inventory Targets

A WOS number has no meaning until it's matched to lead time and replenishment risk. A low figure isn't always bad. A high figure isn't always safe. The target depends on how long it takes to recover stock and how much uncertainty sits between the PO and the shelf.

Tie the target to lead time

One of the clearest planning rules is to anchor target weeks of supply to supplier lead time plus a safety buffer. Toolio's write-up on WOS target setting states that target weeks of supply should generally equal or exceed lead time plus a safety buffer, and gives a benchmark of lead time + 25% safety buffer. In that example, an 8-week lead time points to a target of about 10 weeks of supply.

That's a useful operating benchmark because it connects the metric to an actual replenishment constraint. The question stops being “Is this WOS good?” and becomes “Is this enough time to cover demand until replacement inventory is available?”

Teams working through broader inventory management best practices usually get better results when they define targets by SKU group, not by forcing one catalog-wide threshold.

What high and low WOS actually mean

A WOS value only matters in context. For Amazon operators, the interpretation usually falls into a few clear patterns.

• Too low for the lead time: The SKU is exposed. If demand holds, the seller may stock out before the next replenishment lands.
• Too high for the item profile: Capital is sitting in inventory longer than necessary. Slow movers also create more storage pressure and raise the chance of stale stock.
• Roughly aligned with lead time and buffer: The SKU is in a healthier operating range and doesn't need urgent intervention.

The risks on each side differ:

The right WOS target is rarely universal. Fast replenishable items, seasonal ASINs, and long-lead products need different coverage rules.

That's why experienced operators don't manage to one number across the whole catalog. They group SKUs by lead time, fulfillment path, and demand stability, then set thresholds that reflect those realities.

Limitations of the WOS Formula and Advanced Methods

Trailing WOS is useful, but it can mislead an operator who treats it as a forecast.

When trailing WOS gives the wrong answer

The standard formula assumes recent sales are a reliable guide to near-term demand. That assumption breaks in predictable situations.

Promotions are one example. A temporary ad push or deal period can inflate trailing velocity and make inventory look more exposed than it will be once demand normalizes. The opposite happens after a stockout. If a SKU was unavailable during part of the lookback window, the average weekly sales figure may be artificially low, which makes WOS look safer than it really is.

Seasonal products create the same problem in a different way. Last month's pace may have little relevance to next month's demand. A summer item entering peak season and a giftable item approaching Q4 don't behave like stable replenishable products.

A few warning signs usually mean the trailing number needs scrutiny:

• Recent stockouts: Historical sales may reflect constrained demand rather than true demand.
• Short-term promotions: Velocity may be temporarily distorted.
• Seasonal transitions: A trailing average may lag the actual demand shift.
• Launch-stage SKUs: There may not be enough history to trust a stable average.

Where FWOS fits

In this regard, Forward Weeks of Supply becomes more useful. Cogsy's explanation of FWOS notes that FWOS replaces historical sales with forecasted weekly demand and, in more advanced planning contexts, can also incorporate receipts and lead times. That makes it more operationally useful because it reflects expected time-to-stockout under future demand rather than past velocity.

Trailing WOS answers what inventory coverage looks like based on history. FWOS answers what coverage looks like under the demand the business expects next.

For Amazon sellers, that distinction matters most when the account is entering a promotion window, a seasonal inflection point, or a replenishment decision with long lead times. Trailing WOS still has value. It's often the cleanest health metric for routine monitoring. But when the future won't look like the recent past, FWOS is the better planning lens.

Automating WOS Reporting with agentcentral

Monday morning. The replenishment meeting starts in 20 minutes, and three people are working from three different numbers for the same SKU. One pulled FBA inventory from Seller Central, another used a saved spreadsheet that still includes inbound units, and a third calculated demand from a different lookback window. The formula is simple. The reporting process is what breaks.

For Amazon operators, WOS automation is mainly a data-definition problem. If inventory scope and demand scope change from run to run, the output loses value. A usable workflow needs fixed inputs, a documented lookback rule, and a repeatable way to pull Amazon data without rebuilding joins every week.

The exact data inputs needed

A reliable WOS report starts with two fields per SKU:

• Current inventory position: Usually FBA sellable units, with FBM, inbound, or reserved inventory included only if the report is designed to count them.
• Average weekly units sold: Units ordered over a defined trailing period, converted to a weekly rate using the same method every time.

The hard part is not the formula. It is choosing definitions that match the operating decision. If the report is for an FBA replenishment plan, use FBA inventory and the demand stream that consumes that inventory. If the report is for total network coverage, combine the relevant fulfillment pools and order channels on purpose, not by accident.

Lookback windows should follow SKU behavior. Seasonal or promotion-sensitive ASINs often need a shorter trailing window. Stable replenishment SKUs usually tolerate a longer one. As noted earlier, the right choice depends on how quickly demand has shifted and whether recent sales reflect true demand or stock constraints.

A practical automation pattern looks like this:

1. Pull current inventory by SKU from the inventory data layer.
2. Pull order units by SKU over the chosen trailing window.
3. Convert trailing units into average weekly demand.
4. Divide inventory units by average weekly demand.
5. Flag SKUs outside the target coverage range.

Teams that still rely on native exports usually run into the same issue. By the time the files are downloaded, cleaned, and merged, the review is already lagging current inventory. For a clearer view of those export limitations, see these Amazon seller report workflows.

Example MCP workflows for WOS reporting

Inside an MCP client, the job is straightforward. Pull structured inventory records, pull structured order records, and calculate WOS from the same definitions every run.

agentcentral supports that pattern by exposing Amazon seller data through a hosted MCP data layer. That gives operators and agents a stable source for repeated reads instead of a process built around ad hoc report downloads.

Typical prompts are operational, not theoretical:

Pull current FBA inventory by SKU, calculate average weekly unit sales over the last 4 weeks for seasonal items and over the last 8 to 10 weeks for stable items, then return a table of SKUs sorted by lowest weeks of supply.

Or:

Combine FBA inventory with shared demand from Amazon orders and MCF orders for each SKU, then flag any SKU whose weeks of supply is below its documented lead-time coverage target.

For developers turning that into a repeatable workflow, the pattern is usually this:

Consistency matters more than prompt wording. Once the workflow pulls the same inventory scope, the same demand logic, and the same target rules each time, WOS reporting becomes something an operator can trust and an agent can run on schedule.

Integrating WOS into Your Operational Workflow

Weeks of supply works best as a standing operating metric, not as a one-off calculation before a purchase order.

Amazon teams get more value when they review WOS on a fixed cadence, define inventory scope once, and assign target ranges by SKU type. That creates a stable system for exception handling. Buyers can focus on ASINs that are below coverage, finance can see where stock is tying up cash, and account managers can separate real inventory risk from noise.

The same principle applies to automation. A structured workflow should calculate WOS from the same inventory and sales definitions every time, then surface exceptions for human review. The workflow doesn't need to decide what to buy or transfer. It only needs to return facts cleanly enough for the operator or agent to act on them.

Used that way, the weeks of supply formula becomes one of the most practical inventory controls in the Amazon stack. It connects sales velocity, inventory depth, and replenishment timing in one number that the whole team can understand.

For teams that want to operationalize WOS without rebuilding the same Amazon data joins every week, agentcentral provides a hosted MCP data layer for Seller Central, inventory, fulfillment, orders, and Amazon Ads. Connect the account, expose structured data to Claude, ChatGPT, Cursor, or another MCP client, and let the workflow calculate weeks of supply from consistent inputs with auditable access and repeatable reads.