How to read the Amazon Inventory Ledger

A bank statement for your stock

Amazon's own description of the Inventory Ledger is the best one: it is like a bank statement of your inventory. It starts with a balance, lists everything that came in and went out - units received, customer orders, customer returns, adjustments, removals - and ends with a balance.

That framing tells you how to use it. A bank statement is how you check that the bank has not lost your money. The Inventory Ledger is how you check that Amazon has not lost your stock - and, when it has, it is the evidence you attach to the claim.

If a unit is missing, the ledger is where it went missing.

Summary view or Detail view

The report comes in two views, and they answer different questions.

Scroll the table sideways for the remaining columns.

To download it, Amazon's own steps are: from the Reports menu, choose Fulfilment; under the Inventory section, choose Inventory Ledger; then pick the type of report - the Detailed view has an Event type filter, so you can pull only Receipts, for example - set the date range and generate it.

Source: Amazon Seller Central, FBA lost inventory reimbursement policy (amazon.in, read September 2026).

The form has a View Online tab and a Download tab. Leave ASIN, Merchant SKU and FNSKU blank to cover every product. The Summary view adds two choices, Aggregate report by location (Country or Fulfilment centre) and Aggregate report by time period, and you can narrow either view to one FC or one disposition.

Through Amazon's Selling Partner API the two views are the report types GET_LEDGER_SUMMARY_VIEW_DATA and GET_LEDGER_DETAIL_VIEW_DATA.

The columns that matter

These are the Detail view columns you will work with most:

Scroll the table sideways for the remaining columns.

The Summary view instead carries one column per movement - Starting Warehouse Balance, Receipts, Customer Shipments, Customer Returns, Damaged, Other Events and so on - ending in Ending Warehouse Balance, with the fulfilment centre in a Location column.

Disposition matters more than it looks. The ledger keeps sellable and damaged units as separate balances, so one product at one centre can have several rows. In one seller's ledger six dispositions appeared in three months: SELLABLE, CUSTOMER_DAMAGED, CARRIER_DAMAGED, DEFECTIVE, WAREHOUSE_DAMAGED and DISTRIBUTOR_DAMAGED. Only SELLABLE units can be sold.

What each event type means

Scroll the table sideways for the remaining columns.

Amazon's API names the same six types without spaces - Receipts, Shipments, CustomerReturns, VendorReturns, WhseTransfers and Adjustments - but the file itself writes some with spaces: "Customer Returns" and "Vendor Returns". If you filter the file in a spreadsheet, filter on what the file actually says.

Reconcile one SKU

Pick one SKU at one fulfilment centre, for one month. Take the starting balance, add everything that came in, subtract everything that went out. The result must equal the ending balance. When it does not, the gap is what you are looking for.

It is the same arithmetic Amazon uses on a suspected warehouse loss: total received inventory plus returns, minus sales, removals, adjustments and credits.

Source: Amazon Seller Central, FBA lost inventory reimbursement policy (amazon.in, read September 2026).

Do this for the few SKUs that matter most before trying all of them. The habit of reconciling ten SKUs a month catches more than a once-a-year attempt at a thousand.

Three traps

1. A transfer is not a loss

Amazon moves stock between its centres to put it closer to customers. In the ledger that looks like units disappearing from one centre and, separately, appearing at another - sometimes days later, because the units were in transit. Read either half alone and you will see a loss, or a windfall, that did not happen.

2. The date column you pick changes the totals

The Date column is the local calendar day. Date and Time is in UTC, which runs five and a half hours behind India. An event in the first five and a half hours of an Indian day carries that day's local date but the previous day's UTC date, so daily totals built from the timestamp will not match Seller Central's. Build daily figures from Date.

3. The Detail view does not know your opening stock

Adding up Detail events tells you how stock changed, not how much you had. If you start from zero, every SKU that already had stock will count down into negative numbers. Take the opening balance from the Summary view, then apply the Detail events on top.

From ledger to claim

When the arithmetic leaves units unaccounted for, check three things before you open a case:

1. Is there a matching transfer in at another centre in the same period?
2. Did the units move into a damaged disposition rather than vanish? They will show as a SELLABLE decrease with an increase in another disposition.
3. Has Amazon already paid for them? Look up the FNSKU in the reimbursement report.

If all three come back empty, you have a claim, and the Detail rows - date, FNSKU, quantity, fulfilment centre, reference ID - are the evidence. The FBA reimbursement guide covers what Amazon pays automatically and when you have to file - for a unit lost in the fulfilment centre on amazon.in, within 60 days of the inventory adjustment.

The ledger, read for you

Unilytic pulls both views from Amazon's API, takes the opening balances from the Summary view and the movements from the Detail view, and keeps one row per SKU, fulfilment centre and disposition per day. That is what drives the stock dashboard, per-centre days of cover, and the send list.

app.unilytic.in/dashboardFull size

Questions sellers ask