Tally Voucher Types for Online Sales: A Field Guide
A marketplace settlement is not one transaction — it is a bundle of sales, returns, fees, tax collected at source and a final payout, and each piece belongs in a different TallyPrime voucher type. Sellers who force everything into a single journal entry per payout lose GST detail, order-level traceability and any hope of a clean audit. This guide maps each marketplace event to the right voucher type and shows how to keep the numbering sane.
The event-to-voucher map
| Marketplace event | Voucher type | Effect |
|---|---|---|
| Customer order shipped | Sales | Debit marketplace party, credit sales and output GST |
| Return or refund | Credit Note | Reverse the sale and its GST |
| Commission, shipping, ad fees | Journal (or Purchase for fee invoices) | Debit expense and input GST, credit party |
| TCS deducted by operator | Journal | Debit TCS Receivable, credit party |
| Payout received in bank | Receipt | Debit bank, credit marketplace party |
The pattern to notice: every event flows through the marketplace party ledger, which is why it reconciles to zero (or to the exact unpaid balance) when your books are right.
Sales vouchers: one per order, or summarised?
TallyPrime handles both. Order-level sales vouchers give you SKU-wise inventory movement and clean B2C detail; daily or settlement-wise summaries keep voucher counts down for high-volume sellers. Two cautions. First, GST reporting needs rate-wise and state-wise breakup, so any summarisation must preserve those splits. Second, if you track inventory in Tally, summaries still need correct stock item quantities. Ask your CA which granularity suits your turnover and filing — then keep it consistent all year.
Credit notes and receipts deserve their own discipline
Returns are heavy in Indian marketplaces, and booking them as negative sales inside a journal destroys the GSTR-1 credit note detail your CA needs. Use proper Credit Note vouchers referencing the original sale — our credit note guide covers courier returns, customer returns and refunds in detail. Payouts belong in Receipt vouchers against the party ledger, never as direct bank-to-sales entries; the settlement receipts guide shows the full flow. Fees and TCS round out the picture through journals.
A note on timing: marketplaces recognise events on their own clocks — order date, shipment date, refund initiation date — and your voucher dates decide which GST period each event lands in. Pick the convention with your CA (shipment date for sales is common), then apply it uniformly across channels; mixed conventions are the classic cause of month-end totals that refuse to tie to any single report.
Custom voucher types and numbering
TallyPrime lets you create custom voucher types under the standard ones, and marketplace sellers should use that: an Amazon Sales type under Sales, a Flipkart Sales type, and so on, each with its own numbering series. The benefits compound:
- Day Book filtering by channel takes seconds.
- Each channel keeps an unbroken, auditable number series.
- Imported vouchers are instantly distinguishable from manual ones.
- Statutory reports can still roll everything up, because the parent type is standard.
One warning for automation: import XML references voucher types by exact name. If your file says Sales but the company only has Amazon Sales, TallyPrime rejects the voucher. Decide the type names first, then configure your import tool to match.
Numbering method matters as much as the names. Automatic numbering keeps series unbroken and is what auditors prefer; manual numbering invites gaps and duplicates once imports run at volume. If you want the marketplace's own identifiers preserved, keep them in the reference and narration fields rather than fighting Tally's numbering — vouchers stay sortable by series while every entry still traces to its order or settlement ID. Separate series also make it trivial to prove to an auditor which entries were imported and which were keyed by hand. And resist retrospective renames of voucher types mid-year: reports filter by type name, and a renamed type quietly splits your history into two series.
Automating the whole map
Applying this mapping by hand to a Meesho payment file with two thousand rows is a weekend gone. TallySutra applies it automatically: it reads Amazon, Flipkart and Meesho reports, classifies each row as sale, return, fee, TCS or payout, and generates the corresponding balanced TallyPrime vouchers — sales, credit notes, journals and receipts — using the voucher type names you configure. Every batch waits for CA approval before it exports as standard Tally XML, and the desktop Gateway posts it to your local Tally instance, checking the open company first. See the full feature list for how classification and approval fit together.
Frequently asked questions
Can I book an entire settlement as one journal voucher?
You can, but you lose GST rate-wise detail, credit note reporting and inventory movement, and reconciliation becomes guesswork. Splitting events into sales, credit notes, journals and receipts keeps both the GST reports and the audit trail intact.
Should imported marketplace vouchers use custom voucher types?
It is good practice. Custom types like Amazon Sales under the standard Sales type give each channel its own numbering series and make imported entries easy to filter, without affecting statutory reports.
What if my import file names a voucher type that does not exist?
TallyPrime rejects the voucher during import — voucher type names must match exactly, like ledger names. Create the custom types first, then configure the import tool to use those exact names.
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