How FBA manual reconciliation actually works when you're not running a giant brand
Most people treat their monthly Amazon FBA payouts as a black box. You check your bank account, you see a number, and you hope it matches your books. That approach works fine until it doesn't. The moment you have a discrepancy of a few hundred dollars, you're already two weeks behind trying to trace it. I stopped doing that about four years ago and built a manual process that takes me roughly 45 minutes per month for a catalog of around 30 SKUs. It isn't glamorous. It catches things automated tools routinely miss. The core problem is that Amazon's payout report and your sales reports don't line up cleanly. They use different timestamps, different granularity, and different logic for refunds. A refund processed in January might show in your February settlement. Shipping rebates appear in one report and disappear from another. If you're tracking profitability per SKU, these misalignments compound fast.
Monthly Amazon FBA Manual Reconciliation Process
Here is the actual workflow. First, go to Reports > Payments in Seller Central and pull the Settlement Report for the full calendar month. Download it as a TSV file. Amazon sometimes gives you a zip of multiple files — you want the one labeled "Payments" not the "Transaction" overview. The TSV has separate sheets for Transactions, Shipment Details, and Event Details. Keep all three. Next, pull the Business Reports page showing Units Ordered by date for the same month. Export that CSV. This gives you your actual sell-through number per day, which is your anchor point. Then open your accounting software or spreadsheet and create a simple mapping file. I use columns for Date, Transaction Type, SKU, Quantity, Fee Type, Amount, and Source File. The hard part is matching transactions to sales events. Amazon assigns a case ID to many transactions but not all of them. When you find a case ID, search your transaction export for it and you can usually trace a charge or refund back to a specific order.
I'll give you the specific edge case that made me redesign my whole approach. About eighteen months ago, I had a SKU that showed zero refunds in my accounting software for three consecutive months. The bank deposits looked correct. Everything reconciled. Then I was auditing a shipment reconciliation file and noticed the product had been listed under a superseded ASIN during a listing merge. Amazon refunded customers under the old ASIN ID but credited the payout to the new one. My manual tracking by SKU missed it entirely because the transaction data only showed the current ASIN. The workaround was to export the Inventory Adjustment report alongside the settlement data and cross-reference any suppressed or merged ASINs. That single export caught about $2,400 in uncredited refunds over a 90-day window. I now run that cross-check every month before I close the books. There are a few nuances that nobody puts in guides. Amazon charges a closure fee when you close a case, and they also charge a reinstatement fee if you reopen it. These appear in your settlement as separate line items and people often attribute them to something else. Also, the Refund Administration Fee is not always obvious — it shows up as a percentage of the refund amount, typically 20 percent of the refund, and it appears in the fee breakdown section of the settlement report but gets buried in most exported views. Another counter-intuitive thing: inbound shipment adjustments are where the biggest discrepancies live. Amazon charges you for lost or damaged inventory in transit, but the charge sometimes lands in the month after the shipment arrived, not the month it shipped. If you're doing monthly P&L by cash flow, this creates a timing mismatch that looks like an error. It isn't. It's just how their system posts those reconciliations.
Get the Full Details
The limitation of doing this manually is obvious at scale. Once you hit about 100 active SKUs with consistent monthly volume, the manual matching process becomes a full day of work. The reconciliation gets sloppy under time pressure. At that point, tools like A2X or Redshift do a reasonable job automating the mapping between Amazon settlements and your general ledger. They still miss the weird edge cases, but they handle the volume. The manual process is worth maintaining even after you switch to software, just for the discrepancy files. Those weird lines that the tool flags for review are usually where the real money leaks out. If you're below that scale threshold, here is what matters most. Pull the right three reports every month. The Settlement Report (TSV), the Business Reports units CSV, and the Inventory Adjustments report. Run the ASIN merge cross-check. Separate shipping rebates from product fees. And track your refund rate by SKU against your returnless refund rate. Amazon issued more returnless refunds during the pandemic period and many sellers never noticed the shift in their gross margins because the refund data sits in a different section of the settlement file. That shift alone accounted for a 3.2 percent margin compression on one of my categories over six months. The process takes time. But the alternative is flying blind on your actual per-SKU profitability and hoping the bank deposit is close enough.
