Your Amazon deposit ties but the category totals do not match

This is a different problem from a deposit that will not reconcile, and a more frustrating one. The cash is right. The bank feed matches, the clearing account zeroes out, the payout total agrees with Amazon to the cent. And yet Sales, Shipping, Discounts and the fee accounts in QuickBooks all show different numbers than the same categories in Seller Central.

People lose hours to this, and the reason it resists debugging is structural: a settlement that nets correctly can still be split wrongly. Every misfiled line has an equal and opposite partner somewhere else in the entry, so the total absorbs the error and the bank never complains.

Why tying to the deposit proves less than it looks

A journal entry has to balance. If a line lands in the wrong account, the entry still balances, because the amount is still there, just under a different name. The deposit check only asks one question, whether the parts sum to the whole. It cannot ask whether each part went to the right place.

So the deposit tying is necessary, not sufficient. If your category totals disagree with Amazon while the payout agrees, you now have two numbers and no way to know which one is wrong until you check line types individually.

The same settlement, split two ways

Here is one payout booked two different ways. Both net to exactly 6,400 dollars. Only one matches what Seller Central reports.

Shipping income was folded into Sales. The deposit is identical, the reconciliation passes, and the revenue line is overstated by 600 dollars against Amazon's own figure. Multiply that by twelve months and every revenue-based number you produce, including any tax position that depends on it, is quietly off.

The seven line types that usually cause it

1. Refunds piled into one refunds account

The single most common cause. A reversal belongs in the account it reverses, with its own sign. A refunded item price nets against sales; a refunded referral fee nets against referral fees. Sweep them all into one Refunds bucket and both Sales and every fee account drift away from Amazon's figures at once, while the total stays perfect.

2. Shipping and gift wrap treated as sales

Amazon reports Principal, Shipping and GiftWrap as separate revenue lines. Books that add them together will never agree with a dashboard that keeps them apart.

3. Chargebacks filed as refunds

ShippingChargeback and GiftwrapChargeback are Amazon clawing back shipping and gift wrap revenue on FBA orders. They are contra to those revenue lines, not customer refunds. Filed as refunds, they move money between two accounts that both then disagree.

4. Marketplace facilitator tax booked on one side only

Tax and ShippingTax are collected from the buyer. MarketplaceFacilitatorVAT-Principal and the shipping equivalent are what Amazon withholds and remits itself, and the pair usually nets to roughly zero. Book the collection without the withholding, or the reverse, and a tax-sized hole opens in revenue.

5. Advertising billed to a card instead of the payout

If the payout does not cover the ad spend, some accounts are charged on the card on file for the difference. That spend is real but never appears in the settlement you are reconciling, so the channel looks more profitable than it is and ad totals will not agree. Check how each account is actually billed, because it can change.

6. Reserves treated as income or expense

Current Reserve Amount and Previous Reserve Amount Balance are money Amazon is holding, not revenue and not a cost. They belong on the balance sheet. Let them into profit and loss and monthly figures swing for no real reason.

7. Unrecognized codes absorbed into a catch-all

Amazon renames and adds line types regularly. Any tool or habit that pushes an unknown code into Other, or into the nearest plausible account, produces books that balance and misreport. This is the failure that is hardest to catch precisely because nothing looks broken. Every code and where it belongs is listed in the Amazon settlement fee types glossary.

How to find which one it is: a control total per category

Do not debug the whole month. Take one settlement and test it category by category.

1. Pick a single payout, not a date range. Settlement windows do not align to calendar months, and comparing a month of books against a fortnight of settlement will produce differences that are not errors.
2. Sum the settlement file by line type, straight from the Flat File V2, using the amount-type and amount-description columns rather than your books.
3. Compare category by category, not just the total. The category that differs tells you which line type is misfiled, and the size of the difference usually identifies it outright.
4. Check the partner account. Because the total ties, an overstatement in one category is an understatement in another. Finding the pair confirms the diagnosis instead of leaving you guessing.

Doing this without rebuilding the spreadsheet every settlement

The method above works by hand. It is also exactly what SkuSum automates. It reads the settlement Flat File V2 locally in your browser, with nothing uploaded, no Amazon login and no API access to your books, then outputs a balanced QuickBooks or Xero journal with each line type in its own account, plus per-SKU profit after fees, ads and cost of goods.

The part that matters for this particular problem: anything it cannot classify with certainty is flagged and the export is blocked, rather than being folded into a catch-all that would balance and mislead. The full mapping is documented line by line, and it is validated against 161,344 real settlement lines from US, UK, German and Indian sellers.

Related reading: why the deposit does not equal your sales for the case where the payout itself will not reconcile, and recording Amazon refunds in QuickBooks for the refund side in detail.