The Multichannel Seller's Accounting Guide
Adding a second marketplace roughly doubles your accounting surface, and a third does it again: each of Amazon, Flipkart and Meesho has its own report formats, fee structures, settlement cycles and returns behaviour. Sellers who treat all of this as one blended stream end up with books that can say what the business earned but not where, and where is the question that decides advertising budgets, inventory allocation and which channel deserves to grow. This guide covers how to structure multichannel books so each channel stands on its own.
The core principle: channel separation in the ledgers
Everything else in this guide follows from one structural decision: per-channel ledgers. At minimum, that means for each marketplace a separate receivable ledger (what the channel owes you), sales ledger, fee ledgers for the major deduction heads, and returns ledger. With that in place, channel-wise revenue, fee load and net realisation drop out of TallyPrime reports directly; without it, channel analysis becomes a recurring spreadsheet project that gets skipped in busy months. Whether to go further, cost centres per channel, channel-wise stock, depends on your inventory model, but ledger separation is the non-negotiable floor.
What differs per channel, and why it matters
| Dimension | Accounting consequence |
|---|---|
| Report formats and field names | Each channel needs its own import mapping; a change in one must not break the others |
| Fee structures | Fee heads differ by name and basis, so one-size ledger mapping mislabels costs |
| Settlement cycles | Pending-settlement receivables age differently per channel; one ageing rule misleads |
| Returns behaviour | Return rates and fee-reversal policies differ, so net realisation must be computed per channel |
The practical implication: reconciliation has to run per channel, not on a blended pool. An overall match rate of 95 percent can conceal one channel at 99 and another at 85, and the 85 is where your attention belongs. The mechanics of order-level matching are covered in our reconciliation explainer.
The numbers multichannel sellers should watch monthly
- Net realisation per channel: settled amount as a share of gross sales, after fees and returns. This is the honest comparison between channels, and it routinely reorders them versus gross revenue.
- Fee percentage by head, per channel: drift in any line signals a rate change or misclassification worth investigating, per the fee audit method.
- Return rate per channel: both a margin driver and an operations signal.
- Pending settlements ageing, per channel: money delivered but unpaid, aged against each channel's normal cycle.
None of these require analysis projects if the ledger structure is right; they are readings, not investigations.
Operational realities at three channels
Multichannel accounting fails operationally before it fails technically. Three habits keep it standing. First, a unified collection schedule: all reports for all channels downloaded on the same days, tracked on a checklist, because a missing Meesho settlement file discovered at month-end stalls the whole close. Second, uniform processing: the same pipeline and standards per channel, so adding a channel is configuration, not invention. Third, duplicate safety: with three channels' files flowing weekly, someone will eventually re-upload one, and the pipeline must recognise already-processed rows rather than double-post them. This is the workflow TallySutra packages: upload each channel's files, get order-level reconciliation and balanced TallyPrime vouchers with per-channel ledger separation built in, exceptions queued per channel, and re-imports handled safely, the features page covers the pipeline. Books stay unified in one TallyPrime company; the channels stay distinguishable inside it.
When a channel deserves to be questioned
The payoff of channel-wise books is that hard questions become answerable. If one channel's net realisation trails the others persistently after fee audits and returns work, you can model the business without it, or with it repriced, using real numbers rather than impressions. Sellers make these calls annually whether or not their books support them; the ones with channel-separated, reconciled books make them with evidence. If a CA runs your books, the multi-client workspace shows how firms manage exactly this structure across many sellers, and the same discipline scales down to one seller managing three channels with clarity. If you are earlier in the journey, the sequence matters less than the start: separate the ledgers first, since every later improvement builds on that structure, then add per-channel reconciliation one marketplace at a time, beginning with whichever channel's payouts you currently understand least.
Frequently asked questions
Should each marketplace be a separate company in TallyPrime?
Usually not; one company with per-channel ledgers (receivables, sales, fees, returns) keeps the entity's books unified while making channel-wise analysis a report rather than a project. Separate companies complicate consolidation without adding insight.
Which channel metric best compares Amazon, Flipkart and Meesho?
Net realisation: what actually settled as a share of gross sales, after fees and returns, computed per channel. Gross revenue rankings frequently reverse once fee loads and return rates are applied.
Does adding a third marketplace triple the accounting work?
Only if each channel is handled bespoke. With a uniform pipeline, standard ledger patterns and per-channel reconciliation running through the same process, an added channel is incremental configuration plus its share of exceptions, not a new system.
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