Amazon Payout Reconciliation: Why Amounts Don't Match
You sold four lakh worth of goods last month and Amazon deposited a good deal less — and no single number on any screen explains the difference. This is the most common question sellers bring to their accountants, and the answer is always the same: the gap decomposes into a known list of deductions and timing effects, every one of them visible in the settlement flat file. Here is the list, and the method for proving your particular gap is fully explained.
The seven reasons your payout is smaller than your sales
| Cause | Where you see it | Nature |
|---|---|---|
| Referral commission and closing fees | ItemFees rows (Commission, FixedClosingFee) | Real cost |
| Shipping chargebacks and fulfilment fees | ItemFees and charge rows | Real cost |
| Refunds processed in the window | Refund transaction-type rows | Sale reversal |
| GST TCS at 0.5% (s.52) | TCS-IGST/CGST/SGST rows | Recoverable |
| Income-tax TDS at 0.1% (s.194-O) | TDS rows | Recoverable |
| Settlement timing | posted-date vs invoice date | Timing only |
| Carried balances and recoveries | Settlement opening balance, lending or adjustment rows | Case-specific |
Note the nature column: fees are genuine costs, TCS and TDS are your own money routed through tax accounts (see TCS and TDS accounting in Tally), and timing differences are not losses at all. Lumping all seven into one mental bucket called deductions is why the gap feels mysterious.
Timing: the piece that fools everyone
Settlement files are organised by posted-date within a settlement-id, while your sales are booked by invoice date from the MTR. A month's final week of orders typically settles in the following cycle, so comparing calendar-month sales to calendar-month deposits guarantees a mismatch even for a fee-free, refund-free seller. Reconcile by settlement-id, matching orders across whichever files they actually appear in, and hold a rolling list of in-transit orders at each month end. That rolling list is an asset — it is money on its way to you.
A worked method for explaining the gap
- Pick a completed settlement-id and confirm its signed row total equals the bank deposit exactly. If not, look for lending recoveries or a carried balance before anything else.
- Within the settlement, subtotal by amount-type and amount-description: Principal, Commission, FixedClosingFee, shipping lines, refunds, TCS, TDS.
- Match the settlement's order-ids against sales already imported from the MTR. Unmatched settlement orders mean sales missing from your books; unmatched book sales mean orders not yet settled.
- Post the settlement's components to their ledgers — fees to expenses, TCS and TDS to receivables, net to bank — and the reconciliation closes arithmetically.
Run this for every settlement and the month-end question changes from why is money missing to a clean statement: this much in fees, this much recoverable tax, this much in transit.
Red flags that are not routine
- A settlement whose rows do not sum to the deposit even after checking carried balances.
- Orders appearing in settlements that never appear in any MTR — investigate in Seller Central.
- Fee percentages drifting well outside your category's norm, which can indicate misclassified listings.
- Refund rows with no eventual credit note, covered in Amazon returns and credit notes.
Making this a five-minute job
All of the above is deterministic file processing, which is why it automates cleanly. TallySutra ingests your uploaded MTR and settlement files, classifies every settlement row, matches orders across the two reports, books the balanced vouchers, and surfaces only the genuine anomalies in its exception queue — the full loop is described in the complete reconciliation guide and on the features page. The goal state is simple: every settlement reconciled to the paise within a day of its file appearing, and a month-end where the sales-to-bank gap is a report, not a mystery.
The payout bridge: a one-page statement worth adopting
Sophisticated sellers formalise all of the above into a monthly payout bridge — a one-page statement that starts at invoiced sales per the MTR and walks, line by line, to cash received per the bank: less commission and closing fees, less fulfilment and shipping lines, less refunds, less TCS booked to receivable, less TDS booked to receivable, plus or minus the change in the in-transit balance, equals bank deposits for the month. Built from correctly classified vouchers, the bridge assembles itself from ledger movements, and it answers in one glance the question every proprietor asks and every investor eventually will: where did the money go between the sales report and the bank statement? It also makes anomalies impossible to hide — a bridge that needs a balancing plug figure is telling you a settlement file was missed or a classification is wrong. Make the plug line zero every month and your Amazon books are, by construction, fully reconciled.
Frequently asked questions
Roughly how much of the gap is recoverable rather than a real cost?
The GST TCS (0.5% under section 52) and income-tax TDS (0.1% under section 194-O) components are fully recoverable against your tax liabilities, so they are cash-flow timing, not cost. Fees, by contrast, are permanent costs, and refunds are reversed revenue. The exact split varies by month and category — your settlement files, correctly classified, give you the precise number rather than an estimate.
Amazon's deposit doesn't match even the settlement report total. What now?
First re-sum every signed row in the settlement-id, including header balance rows — a carried-forward negative balance from the prior cycle is the usual culprit. Next, check for loan or advance recoveries deducted from disbursement. If a genuine discrepancy remains between the file and the bank credit, raise it with Seller Support with the settlement-id, and book nothing until resolved.
Should I book sales at net payout value to avoid all this?
No. Your statutory sales are what you invoiced customers, with GST, per the MTR — booking net-of-fees turnover understates revenue and breaks GSTR-1. The correct model is gross sales plus separately booked fees, taxes, and refunds, which is exactly what the settlement file itemises. It is slightly more work and entirely automatable, and it is the version an assessment will expect.
TallySutra turns Amazon, Flipkart and Meesho reports into reconciled, reviewed TallyPrime vouchers — duplicate-safe, with every rupee traceable to its source row.
Book a 30-minute demo