What Amazon reconciliation actually means

The distinction that matters

Bookkeeping is a record of what happened. Money arrived, it is attributed to a period, it appears in a profit and loss. The test of a good set of books is internal consistency: does everything add up and is everything accounted for.

Reconciliation is an audit of someone else's arithmetic. It takes what you believe you earned, takes what Amazon says you earned, takes what your bank says you received, and insists that all three agree. The test is not internal consistency but external agreement, and a disagreement is the output you are looking for rather than an error in your process.

This is why a business can have immaculate accounts and a recurring leak. Nothing in a correctly kept ledger notices that a fee was charged at the wrong rate. The ledger faithfully records the wrong number.

The unit is the fee line, not the payout

The instinct is to check the big number. The deposit was about what you expected for a month like that, so it is probably fine. This is the single most expensive habit in marketplace accounting, because the errors worth finding are small per order and persistent across thousands of them.

A referral fee charged against the wrong category might cost a few rupees on each order. Nobody notices it in a monthly total. Across a year and a reasonable order volume it is a serious number, and because it is systematic rather than random it never averages out.

So reconciliation works at the level of the individual fee line. For each line, which order caused it, what should it have been, and what was it. On Amazon this is harder than it sounds, because fee invoices do not carry an order identifier, which is a known gap and the reason the matching step is the part worth mechanising.

Three documents, and why two is not enough

You need your own record of orders, Amazon's settlement report, and your bank statement. Each pair of these can agree while the third disagrees, and each of those cases means something different.

Orders and settlement agree, bank disagrees. The money Amazon calculated is right and the transfer did not fully arrive, which points at a failed disbursement, a reserve, or a payout that split across periods.

Settlement and bank agree, orders disagree. Amazon paid exactly what it said it would, and what it said it would is not what you think you sold. This is the case that finds missing orders, wrongly cancelled orders, and refunds you were not expecting.

Orders and bank roughly agree, settlement disagrees in its detail. This is the fee-level case, and it is the one that recovers money. The total came out close enough that nobody looked, and inside it a fee line is wrong.

Timing is not loss, and confusing them wastes your week

Before you dispute anything, rule out timing. A large share of apparent gaps are money that exists and has not arrived yet, and chasing those teaches you to distrust a report that was correct.

The usual causes are a settlement period boundary, where an order placed near the end of a period settles in the next one; a return processed after the period closed, so the sale and its reversal sit in different reports; and a reserve, where Amazon is holding funds against expected returns and releasing them on its own schedule.

The discipline is to reconcile a period only once its neighbours are available, and to carry a deliberate list of items you expect to appear later rather than writing them off. A gap you have named and dated is not a problem. A gap you have forgotten is.

The eight places money actually goes

In practice the differences cluster. Fees charged at the wrong category rate. Weight handling charged on a measured weight heavier than what you sent. Returns refunded to the buyer where the item never came back to you. Inventory lost or damaged inside a fulfilment centre. Cancellation fees for cancellations that were not your fault. Orders missing from a settlement report entirely. Reserves that grew without explanation and did not release. And overcharges that ran quietly for long enough that the window to claim them is the binding constraint rather than the evidence.

Each of those has its own route to recovery and its own deadline, and the deadlines are the reason reconciliation is a monthly rhythm rather than an annual exercise. Evidence that would have won a case easily in week two is often unavailable in month six.

Notice also that most of the eight are not arithmetic errors at all. They are operational events that happen to cost money, which is why reconciliation sits closer to operations than to accounting and why it benefits from the same data your order processing already touches.

What to automate, and what not to

Automate matching. Pairing fee lines to orders, settlements to bank credits, and returns to their original sales is mechanical, high volume and exactly what software is for. Doing it by hand is where reconciliation dies, because the effort scales with your success and the first busy month ends the habit.

Automate the expectations too. If you know what a fee should be for a category and a weight band, a machine can compute the expected charge for every order and show you only the lines that disagree. That turns a full audit into a short exceptions list.

Do not automate the judgement. Whether a two rupee difference across four hundred orders is worth a dispute, which cases to file first when the evidence is thin, and when to accept a loss and change the operation instead are decisions with your business context in them.

Robnu is built for the first two. It reads Amazon settlements alongside Meesho, AJIO, Flipkart and Myntra, matches each fee line back to the order that caused it, and surfaces the exceptions rather than the ledger. You keep the judgement, and stop doing the matching.

Where this sits in the rest of your Amazon operation

On Amazon, Robnu syncs your orders, returns, payouts and inventory, reconciles every settlement line back to the order that caused it, lists the FBA units Amazon's own ledger has not made good, flags a return that never came back before the SAFE-T window closes, and scans returns in at your dock. It reads your Amazon account rather than writing to it, so accepting orders and making labels run on AJIO and Meesho today. Related reading:

• Reconciling Amazon India payments, step by step
• All 24 fields of the V2 settlement report, defined
• The settlement report removal on 11 November 2026
• How Amazon India settlements work
• When Amazon India actually pays you
• Payment reconciliation across marketplaces
• Reconciliation software for Indian sellers
• What Robnu does on Amazon

Sources & further reading

• Amazon SP-API settlement report type values the reference page for all three settlement reports. It states the role each one needs, that settlement reports cannot be requested or scheduled, and the three-column condensation. Read 2 November 2026.
• Amazon India Seller University the public training hub. It serves, and it does not publish the account-health thresholds. Read 2 November 2026.

Not legal or tax advice. Amazon changes fees, windows and policies without notice, and the detailed style guides and account-health thresholds sit behind a Seller Central login, so any figure quoted here as convention is not Amazon-published. Check anything you plan to act on against your own Seller Central account first.