Select Page

Amazon Reporting Issues

agsdix-smt1-event

November 1, 2020

agsdix-fas fa-user

Kalvin Mizzi

agsdix-fas fa-comment

2

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).

Share this post

Kalvin Mizzi

Online Seller, Finance Geek, Developer

Kalvin Mizzi has over 20 years experience in the E-commerce industry.  He holds an Economics degree from University of Toronto, where he graduated with Honors, and is a self-taught programmer and entrepreneur.

Kalvin started his career in the real estate development industry, raising equity/debt, financial modeling, and sales/brokerage.

He is passionate about systems and helping other E-commerce sellers.

Related posts

2 Comments

  1. ecomazan guy

    Great info on financial events – this is the only reference I’ve found to cover this. Took me quite a while to figure all that out. I chose to solve it this way:

    “Another alternative would be to explicitly keep track of PostedAfter and PostedBefore dates for each request ”

    Another advantage of this solution is that you can apply a pseudo-posted date on service fees which otherwise don’t have a date on them.

    This isn’t easy – you have to be very careful about exception handling, transactional integrity, server restarts, etc.

    But AFAIK, this is working.

    Currently I’m working on migration to SP-API and wondering if these issues have been solved (still battling my way thru OAUTH right now)

    Reply
    • Kalvin Mizzi

      Yes Amazon has so many nuances and when you on support tickets with them, they rarely claim that it is a big or poor design. They simply say it is working as intended.

      For SP-API, we actually just started the integration two days ago and got our first success call within a couple hours. I am lucky as two of my team members have experience with SP-API and there are steps that are not documented that are required to get it working. The first time one of my team members tried, it took a ton of back and forth with dev support and after 2 weeks they told him the undocumented steps. I’ll add this as my next blog topic idea.

      Reply

Submit a Comment

Your email address will not be published. Required fields are marked *