Receipt Vouchers in Tally for Marketplace Settlements
The payout hits your bank: some odd figure like 4,83,217.42 from Amazon. That number is not revenue — it is what is left of your sales after commissions, shipping fees, advertising, refunds and tax collected at source. The Receipt voucher that books it is simple; making it meaningful is the hard part, because it only reconciles if everything upstream was booked first. This guide covers the entry, the sequence, and the traps.
Anatomy of a settlement
Every marketplace payout is the tail end of the same equation:
- Gross sales for the settlement window
- minus returns and refunds
- minus commission, shipping, fulfilment and advertising fees
- minus TCS collected under GST (and, where applicable, TDS)
- equals the amount deposited to your bank
In a well-kept TallyPrime company, each of those pieces is already in the marketplace party ledger before the payout arrives: sales vouchers debited it, credit notes and fee journals credited it. The Receipt voucher then simply clears it — debit bank, credit the marketplace party ledger for the payout amount.
The entry, and what it should not be
| Approach | Entry | Verdict |
|---|---|---|
| Correct | Receipt: debit Bank, credit Amazon (party ledger) | Settlement trail preserved; party ledger tends to zero |
| Common shortcut | Receipt: debit Bank, credit Sales | Wrong — invents revenue equal to net payout, loses fees and GST entirely |
| Lazy variant | Journal lumping payout, fees and sales in one entry | Loses order traceability and rate-wise GST detail |
If you take one thing from this article: payouts always credit the party ledger, never a sales ledger. Revenue was recognised when the orders were booked; the payout is only the cash catching up.
Sequencing: fees and returns before receipts
Book the settlement's sales, credit notes, fee journals and TCS entries first, then the receipt. Done in that order, the party ledger balance after the receipt equals exactly the unsettled remainder — current orders not yet paid out, plus any reserve the marketplace is holding. If the residual is some inexplicable figure, something upstream is missing or duplicated, and the ledger is telling you before your CA or an auditor does. Our guides on fee journals and credit notes for returns cover the upstream pieces.
The order matters for review too. A CA approving a settlement batch wants to see the whole story at once — sales, reversals, deductions, receipt — and confirm the arithmetic closes before anything posts. Batches assembled event-complete like this are also what make duplicate detection tractable: if the same settlement ID ever shows up twice, every piece of it is identifiable and removable as a unit rather than as scattered entries. It is also the layout that makes month-end audits fast, because each batch reads as one self-contained settlement.
Multiple payouts, holds and reserves
Real settlement behaviour is messier than one payout per month: Amazon typically settles on a rolling cycle, Flipkart pays on order-age slabs, Meesho on its own cadence, and platforms sometimes hold amounts in reserve. Practical rules: book one Receipt voucher per actual bank credit (never merge them — bank reconciliation depends on matching individual credits); put the settlement ID in the narration; and treat reserves as what they are — balance simply remaining in the party ledger until released. When a payout covers two months' orders, the receipt date is the bank credit date; the party ledger absorbs the timing difference naturally.
Foreign marketplaces and export orders add complications — currency conversion, remittance charges deducted by banks, and timing spreads — that deserve their own treatment and a CA's eye; the domestic pattern here assumes rupee settlements landing in a rupee account. Even domestically, watch for the occasional negative payout: a period where refunds and fees exceed sales produces a demand rather than a deposit, which books as the mirror entry when you actually pay it.
Where automation earns its keep
The receipt itself takes thirty seconds; proving the payout equals sales minus fees minus TCS for three thousand order rows is the real work. TallySutra does that arithmetic for you: it ingests the settlement reports, builds the full voucher set — sales, credit notes, fee journals, TCS entries and the receipt — as one balanced, reconciled batch, and shows you the tie-out before anything is posted. Your CA approves the batch, then it exports as standard TallyPrime XML or posts through the Gateway to your local Tally. Re-imports are duplicate-safe, so overlapping report downloads cannot double-book a payout. See the reconciliation features, and pair this with the bank reconciliation guide for the bank-side view.
Frequently asked questions
Should a marketplace payout be booked as sales income?
No. Sales were already recognised when orders were booked. The payout is a Receipt voucher debiting bank and crediting the marketplace party ledger — it is collection of a receivable, not revenue.
What does a leftover balance in the marketplace party ledger mean?
It should equal unsettled orders plus any reserve the platform is holding. If the figure does not match the marketplace's own unsettled balance report, some sale, fee, return or TCS entry is missing or duplicated.
Can I combine several bank credits into one receipt voucher?
Avoid it. One receipt per bank credit keeps bank reconciliation one-to-one and lets each settlement ID trace to its own entry. Merged receipts turn every BRS difference into an investigation.
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