Free · No email required
Three numbers, one truth
Seller Central, the SP-API Orders API and Data Kiosk all answer “how much did I sell?” — and people report three different numbers. Measured on a real seller account across two closed months, all three agree exactly. Every discrepancy comes from how the fields are read.
One page. Print it, or forward it to whoever asks why the numbers don't match.
Three Amazon surfaces answer “how much did I sell?” for the same window, and sellers routinely report three different numbers. Measured on one real seller account across two closed months, pulled 2026-08-31: all three agree to the penny. Every discrepancy comes from how the fields are read — not from Amazon disagreeing with itself.
| Metric | Authoritative source | How far the others drift | What you say when the client asks |
|---|---|---|---|
| Revenue ordered product sales |
Data Kiosk orderedProductSales |
Seller Central and Data Kiosk are identical in both months (£8,918.85 and £6,379.50). The Orders API matches to the penny — but only if you sum ItemPrice raw. |
“It matches your Seller Central exactly — they are the same Amazon dataset. If our number ever differs from yours, that is our bug, not Amazon disagreeing with itself.” |
| Units | Any — all three agree | Exact across all three sources in both months (796 and 566 units ordered). But one month holds three different unit counts: 796 ordered, 873 shipped, 697 order lines. | “Those are three different questions, and all three answers are correct. Tell me which one you want the report to track and I will hold it to that.” |
| Order items | Data Kiosk totalOrderItems |
697 and 473. The Orders API returned 698 lines in June — one more — because getOrderItems can return a line with QuantityOrdered = 0. |
“The API returns a zero-quantity cancelled line. We filter it out. That is the one-line difference, and it carries no revenue.” |
| Shipped, refunded, orders shipped |
Data Kiosk the only source |
Seller Central and Data Kiosk agree exactly (873 shipped / 27 refunded in June). The Orders API has no equivalent aggregate at all. | “Shipped and refunded units do not come from the orders feed. Only the Business Report carries them, so that is where we take them from.” |
| Amazon Business (B2B) |
Either — both carry it | Identical in both. Worth 11.6% of June revenue and 11.8% of July — in a separate column most dashboards never read. | “Roughly an eighth of your revenue is Amazon Business. It sits in its own column, so tools that only read the headline figure silently drop it.” |
| Daily figures | Data Kiosk / Business Report |
Every day reconciles — but only in the marketplace's own timezone. Bucketed by raw UTC PurchaseDate, just 20/30 and 21/31 days match. Converted to Europe/London: 30/30 and 31/31, worst gap £0.00. Only 6 order lines a month move — all of them placed in the 23:00 UTC hour. |
“Amazon reports your days in UK local time; the orders feed timestamps in UTC. During BST that pushes a handful of late-evening orders into the next day. Convert first and every single day matches to the penny — we do.” |
| When the number stops moving |
— | June 2026 was captured on 2026-08-15 and re-captured on 2026-08-31: identical on all six metrics, 16 days apart. | “Once a month closes, Amazon's figure stops moving. If a past month has changed on your side, something changed in how it was pulled — not at Amazon.” |
Four ways an orders pull goes wrong
Each produces a number that looks plausible and moves month to month like a real one. The first three change the total; the last moves it between days. Measured on the same account:
| Mistake | June 2026 | July 2026 | Why |
|---|---|---|---|
Multiplying ItemPrice by QuantityOrdered |
+40.3% (£3,595.75) | +59.7% (£3,806.61) | ItemPrice is already the extended line total. Multiplying squares the quantity on every multi-unit line. |
Subtracting PromotionDiscount |
-£12.28 | -£2.82 | orderedProductSales is already gross of promotion discounts. Subtracting them removes the discount twice. |
Counting QuantityOrdered = 0 lines |
+1 order item | none that month | Cancelled lines can come back with zero quantity. They inflate the line count, never the revenue. |
Bucketing days by raw UTC PurchaseDate |
10 days wrong | 10 days wrong | PurchaseDate is UTC; the Business Report attributes to marketplace-local time. This one does not change the month — it moves revenue between days. |
The one-line check
Sum ItemPrice across every non-cancelled order line for a closed month,
without multiplying by quantity and without subtracting promotions. It should equal
orderedProductSales exactly. On this account it did, twice:
£8,918.85 in June and
£6,379.50 in July, both to
£0.00.
For daily figures, convert PurchaseDate to the
marketplace's timezone first — then every day reconciles too. If yours still does
not, the difference is in your reader, not in Amazon. That is good news: a bug you can
fix rather than a vendor you have to argue with.
Method. One UK seller account, windows
2026-06-01–2026-06-30 and
2026-07-01–2026-07-31, pulled
2026-08-31. Sources: Seller Central
GET_SALES_AND_TRAFFIC_REPORT, SP-API Orders
(getOrders + getOrderItems, exhaustive pagination,
697 and 479 orders), and Data Kiosk
analytics_salesAndTraffic_2024_04_24. Cancelled orders excluded.
30- and 31-day windows compared
day by day as well as in total.
If yours doesn't reconcile
I build the reporting pipelines behind this kind of reconciliation — SP-API, Data Kiosk, Amazon Marketing Stream, into a warehouse you can actually query. If your numbers disagree and you'd rather not spend a fortnight finding out why, tell me where they diverge.
Work with me