Reviewing Marketplace Vouchers Before Posting to Tally
Automation moves the risk in marketplace accounting; it does not remove it. When vouchers are generated from Amazon, Flipkart or Meesho report files, the danger is no longer a mistyped amount, it is a systematic issue repeated across a thousand rows: a fee mapped to the wrong ledger, a changed report format, a month imported twice. That is why the review step between generated vouchers and posted books is the control that matters most, and why it deserves a checklist rather than a glance. This article is that checklist, written for the reviewer who has twenty minutes, not two hours.
Review the batch before the vouchers
Individual voucher reading is the least efficient way to catch batch-generation errors. Start at the top:
- Counts: does the number of vouchers correspond to the number of orders and settlements in the source files for the period?
- Period: are all voucher dates inside the expected range, with no strays from a previous month?
- Totals: do batch totals for sales, fees and settlements tie to the report totals?
- Ratios: are fees as a percentage of sales in line with prior months? A jump usually means a mapping change or a marketplace fee revision worth investigating either way.
If the batch-level picture is clean, sampling within the batch is a reasonable next step. If it is not, stop; fix the cause and regenerate rather than editing individual vouchers, since edited generated vouchers break the link between books and source.
What to check on sampled vouchers
| Check | What you are catching |
|---|---|
| Ledger mapping of each fee head | Commission booked as shipping, new fee heads landing in a suspense ledger |
| Tax breakup against the report row | Rate or rounding errors propagated across the batch |
| Debits equal credits, correct receivable ledger | Unbalanced or misdirected entries |
| Round-trip to source | That the voucher traces to a real report row, proving the evidence trail works |
Sample deliberately: a few ordinary orders, the largest values in the batch, at least one return, and any voucher the system flagged. Flagged items are not noise; an exception queue exists precisely so the reviewer's attention lands where the automation was least confident, and clearing it is part of the review, not a separate chore. How those flags arise is covered in our guide to reconciliation exceptions.
Red flags that justify holding the batch
Some findings mean the batch should not post at all until explained: a fee head you do not recognise, settlement totals that differ from banked amounts for the same cycle, duplicate order IDs across this batch and a prior one, or a sudden change in voucher structure mid-month. The last two usually indicate a re-imported file or a marketplace format change. A duplicate-safe pipeline protects you from the re-import case, one of the reasons TallySutra treats duplicate detection as a first-class feature rather than a manual check; see the features page for how re-imports are handled.
Make approval an explicit, recorded act
The difference between a review culture and a review theatre is whether approval is a recorded decision. The reviewer should approve a named batch, on a date, under their own login, and only approved batches should reach TallyPrime. This gives three benefits: juniors can prepare freely knowing nothing posts by accident, the firm gets an internal-control record that stands up in an audit, and disputes about who posted what disappear. TallySutra's CA workspace implements this directly, generated vouchers wait in review, and posting to TallyPrime through the desktop Gateway happens only on approval. The organisational logic behind separating preparer and approver is covered in the maker-checker workflow article.
Keeping review fast enough to actually happen
A review step that takes hours will be skipped under deadline pressure, and a skipped control is worse than none because it creates false assurance. Keep it fast: rely on batch-level checks first, sample rather than read everything, let the exception queue direct attention, and standardise ledger structures across clients so a reviewer's pattern recognition transfers. Reviewers who see the same shape of books for every client can clear a clean batch in minutes and spot an odd one almost immediately. That speed is not corner-cutting; it is what a well-designed control feels like.
Frequently asked questions
Should the reviewer check every generated voucher?
No. Batch-level checks (counts, totals, period, fee ratios) catch systematic errors far more efficiently. Sample individual vouchers deliberately, including large values, returns and anything the system flagged, rather than reading everything.
What should happen when review finds an error in generated vouchers?
Fix the cause, the mapping, the source file or the import, and regenerate the batch. Hand-editing generated vouchers breaks the link between books and source data and hides the systematic issue that caused the error.
Who should approve voucher batches in a small firm?
Someone other than the person who prepared the import, even in a two-person team. The separation is what makes the control real, and a recorded approval creates internal-control evidence for audits.
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