Rank ARA Inventory Health by Cost, Not Units

Rank the inventory tying up money by unhealthy inventory cost, with aged 90+ day sellable cost as the tie-break, never by units on hand: the agent pulls GET_VENDOR_INVENTORY_REPORT weekly through the Amazon Selling Partner MCP as a reusable Skill that labels every figure with the condition it counts, grounded by Amazon Agent Atlas so "unhealthy" means what Amazon means by it.

Finance said three million dollars was sitting at Amazon and asked which Amazon Standard Identification Numbers (ASINs) held it. The Amazon Retail Analytics (ARA) Inventory dashboard answered with four on-hand numbers on one page, an out-of-stock (OOS) rate our vendor manager disputes, and a permissions error for half the team. Which ASINs tie up money, how fast are they moving, and can I get that answer every Monday?

ChatGPT, Claude, Perplexity, and Microsoft Copilot know nothing about your business out of the box, and your competitors use the same four tools. Kuudo gives those same tools your data, your rules, and your way of working: your account as it is right now, your judgment running every time, and your call before anything changes. The Selling Partner MCP supplies the live account and the authorized report pull, Skills preserve how your team ranks excess, Amazon Agent Atlas applies the Amazon-specific grounding, and approval controls keep the write with the operator.

The Inventory dashboard moves once a week, and its sellable count is a condition, not an availability

The first thing I had our agent do was not a calculation. It was a label pass. Atlas retrieves the amazon_vendors Amazon Retail Analytics playbook, and the agent annotates every on-hand column with the condition that column counts and the day it is measured on, before anything gets ranked or divided.

Two properties of the dashboard set the clock. The Inventory dashboard lets you monitor the health of product inventory through weekly updates, so you can identify and respond to unfavorable trends. And there is no daily grain to fall back on: not all metrics in the Inventory dashboard are available at daily granularity, so Amazon removed the option. A weekly cadence is not a scheduling preference here, it is the finest grain Amazon still offers on this page.

The trap is the word sellable. In the Inventory dashboard, sellable on-hand units refers to the physical condition of the product as recorded in Amazon's inventory, before Amazon accounts for any outbound units such as customer shipments, transfers, or removals. Sellable inventory does not necessarily mean the units are available for sale on the Amazon website, only that they are not considered defective. The glossary pins the measurement day: sellable on-hand units and Sellable On-Hand Inventory, its cost form, are both counted in fulfillment centers on the last day of the selected period.

Unsellable is the mirror. Unsellable On-Hand Inventory Units is the number of units in Amazon's fulfillment centers in an unsellable condition on the last day of the selected period, and it can include recalled inventory quarantined for removal. Unsellable On-Hand Inventory is the same population expressed as cost. A row with unsellable units is not automatically a quality defect, which matters later when the agent decides where that row goes.

{
  "period": { "grain": "weekly", "week_ending": "2026-08-29" },
  "view": "Sourcing",
  "columns": [
    {
      "field": "sellableOnHandUnits",
      "counts": "physically sellable condition",
      "measured_on": "last day of the selected period",
      "caveat": "taken before outbound units are deducted",
      "is_not": "availability to buy on the Amazon website"
    },
    {
      "field": "unsellableOnHandUnits",
      "counts": "unsellable condition, can include recall quarantine",
      "measured_on": "last day of the selected period",
      "caveat": "not necessarily a quality defect",
      "is_not": "a demand signal"
    }
  ],
  "grain_note": "daily granularity removed; weekly update cadence"
}

One more thing the label pass reports, because an empty dashboard reads exactly like a healthy one. Users who are not administrators must have the "FinancialReports" task-based role enabled in order to access the Inventory dashboard. Admins have all rights enabled by default, and only an admin can enable or disable a non-admin's rights. That is a grant, not a link somebody can forward.

Aged 90+ days and unhealthy inventory are two different measures of the same dollars, and only one of them has looked at your forecast

Aged 90+ Days Sellable Inventory is the cost of inventory that is at least 90 days old and in sellable condition on the last day of the selected time period. The glossary carries the same cohort as a unit count under the name Aged 90+ Days Sellable Units. Both sit at Sourcing and Manufacturing access on the Inventory dashboard. That metric knows how long the stock has sat and nothing else.

Unhealthy Inventory Amount is the excess cost of inventory on the last day of the selected time period based on forecasted demand. Amazon has already run the netting against its own forecast and handed you the answer as a dollar figure. The API side carries both forms of it, unhealthyInventory and unhealthyUnits.

Age and excess are independent, which is the whole reason the ranking needs two columns. Aged and not unhealthy means old stock the forecast still expects to clear. Unhealthy and not aged means recently received cost that demand will not absorb, and that stock will not show up in an aging report for up to another quarter.

The velocity column is Sell Through Rate, defined as units shipped compared to the units at Amazon's stores at the start of the period plus any units received during the same period, calculated as (shipped units - customer returns) / (on-hand units + received units). It is a Sourcing and Manufacturing metric on the Inventory dashboard, so it travels with the ranking rather than needing a second pull.

One constraint decides the period before the ranking runs. Unhealthy Inventory Amount is explicitly not available for the custom or daily view. The Skill therefore builds on a standard dashboard period and refuses a custom range outright, because on a custom range that column is absent rather than zero. The sort is unhealthyInventory descending, ties broken by aged90PlusDaysSellableInventory descending: unhealthy ranks the dollars demand will not clear, aged ranks the dollars that have already sat.

The Skill then produces the artifact finance asked for, with the open purchase order (PO) quantity carried alongside so a row's exposure is visible next to its excess:

The Read column is not a score, it is a lookup, and the unsellable rule is evaluated first because that row leaves the demand question entirely:

Sell-through and vendor lead time are modifiers on urgency, not ranking keys. A long Overall Vendor Lead Time in Days on a "stop buying into it" row means the reorder decision has to happen further ahead, not that the row outranks the one above it. Any sell-through floor in this table is a threshold your team sets. Amazon publishes none, and the agent will not invent one.

The out-of-stock rate in ARA is procurable OOS, and it is a Manufacturing-view metric your Sourcing-view login will never show

I did not believe our vendor manager and the dashboard could both be right until I put the two numbers side by side. The cohort was the difference, not the data.

ARA surfaces procurable product OOS (ROOS). Procurable Product OOS is the out-of-stock rate on all procurable products, calculated as ROOS = OOS GVs on procurable ASINs / total GVs, where GVs are glance views. It carries Manufacturing View access on the Inventory dashboard. A procurable ASIN is a condition indicating whether Amazon can fulfill a customer delivery promise, considering the ability of known vendors to supply the ASIN in the foreseeable future, that is, whether Amazon can obtain the ASIN from a vendor without a purchase order delay.

Replenishable OOS, the Rep OOS your vendor manager quotes in the quarterly review, considers only replenishable ASINs. ROOS considers procurable ASINs. Because the ASIN cohort is larger for ROOS than for Rep OOS, in most cases ROOS will be the lower percentage. Two correct numbers, two cohorts, one argument that never needed to happen.

A third metric hides in the same neighborhood and is not the same thing. Sourceable Product OOS is a glance-views-based metric measuring retail availability for all ASINs with a sourceable retail vendor, calculated as Sourceable Product OOS = OOS Glance Views (GVs) on sourceable ASINs / total GVs, also Manufacturing View on the Inventory dashboard. Sourceable is not procurable, and the Amazon Retail Analytics metric glossary gives each its own row for a reason.

Then there is the blank cell. ROOS and Unfilled Customer Ordered Units, the number of units ordered or pre-ordered but not shipped, are not visible in the Sourcing view, and that is expected behavior: the data is only available for manufacturing vendors, because it is ASIN-level data that cannot be attributed to a specific vendor. The general difference between the Sourcing and Manufacturing views belongs to the ARA Sales dashboard guide, which also covers the one route to enabling Manufacturing view, since that is owned by retail stakeholders rather than a settings page. What matters here is the Inventory consequence: a blank availability column in Sourcing is a permissions state, not a data gap.

GET_VENDOR_INVENTORY_REPORT carries the same fields every week, and the aged and unhealthy figures exist only on the API side

Amazon's own name for this pairing is "Inventory health & planning": the electronic data interchange (EDI) transaction is Sales (X12 852, EDIFACT SLSRPT), and the Selling Partner API (SP-API) report type is GET_VENDOR_INVENTORY_REPORT. I had the agent pull it the same way we pull the sales report: through the Selling Partner MCP it calls Reports_createReport for that report type and period, waits on Reports_getReport, and reads the payload with Reports_getReportDocument.

The Amazon Retail Analytics EDI/API integration playbook maps the Inventory fields element by element, and reproducing that mapping as written matters more than making it read logically:

The EDIFACT equivalents are QTY+145 for sellable on-hand units and QTY+21 for quantity on order. Note the third row: the EDI element is literally named quantity_oos, and it maps to the unfilled customer ordered units metric, not to any out-of-stock rate.

Now the part that decides the architecture. Eight Inventory fields exist only on the API side with no EDI equivalent at all: netReceivedAmount, sellableOnHandInventory, unsellableOnHandInventory, aged90PlusDaysSellableInventory, unhealthyInventory, unhealthyUnits, overallVendorLeadTime, and vendorConfirmationRate. The entire excess ranking from the section above is in that list. An EDI-only integration cannot produce this audit, no matter how carefully it is parsed.

The trade runs both directions. Six EDI elements have no API equivalent: quantity_on_hold (ZA*HL), days_supply_daily (ZA*DS), weeks_supply_daily (ZA*WS), forecast_variance (ZA*FV), quantity_in_transit (ZA*QI), and quantity_ending_balance (ZA*QE). A warehouse migrating off EDI loses those six columns, and days of supply is the one people miss first. Amazon offers an EDI and API system so integration can be chosen freely, so supply-chain messaging can stay on EDI while reporting runs on API. That is a choice worth making deliberately rather than discovering after the cutover.

# Skill: ara-inventory-health-audit
# Runs on the Selling Partner MCP, grounded by Atlas (amazon_vendors).
report:
  type: GET_VENDOR_INVENTORY_REPORT
  period: standard        # never custom, never daily
  cadence: weekly         # matched to the dashboard's weekly update
calls:
  - Reports_createReport
  - Reports_getReport
  - Reports_getReportDocument
rank:
  primary: { field: unhealthyInventory, order: desc }
  tiebreak: { field: aged90PlusDaysSellableInventory, order: desc }
refuse:
  - custom_or_daily_period    # Unhealthy Inventory Amount is absent there
  - unlabeled_availability    # every OOS figure carries its ASIN cohort
  - invented_threshold        # every cutoff is the operator's, stated as theirs
gate: require_human_approval

What happens next

The audit becomes a recurring Skill on the dashboard's own clock rather than a calendar habit, so a ranking is never built on a period the Inventory dashboard has not refreshed. A run raises a notification only when a row changes its read, for example when "old, forecast covers it" flips to "stop buying into it", or when a row crosses a threshold your team set. The list stays a recommendation until a person approves it: no reorder change, no removal request, and no note to the retail partner ships on the agent's authority.

Four things leave this audit rather than sitting in it. Rows with unsellable units go to the returns and removals path, where your purchasing terms govern the return cap as a percentage of cost or as a unit count per period, the minimum and maximum unit quantity per removal order, and the maximum and minimum volume per return shipment to the vendor. A blank ROOS or unfilled-units column forks to permissions, not to data. An ASIN that looks unowned forks to ASIN mapping, since ASINs not properly mapped to ARA through vendor hierarchy, ASIN catalog attributes, and vendor group setup can populate inaccurately, and the route there is your retail partner or a Contact Us case requesting ASIN mapping assistance. And the forecast behind the word unhealthy forks forward to the Forecasting dashboard, which is the subject of the next guide.

The weekly pull then lands in the Amazon Agent Data layer beside the spend the Amazon Ads MCP pulls and the sales figures the ARA Sales dashboard guide reconciles, so excess cost and advertising cost share a week-ending key. When the question is which dashboard or report type answers a metric at all, the ARA report and metric glossary guide routes it before this audit runs.

Amazon publishes every definition in this guide. What was missing was one ranked list that read the condition, the view, and the forecast before it read the total.

Next in the ARA arc: the forecast that decides what counts as unhealthy, turned into a production plan you can hold your factory to.