TallySutraHomeFeaturesSolutionsCompareBlogPricingDownloadBook a demo

Amazon to Tally Reconciliation: The Complete Guide

By TallySutra Team · 11 July 2026 · 7 min read

Reconciliation is where Amazon accounting gets real. Importing sales is mechanical; proving that what you invoiced, what Amazon paid, and what reached your bank all agree is the part that protects you in a GST assessment and tells you your true margin. This guide lays out a three-way reconciliation method that works whether you run it in spreadsheets or let software do the matching.

The three-way reconciliation model

Amazon sellers reconcile across three documents, each answering a different question:

DocumentQuestion it answersOrganised by
MTR (Merchant Tax Report)What did I invoice, with what GST?Invoice date
Settlement flat fileWhat did Amazon collect, deduct, and pay?Posted date, settlement-id
Bank statementWhat money actually arrived?Value date

The MTR feeds sales and credit notes into Tally. The settlement file feeds fees, TCS, TDS, and receipts. The bank statement confirms the settlement totals landed. Each pair must tie out: MTR to settlement at order level, settlement to bank at deposit level.

Step 1: Reconcile MTR sales against settlements

Match on Order ID, which appears in both files. For every Shipment row in the MTR there should eventually be ItemPrice rows in some settlement file — not necessarily the same month's, because settlement windows follow posted-date. Work order by order:

  1. Group the MTR by Order ID and total the Invoice Amount.
  2. Group settlement ItemPrice rows (Principal plus buyer-paid components) by order-id.
  3. Match the two lists. Perfect matches clear; the residue is your investigation list.

Typical residue: orders shipped late in the month that settle next cycle, refunds that reversed a sale, and cancelled orders that never settle at all. Nothing here is necessarily an error — but every open item should have a known reason.

Step 2: Reconcile settlements against the bank

This one is blunt: the signed sum of every row in a settlement-id must equal one bank credit. If the bank shows less, look for Amazon lending recoveries or negative opening balances carried into the next cycle. If a settlement never hits the bank, its closing balance was rolled forward — the flat file's header rows make this visible.

Step 3: Explain the sales-to-payout gap

Once matching is done, the month's gap between invoiced sales and received cash should decompose fully into: referral commission and closing fees, shipping chargebacks and other fee lines, refunds, GST TCS at 0.5% under section 52, income-tax TDS at 0.1% under section 194-O, and timing differences carried across the month boundary. If a residual remains after these buckets, something is missing from your books — often fee lines nobody imported. Our deep-dive on why payout amounts don't match lists the usual suspects in detail.

Common mismatch causes and fixes

  • Settlement straddles the month. Reconcile by settlement-id, not by calendar month, and accept a moving cut-off.
  • Refund settled but credit note missing. Import MTR Refund rows as credit notes before reconciling.
  • Duplicate sales vouchers. Re-imported overlapping MTR files inflate the books side. Use duplicate-safe imports.
  • TCS/TDS not booked. The deductions are real money recoverable later; leaving them out both breaks the reconciliation and forfeits visibility of credits.
  • Manual edits inside Tally. A voucher edited after import no longer matches its source row. Keep corrections upstream where possible.

Running this in practice

Done by hand, three-way reconciliation is a day of VLOOKUPs per month, and it degrades exactly when volume grows. TallySutra's Amazon to Tally pipeline was built around this loop: you upload the MTR and settlement files, it creates the vouchers, auto-matches orders across the two reports, and pushes anything unexplained into an exception queue a human — or your CA, via the built-in review step — must clear. The features page shows how exceptions, approvals, and re-imports fit together. Whichever tool you use, the standard to hold yourself to is simple: every rupee of gap between sales and bank has a named reason, every month.

A cadence that keeps reconciliation permanently current

The difference between sellers whose reconciliation is a five-minute habit and those facing a quarter-end archaeology dig is cadence, not skill. A rhythm that works in practice: import sales from the MTR as soon as the monthly file is final; reconcile each settlement within a day or two of its flat file appearing, while the orders are recent enough to remember; and reserve month-end for the three-way tie-out plus a review of the carried in-transit list. Keep two living documents between closes — the in-transit order list, which explains the Amazon ledger balance at any moment, and an exception log recording every anomaly with its resolution. Both documents shrink the next close, because timing items roll forward with names attached instead of being rediscovered. When a new person — an accountant, an article assistant, your CA's junior — takes over the books, these two lists plus the archived source files are the entire handover. That is what reconciliation maturity looks like: not heroic quarterly clean-ups, but a state where no question about the Amazon ledger takes longer than a lookup to answer.

Frequently asked questions

How often should I reconcile Amazon settlements?

Reconcile every settlement cycle rather than once a quarter. Amazon settles frequently, and each settlement file is small enough to clear in minutes when current. Left for months, unmatched orders, rolled-over balances, and revised reports compound into an archaeology project. A practical rhythm: import sales weekly or monthly, reconcile each settlement as its file appears, and do a full three-way tie-out at month end.

My MTR total and settlement total for a month will never be equal — is that a problem?

No, and expecting equality is the classic beginner error. The MTR is organised by invoice date and the settlement file by posted-date, so the same month's totals cover different order populations. Reconcile at order level across whatever settlement files the orders actually landed in, then explain the remaining difference through fees, taxes, refunds, and timing.

Can reconciliation be done inside TallyPrime alone?

Tally can hold the resulting vouchers and ledger-level comparisons, but the order-level matching between MTR rows and settlement rows happens before voucher creation, on the raw files. You need either spreadsheet work or a conversion tool that matches during import. TallySutra performs the match at upload time and only sends balanced, reconciled vouchers into Tally.

Close your marketplace books without the guesswork.

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

Related reading