What each Amazon Vendor Central report in Retail Analytics measures, why its manufacturing and sourcing views must never be added, and how to query them.
Vendor Central has no shortage of reports. The trouble is reading them. The same sale shows up twice under two views, the margin column belongs to Amazon rather than to you, and inventory numbers that look like daily totals are snapshots you must never add up. Most vendor teams learn these rules the hard way, one wrong slide at a time.
This guide walks through the reports in Retail Analytics, what each one measures, the traps inside them, and how to put them in front of Claude, ChatGPT or a BigQuery notebook so you can ask questions instead of downloading spreadsheets. The Amazon facts below were checked against Amazon's Selling Partner API documentation on 30 October 2026.
In Vendor Central, the reports sit under the Reports menu, with Retail Analytics as the main area for sales, traffic, inventory and margin. Brand Analytics sits next to it for search terms, Market Basket and Repeat Purchase if you are the brand owner. Payments, invoices and remittances live under Payments, not under Reports, which is why finance and the category team often work from two different sets of numbers.
The same Retail Analytics data is available through the Selling Partner API as report types that start with GET_VENDOR_. Amazon lists them under the Brand Analytics role, so an application needs that role to request them. That is the route any tool, DataDoe included, uses to bring vendor numbers out of the portal.
Two details in Amazon's documentation matter in practice. Refreshed inventory data arrives about 72 hours after a period closes, so last week's numbers are not final on Monday morning. And the forecast cannot be requested for past dates: Amazon returns only the newest one. If you want to know how the forecast for Black Friday moved over the summer, you have to save every weekly forecast yourself as it arrives.
The Sales and Inventory reports come in two views, and Amazon asks for one of them on every request.
The views overlap. For a brand that sells all its own products to Amazon, shipped units are often identical in both, and adding them doubles the business on paper. Ordered revenue exists only in the manufacturing view. Contra-COGS is usually filled only in sourcing. The rule is simple and easy to forget under deadline: pick one view per question, and never sum the two.
A second trap sits in the selling program. Amazon reports Retail, Amazon Business and Fresh separately. A category manager asking about "Amazon sales" usually means Retail, while the finance team may expect Business orders in the total. Agree on which programs count before the first dashboard goes out.
Net Pure Product Margin is Amazon's margin on your products, not yours. Amazon describes the report as data on its "net pure product margins for selling a vendor's items". It is the number Amazon's buyers look at in annual negotiations, which is why it matters, but it says nothing about your own cost of goods or profit.
The same caution applies to the money columns in the sales data:
Read together, the gap between shipped revenue and shipped COGS shows how hard Amazon is discounting your items. That is useful context for a price conversation. It is not a profit and loss statement.
Three more rules keep vendor reporting honest:
Retail Analytics tells you what Amazon sold. It does not tell you what Amazon paid you. For that you need two other data sets: invoices, with their status (in progress, paid, partially paid, deducted, rejected), and remittances, each payment Amazon made and the invoice lines, deductions, vendor returns and advertising charges it covered.
One limit is worth knowing before you build a chargeback dashboard: in Amazon's remittance data, a deduction appears as a negative line with a description and an invoice type. There is no chargeback reason code, dispute status or co-op agreement in it. Matching shortages to purchase orders still needs the portal or your own records.
DataDoe brings the vendor reports into tables you can query from an AI client or SQL: daily, weekly and monthly sales, traffic and inventory per ASIN and for the catalog, the weekly demand forecast stored as a snapshot every week, hourly Rapid Retail Analytics, purchase orders, shipments, Direct Fulfillment orders, invoices and remittances. Both views are fetched and kept on one row per ASIN and day with their own prefixes, so the AI can be told exactly which view a question needs. Sales and traffic history goes back about two years. The daily fetch starts at 2am in the vendor's local time zone.
With the account connected to Claude, a category manager can ask questions like these in plain English:
The data is the same whichever client you use. Claude, ChatGPT and other AI clients reach it through MCP, developers through the REST API, and data teams through a BigQuery data warehouse that sits next to the rest of the company's data. The developer view of the same data, with endpoints and tables, is on the Amazon Vendor Central API page.
Vendor accounts can also act, not only read. Purchase order acknowledgements, shipment confirmations and Direct Fulfillment updates are available as Actions. Actions stay off until you enable them, most AI clients ask before a change, and every change is logged.
Some questions stay outside Vendor Central data, whichever tool reads it:
If your brand sells both ways, the reports above cover only the first-party side. Seller Central has its own Business Reports, settlements and FBA data, and the two do not line up field by field. Our comparison of Vendor Central and Seller Central explains where they differ, and the DataDoe page for vendors shows how both sides sit in one schema next to Amazon Ads.
DataDoe costs $97 a month with a 14-day free trial, and the plan includes Vendor Central, Seller Central and Amazon Ads connections in the same organization. Connect your vendor account, wait for the first load, and ask your AI client the question you would normally answer with three downloads and a pivot table.