Credit Notes in Tally for Marketplace Returns
Returns are the tax on selling online in India — apparel and footwear sellers routinely see a meaningful slice of shipped orders come back. Every one of those returns must reverse revenue and GST in your books, and the correct instrument in TallyPrime is the Credit Note voucher. Booking returns as ad-hoc journals or netting them silently against sales corrupts both your GSTR-1 and your margin reporting. Here is how to do it properly, at marketplace volume.
Why a credit note and not a journal
A Credit Note voucher in TallyPrime does three things a plain journal does not do cleanly: it reverses output GST in the tax ledgers so GST reports stay correct; it carries the reference to the original sale, which return-related GST reporting expects; and it restores inventory if you track stock. The accounting effect is the mirror of the sale — credit the marketplace party ledger, debit sales returns (or sales) and debit the output GST ledgers. Whether you post returns to a separate Sales Returns ledger or against the original sales ledger is a presentation choice your CA should confirm.
What the marketplace reports actually give you
Each platform reports returns differently, and your process has to read them all:
- Amazon — refund rows appear in settlement and MTR data with references to the original order; customer returns and refunds are distinct events from reimbursements.
- Flipkart — settlement data carries return and refund adjustments against the original order ID, including courier returns that never reached the buyer.
- Meesho — heavy RTO (return to origin) volumes show up as adjustments in payment files.
A courier return (RTO) and a customer return can carry different fee reversals, and refunds may span settlement periods — a January sale refunding in February must still find its original invoice reference.
Fee reversals ride along with returns and deserve separate lines. When an order comes back, platforms typically reverse some charges (referral fee, sometimes shipping) and levy others (return processing). Fold those into the return's accounting as their own fee entries rather than burying them in the credit note amount — the credit note should reverse the sale as invoiced, while fee adjustments flow through the fee ledgers, or the party ledger stops tying to the settlement. A CA should confirm how reversed and levied fees interact with any input credit already claimed.
The fields that make a credit note audit-proof
| Field | Why it matters |
|---|---|
| Date | Drives which GST period the reversal lands in |
| Reference to original invoice | Links the reversal to the sale for GST and audit |
| Party ledger (marketplace) | Keeps the settlement trail through one ledger |
| GST ledgers by rate | Reverses the exact tax charged on the original sale |
| Stock item and quantity | Brings sellable returns back into inventory |
| Narration with order ID | Makes month-end investigation possible |
Volume is the real problem — automate the matching
The accounting is not hard; doing it eight hundred times a month is. Each return row must be matched to its original order, classified (customer return, RTO, refund without return), and turned into a balanced credit note with the right GST split. This is precisely the tedium TallySutra removes: it reads the marketplace reports, pairs return rows with their original sales, generates Credit Note vouchers with correct references and tax reversal, and reconciles the net effect against the settlement amount. Nothing posts until your CA approves the batch, and re-imports are duplicate-safe, so a refund appearing again in next month's file does not become a second credit note. The output is standard TallyPrime import XML — posted via the Gateway or imported manually. See how returns fit the broader flow in the voucher types guide and on the solutions page.
Month-end checks for returns
- Count of credit notes vs count of return rows in the marketplace reports.
- Credit note total vs refund total in settlement data.
- GST reversal by rate vs the original sales mix — a mismatch means wrong rate mapping.
- Spot-check five RTOs: inventory restored, fees treated per policy.
Keep an eye on partial returns as well — one unit returned out of a three-unit order line must reverse exactly one unit's value and tax, and it is the case hand-built credit notes get wrong most often. Where quantity maths and rate splits interact, generated vouchers earn their keep.
Ten minutes of checks after import beats a filing-week surprise. For the full post-import routine, see verifying GST reports after import.
Frequently asked questions
Do marketplace returns need a credit note even if the refund happened on the platform?
Yes. The marketplace refunds the buyer, but your books recorded the sale, so you must reverse revenue and output GST with a credit note. The refund then flows through the marketplace party ledger like any settlement adjustment.
How are RTO (courier return) and customer return different in accounting?
Both reverse the sale, but fee treatment differs — platforms reverse or retain different charges for each, and RTO stock usually returns sellable. Classify them separately and have your CA confirm the fee treatment.
What if a return arrives in a later month than the sale?
Book the credit note in the period the return or refund occurred, referencing the original invoice. Cross-period returns are normal; what matters is the reference linking the reversal to the original sale.
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