Reports generated by Amazon on Seller Central or via the Reporting API have some challenges. This blog post is geared towards the more technical reader who is familiar with the Amazon reporting structure. For those users who are not, simply know that reporting from Amazon is not as robust as you would expect from a company as big as Amazon. Data relied on from their reports should not be assumed to be 100% accurate.
Fulfillment Reports
Inventory Reconciliation
- Link
- API Name: _GET_FBA_RECONCILIATION_REPORT_DATA_
- The Inventory Reconciliation report is generated at the end of each month and summarizes the total reconciled inventory for each SKU in FBA. This is important in order to determine whether the end of month inventory is in sync between Amazon and your inventory management software.
- This report is not supported by the API despite being a very integral part to inventory operations
Other Reports
- A common problem among many other fulfillment reports has to do with the lack of a unique identifier from Amazon for each record, resulting in possible duplicates are skipped records.
- There are band-aid workarounds to this issue, either involving:
- Applying the “hash” function to a dataset, which could result in lost data if two records have exactly the same data but are not duplicates (this is possible).
- Keeping track of explicit date filters of requests, which could also fail since Amazon has been known to produce different results for a fixed date range (retroactively adding or removing items).
Financial Events
- Link
- While technically not an Amazon Report, the data from the Financial Events API is used to reconcile payments from Amazon to seller, with a breakdown of all the transactions that result in the end balance deposited into the seller bank account.
- There is no unique transaction id for each line item, leading to reliance on the PostedAfter date to make sure duplicate events are not downloaded
- PostedAfter does not work for checking for unique records since not all financial events returned from Amazon have the PostedAfter data, even though they get filtered by it (Service Fee Events for example)
- Alternative is to apply a “hash” function to each event, testing for uniqueness. As of Fall 2020, this also fails since Amazon changes the order of the details of some events inconsistently.
- Example: For a Shipment Item, one call may return FeeType FBAPerUnitFulfillmentFee first, then the next call even just one minute later may return FeeType FBAPerOrderFulfillmentFee first
- The result is the hash for the two subsequent calls are unique for the Shipment Item events, resulting in duplicate records
- A band-aid fix for this would be to the contents of each financial event alphabetically first before applying the hash
- Another alternative would be to explicitly keep track of PostedAfter and PostedBefore dates for each request for financial events, and never overlap the date range.
- This could work in theory, however, Amazon has been known to produce different results for a fixed date range (retroactively adding or removing items).