Amazon Sales Returns: Credit Note Entries in Tally
Returns are a fact of marketplace life, and in categories like apparel they are a large fact. Each one has two accounting consequences: a credit note that reverses the sale and its GST, and a settlement impact where Amazon claws back the refunded amount while reversing some fees. Handle both sides and your books stay clean; handle only one and your turnover, tax liability, and Amazon ledger all drift.
Where returns appear in Amazon's reports
In the MTR, a return shows up as a row with Transaction Type = Refund. The row carries the same structure as the original sale — Invoice Number, Order ID, SKU, Quantity, Ship To State, Tax Exclusive Gross, and the IGST/CGST/SGST amounts — with values representing the reversal. In the settlement flat file, the same event appears as Refund transaction-type rows: negative Principal returning the buyer's money, and typically a partial reversal of the referral commission (Amazon's refund policies determine how much of the original fee comes back; the settlement rows are authoritative for what actually happened).
The credit note entry in Tally
Each MTR Refund row (grouped by invoice, like sales) becomes a credit note voucher:
- Debit: sales returns ledger with the taxable value (the row's Tax Exclusive Gross).
- Debit: the same GST duty ledgers as the original sale — IGST for interstate, CGST plus SGST for intrastate — per the tax columns.
- Credit: the Amazon party or marketplace control ledger for the Invoice Amount.
Keep the place of supply and tax split identical to the original invoice; the MTR already provides both, so preserve rather than recompute. Where your Tally configuration supports it, reference the original invoice number in the credit note — GST return disclosures link credit notes to original supplies, and your CA will confirm the exact disclosure treatment applicable to you.
Timing: returns cross month boundaries
A January sale refunded in February produces a February credit note — do not reopen January. This matters for GST (credit notes are reported in the period they are issued, subject to statutory time limits your CA can confirm) and for reconciliation, because the refund's settlement rows will also post in the later period. The practical rule: import each month's MTR completely, Shipment and Refund rows alike, and let the dates fall where Amazon put them.
Reconciling the two sides of a return
| Event | MTR effect | Settlement effect |
|---|---|---|
| Customer refunded | Refund row → credit note | Negative Principal row |
| Commission reversal | — | Positive Commission row (partial or full) |
| TCS adjustment | — | TCS reversal rows in a following cycle |
The check that catches most errors: every Refund order-id in a settlement file should have a matching credit note in Tally, and vice versa within a reasonable window. Orphan refunds usually mean an MTR month was imported before Amazon finalised it — re-download and re-import, which is safe when your import pipeline is duplicate-aware, as described in avoiding duplicate vouchers in Amazon imports.
Special cases worth flagging
- Refund without return (customer keeps the item): financially identical to a normal refund; the credit note still issues because the buyer was repaid.
- Partial refunds: the MTR row reflects the partial value; the credit note follows the row, not the original invoice total.
- Cancellations are a different animal from refunds — Cancel rows have their own treatment, covered in Amazon cancelled orders accounting.
- Damaged FBA returns and reimbursements: Amazon reimbursements arrive as separate settlement lines, booked as other income or recovery, not netted into sales returns. Confirm classification with your CA.
Automating return handling
Returns are where manual imports break down first, because each one touches two reports in two periods. TallySutra's Amazon to Tally pipeline creates credit notes from Refund rows automatically, mirrors the original invoice's tax structure, matches them against refund rows in uploaded settlement files, and holds anything unmatched — an orphan refund, an unexpected fee reversal — in the exception queue for review. The full voucher set exports as standard Tally XML, and the features page shows how exceptions and CA approval slot into the flow.
Monthly returns hygiene in four checks
Returns stay manageable when four checks run every close: every MTR Refund row has produced a credit note; every settlement Refund order-id matches a credit note within a reasonable window, with stragglers on a named timing list; commission reversals landed as credits inside the fee ledgers rather than as stray income; and the month's return rate by value, computed free from the MTR, is charted somewhere a decision-maker actually looks. The last check is the underrated one — accountants often hold the earliest reliable signal that a listing or courier lane has gone bad, weeks before operations notices, and a rising returns line is exactly that signal.
Frequently asked questions
Do I reduce my sales ledger or use a separate sales returns ledger?
Use a separate sales returns ledger grouped so it nets against sales in reporting. Keeping returns visible as their own ledger preserves your return-rate metric, simplifies GST credit-note disclosures, and makes reconciliation against Amazon's refund rows straightforward. Directly reducing the sales ledger hides information and makes audits harder. Your CA can confirm presentation preferences for your entity.
Amazon refunded the buyer but my commission came back only partially — how do I book that?
Book exactly what the settlement rows show: the negative Principal clears against the credit note, and the positive Commission row posts as a credit to your referral fee ledger for whatever amount Amazon actually reversed. The unreversed portion simply remains your cost. Do not assume full reversal — the flat file, not the fee schedule, is the record of what happened.
What if a refund appears in the settlement file but there is no Refund row in my MTR yet?
This is normally timing: the refund posted near a month boundary and will appear in the next MTR. Hold the settlement row as unmatched, then re-download the relevant MTR and re-import once Amazon includes it. A duplicate-safe importer makes the re-import harmless. If the gap persists beyond a cycle, investigate the specific order in Seller Central.
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