Financial Accounting · Inventory Management
Amazon FBA Inventory Reconciliation in 2026
Updated September 2026. I wrote the investigation below in April 2021, as an open letter to Amazon, with my own case IDs in it. Amazon has since answered most of it. Not by fixing those three reports, by replacing them. This new section covers what exists now. The 2021 letter is kept underneath, unedited, because the reports it dissects are the ones a lot of older tooling still reads.
What actually changed since 2021
Amazon replaced the reports. The three I tested in 2021 are no longer on the FBA report-type list at all: Inventory Reconciliation, Daily Inventory History, Monthly Inventory History. What sits there instead is the Inventory Ledger Report, in two views, and both are available over SP-API.
The Summary View is described by Amazon as being like a bank statement of your inventory: starting balance, received inventory, customer orders, customer returns, adjustments, removals, ending balance. Read that list again and compare it to the formula I quoted from Seller Central in 2021. It is the same formula. The difference is that it is now a report you can request instead of an equation you were expected to assemble yourself out of six other reports.
The Detailed View is the movements underneath it: shipments, receipts, customer returns, vendor returns, adjustments, warehouse transfers, with eighteen months of history behind it.
Two of my six 2021 asks are clearly answered by that replacement. You can pull it from the API, which was the one that hurt most: in 2019 MWS level 2 support told me the reconciliation report simply was not supported, and it still was not when I re-tested in April 2021. And you can aggregate monthly, weekly or daily instead of being forced onto the first of the month by a date picker.
The unified US-and-Canada one I assumed was answered too, until I went and read the parameters. The ledger aggregates by country, but that is about where the units physically sit, which is not the same question as which marketplace a unit belongs to, and the report Amazon does publish for splitting inventory by country is scoped to sellers in Europe. So I am leaving that ask open. The commingled-barcode SKU mixups, the 72-hour data volatility and the missing FNSKU on the shipments report I have not re-tested at all. If you are still hitting any of them, I would like to hear about it.
So is FBA reconciliation solved?
No, and the reason is structural rather than technical.
A ledger you receive is still somebody else’s ledger. It is a very good one now, and it is the right shape, and it arrives in a form you can compute on. But it is Amazon telling you what Amazon believes happened in a building you have never been inside.
An inventory consultant put the general version of this to me on a call in December 2025, talking about a third-party warehouse rather than FBA:
“Right now the 3PL we use, I don’t want to integrate with them directly because I don’t really trust their numbers. So I want to have that degree of separation. So I know what should be and I can compare it to what they report on.”
That is the whole job, and she said it better than I have. She did not want their feed. She wanted her own number to check theirs against.
FBA is the case where this is easiest to forget, because it does not feel like a third-party warehouse. It feels like part of Amazon, and Amazon is where the sale happened, so the number has an authority that a 3PL’s spreadsheet never gets. It is a warehouse you do not control, staffed by people you do not employ, and the further a unit travels from someone who answers to you, the longer a wrong number survives before anybody notices.
What we do with the ledger
We pull both views on a schedule, build our own on-hand from the movements, and then compare our balance to the balance Amazon states.
Here is the part worth explaining, because it is the part I have not seen elsewhere. When the two disagree, we do not overwrite ours with theirs and we do not quietly drop the difference. We write a row: this FNSKU, this fulfillment center, this disposition, this date, this quantity, and the cost of goods attached to it. It carries a reason: the summary did not match the movements, an event type we do not recognize, a shortfall, a manual adjustment. It carries an investigation status too, starting at new and moving through investigating and case opened to one of three endings, which are reimbursed, written off, or resolved.
The row we write when the two ledgers disagree, and where it can end up.
I described the mechanism on a call in May 2025 like this:
“You have many times where Amazon will say ending inventory on a day is 20, but the ledger adds up to 18. We’ve built in automatic reconciliation in the form of detecting those anomalies.”
Twenty against eighteen is a two-unit disagreement. On its own it is noise. Across a catalog and a quarter it is a number your accountant has to do something with, and the difference between a business that reclaims it and one that does not is whether anyone wrote it down on the day it happened.
Because the difference has a cost basis on it, it posts as an accounting transaction rather than living in a spreadsheet. That matters at month end, when the question stops being how many units went missing and starts being what they cost.
We run the comparison daily, and daily is deliberate rather than lazy. In our own runs Amazon’s ledger lands one to two days behind, so pulling it every fifteen minutes would only re-measure the same lag while spending SP-API rate limit that the order and shipment syncs need more. That number is our observation across tenant accounts, not something Amazon publishes, so treat it as a working figure rather than a guarantee.
What this does not fix
It does not make Amazon’s number right. It tells you, with a date and an amount, where the two records stopped agreeing, and gives you something to open a case with.
It does not replace your own investigation either. A reimbursement case is a human writing to Amazon about a specific shortfall. The system’s job is to hand that human a list they did not have to build.
And it does not help if FBA is the only place your stock is. If everything you own sits in Amazon’s warehouses and you sell nowhere else, Amazon’s ledger is your ledger, there is no second record to compare it against, and Seller Central plus a good accountant will serve you better than we will. This gets useful when the same product exists in more than one place, FBA plus a 3PL or FBA plus your own shelf, and the totals have to agree at the end of the month.
If your problem is the warehouse rather than Amazon, keeping a 3PL in check is the same argument applied to a partner you chose, and the mechanics differ enough to be worth reading separately.
The question to ask
Whoever you are evaluating, ask what their system does when Amazon’s stated ending balance and the sum of Amazon’s own movements disagree.
“It syncs your Amazon inventory” is not an answer to that question. A founder I spoke to in early 2022 had spent a month trying to go live on another system and never did, because, in his words, they could not pull his FBA numbers properly and their advice was to contact Amazon about it. Amazon was not going to do anything about it. That is the moment you find out whether a vendor built reconciliation or built a sync.
If you want to see what ours produces against your own account, I will do that demo myself. Book a demo.
The original 2021 investigation
Everything below is as published on 13 April 2021 and has not been edited. The report names and MWS report types in it are the ones Amazon has since retired; the case IDs are real and were mine.
Throughout this blog post you may see specific case IDs or other situational specific information. This post is being sent to the Amazon team in order to try to promote fixes to the Amazon issues. I wanted to post the entire content as a blog post as well as I am sure there are many other frustrated sellers facing similar issues.
I have discovered that inventory accounting with FBA has some big problems.
The worst sellers affected are those who have Unified accounts (i.e. selling in US and Canada) and those who use Manufacturer Barcodes (Commingled inventory). However, all FBA sellers are affected.
As an Amazon Seller, I need to be able to do inventory accounting and calculate the cost of goods sold for the end of a period.
Typically cost of goods sold is calculated at the end of each month.
Using a periodic inventory system, cost of goods sold relies on the ending inventory count for a given month. Because FBA acts like a warehouse location, sellers rely on Amazon to provide reports telling them how much inventory they have at the end of each month.
Amazon provides this page as an Amazon Fulfillment Reports explanation: https://sellercentral.amazon.com/gp/ssof/reports/searchv2.html
On this page, the magic formula Amazon describes for inventory balance calculation is:
Starting inventory balance + received inventory - customer orders + customer returns +/- adjustments - removals = ending inventory balance
Let’s call the received inventory, customer orders, customer returns, adjustments, and removals “FBA Inventory Movements“
There are two reasons why a seller would need to know the inventory snapshot at the end of a given month:
- Establish a starting inventory balance
- Verification check that the previous starting inventory balance + FBA Inventory Movements = ending inventory balance
There are three potential reports that have inventory snapshot data:
Inventory Reconciliation
Seller Central Link
MWS API ReportType
_GET_FBA_RECONCILIATION_REPORT_DATA_
Supported by API?
No
Returns accurate sku?
If you sell only in the US, maybe
If you sell in the US and Canada, no
If you sell in the US and Canada, the sku returned appears to be randomly picked between the sku on your US account and the sku on your Canada account. I know this because I sell in both marketplaces and I use a different sku format for each marketplace.
I reported this issue in 2019 with Case ID 5884459081 and was told that because my account is unified (US and Canada), the data returned is shared between the two marketplaces. The final reply I got was as follows:
These two skus are using the manufacturer barcode, which have them share inventory on the report. The selection of which sku is used is not determined at this time. However, the inventory is all accounted for under SKU: 1727572-FBA-CA for both SKUs. This is working as intended.
You can use an Amazon Barcode for the SKU: 1727572-FBA so the report will not unify both SKUs. This is the only alternative we have at the moment.
If you need to reconcile your units in each marketplace, you will need to use the Online Reconciliation if you want specific result for the SKU: 1727572-FBA.
I don’t believe that “working as intended” is accurate here when “The selection of which sku is used is not determined”. I do suppose that another condition to when this problem occurs is not just having a unified account, but also using Manufacturer Barcodes instead of Amazon Barcodes (AKA Sellers who use commingled inventory).
Returns accurate quantity?
Yes and no. It is accurate but does not return inventory level for just the US marketplace if you sell in both US and Canada. It returns only the unified total count between the two marketplaces.
This is a problem and breaks the reconciliation process because the FBA Inventory Movements reports do return the inventory level specific to a marketplace.
Google Sheets example link
https://docs.google.com/spreadsheets/d/1itG_gFHQxSiy4eLI6_Y2aOvwiK8xiUphoubrteGXeiI/edit?usp=sharing
Example ReportId
26890806852018661
Quantity returned in example
30
Other notes
Issue 1:
This report is not supported by the MWS API. Since I am needing to calculate cost of goods sold for both myself as a seller and other sellers through an app I am developing, this is an inefficient workflow requiring the user to manually generate the report via Seller Central and then upload it to my software.
If you attempt to RequestReport of type _GET_FBA_RECONCILIATION_REPORT_DATA_ via MWS API, you will get a result of “_DONE_NO_DATA_”
I’ve opened up a support ticket in 2019 (Case ID 6050777341) which reached MWS level 2 support (mws-level2-na@amazon.com) and received a reply:
I understand you have questions about requesting a FBA reconciliation report via API using the report type _GET_FBA_RECONCILIATION_REPORT_DATA_.
Unfortunately, the report is not supported by the API at this moment.
Currently, the only reports supported by the API are the ones in the following documentation page:
http://docs.developer.amazonservices.com/en_US/reports/Reports_ReportType.html
I’m truly sorry for the frustration you have encountered with this situation.
I have informed our Engineering and Development teams, and they have added your comments as feedback for a Feature request. I really appreciate that you took the time to let our offices know about this limitation. We take your interactions with our programs very seriously, and it is real-world feedback such as you have provided that ultimately helps Amazon become a better platform for everyone involved.
I then tested this again in April 2021 and got the same result
Issue 2:
As of March of 2021, you can no longer calculate end of month inventory for the desired month. I have a separate case open with just this issue: Case ID 8135637491. You can see in this screenshot that Seller Central (the only way to generate this report since no MWS API access), only allows the 1st day of each month to be chosen as the date.
This causes problems because most businesses get inventory snapshot reports once per month at the end of each month (whether their own warehouse or a 3PL partner). The timestamp of inventory count across warehouses (including FBA) needs to be the same in order to assure there is no double counting of inventory between warehouses.
This disabling of any date but the end of the 1st day of a given month is a NEW bug in the UI that appeared sometime in March. It is very restrictive and makes reconciliation even more difficult.
Daily Inventory History
Seller Central Link
https://sellercentral.amazon.com/reportcentral/INVENTORY_SNAPSHOT/0
MWS API ReportType
_GET_FBA_FULFILLMENT_CURRENT_INVENTORY_DATA_
Supported by API?
Yes
Returns accurate sku?
No, returns the sku from the Merchant Fulfilled Offer, not the FBA offer
Returns accurate quantity?
No, in our test example it returned 29 units total (28 US, 1 Canada), different from the reconciled count of 30 in the Inventory Reconciliation report, which I assume is the accurate authority
Google Sheets example link
Example ReportId
28946506007018729
Quantity returned in example
29
Other notes
Inventory separated by FBA fulfillment center location
Monthly Inventory History
Seller Central Link
https://sellercentral.amazon.com/reportcentral/INVENTORY_MONTHLY_SNAPSHOT/1
MWS API ReportType
_GET_FBA_FULFILLMENT_MONTHLY_INVENTORY_DATA_
Supported by API?
Yes
Returns accurate sku?
No, returns the sku from the Merchant Fulfilled Offer, not the FBA offer
Returns accurate quantity?
Yes, in our test example it returned 30 units total (29 US, 1 Canada), equal to the reconciled count of 30 in the Inventory Reconciliation report, which I assume is the accurate authority
Google Sheets example link
Example ReportId
28951817463018729
Quantity returned in example
30
Other notes
Inventory separated by FBA fulfillment center location. Includes items with 0 end quantity.
Out of these 3 reports, all of them return inaccurate merchant sku, making it difficult to match the report data with the inventory item for accounting. The Inventory Reconciliation report may return both accurate sku and count if you are not a seller who sells in both US and Canada. If you are, the wrong sku returned and lack of separation between inventory in each country makes the report virtually unusable.
Amazon gives tips on the Amazon Fulfillment Reports page to use FNSKU to reconcile inventory. This contradicts their inventory reconciliation formula:
Starting inventory balance + received inventory - customer orders + customer returns +/- adjustments - removals = ending inventory balance
.. since, the customer orders report (aka Amazon Fulfilled Shipments) does not include the FNSKU field.
Another note. You must request FBA Inventory Movements reports with an end date of no later than 72 hours prior to current date. Otherwise, the data returned in FBA Inventory Movement reports may be different than if you request the same report with the same date range after the 72 hours.
There is also random situations where the SKU returned in the FBA Inventory Movements is wrong. The most common error is the merchant fulfilled sku being returned instead of the amazon fulfilled sku. This could be related to Manufacturer Barcode mixups as well.
Summary
To summarize, in order to allow Amazon sellers to do inventory accounting, Amazon needs to fix the following:
- Have Inventory Reconciliation Report only return data for the marketplace the seller is in when requesting the report
- Allow Inventory Reconciliation Report to be accessible via MWS API
- Fix bug with Manufacturer Barcode sku’s returning inaccurate sku’s in FBA Inventory Movements Reports
- Fix Seller Central bug to allow seller to choose any date for end of Inventory Reconciliation Report
- Disallow User to download FBA Inventory Movement Reports with end dates later than 72 hours prior to current date OR fix the issue with data being inaccurate for a fixed date range depending on when it is requested
- Add FNSKU to Amazon Fulfilled Shipments report, so that seller can follow Amazon’s tip of using the FNSKU field in each report (as opposed to merchant sku) to reconcile inventory