A Month-End Close Process for E-commerce Clients
Month-end for a marketplace seller client fails for predictable reasons: a missing settlement report, a pile of unmatched orders discovered on the last day, returns from two months ago still hanging, and no one certain whether the sales figure includes cancelled orders. A written close process fixes most of this, because the problems are sequencing problems. This article lays out a close calendar you can apply to every Amazon, Flipkart or Meesho client, whether you run it manually or through an automation layer.
The close is a pipeline, not a day
Treat the close as five stages that must happen in order. Each stage has an exit condition; you do not move on until it is met.
| Stage | Work | Exit condition |
|---|---|---|
| 1. Collect | Download order, settlement and returns reports for the full month from every marketplace | All expected files present, dated, and stored |
| 2. Import | Load reports and generate draft vouchers | Row counts in system match row counts in files |
| 3. Reconcile | Match settlements to orders at order level | Every order is matched, pending, or flagged |
| 4. Resolve | Clear flagged exceptions or document why they remain open | Exception queue reviewed; open items have owners |
| 5. Review and post | Senior reviews draft vouchers and approves posting to TallyPrime | Approved vouchers posted; sign-off recorded |
Stage details that trip people up
Collection is where closes silently die. Settlement reports often lag the month by days, and a settlement cycle can straddle the month boundary, so define upfront which settlements belong to which month and apply the rule consistently. Keep a per-client checklist of expected files; a missing Meesho payment file discovered in week three costs far more than the two minutes it takes to notice it in week one.
Import should be boring. If your import step involves manual copy-paste between sheets, every close inherits the risk of a sort gone wrong or a dragged formula. Whatever tool you use, verify counts: orders in the file versus orders imported. TallySutra makes this stage duplicate-safe, so re-importing a corrected file mid-close does not double-post anything, and the draft vouchers arrive balanced with fee heads separated; see the features overview for what the drafts contain.
Reconciliation at order level is the heart of the close. Summary-level ties (total settled versus total banked) catch big breaks but hide offsetting errors. Order-level matching surfaces the short payments and stray fees that summaries absorb; the trade-offs are covered in order-level versus summary reconciliation.
Handling the items that will not close
Every month leaves a tail: orders settled but not yet in a report, returns awaiting refund, disputed fees. The mistake is letting these live in someone's memory. The close should end with an explicit open-items list, each with a description, the month it originated, the evidence attached, and a named owner. Next month's close begins by re-checking this list. Items that persist for more than two cycles deserve escalation, either to the marketplace via a claim or to the client for a write-off decision, and any tax treatment of write-offs should be confirmed against current rules.
Sign-off: what the reviewer actually checks
The final review is not a re-performance of the work. A practical reviewer checklist:
- Sales per books versus sales per marketplace reports, with differences explained by cancellations and returns
- Settlement match rate for the month and the size of the unmatched tail
- Fee ledgers as a percentage of sales, compared to prior months for drift
- Exception queue empty or every open item owned and dated
- Voucher batches approved by someone other than the preparer
That last point is a control, not a formality; the case for separating preparation from approval is made in our maker-checker article. When the reviewer approves, posting to TallyPrime should be a single controlled action, and the sign-off should be recorded with a date and name. A close that ends with posted vouchers, a clean or owned exception list, and a recorded approval is a close an auditor can rely on months later. Firms running this loop on TallySutra do the review inside the CA workspace, where approval and posting are the same recorded step. Two further habits harden the process over time: keep a one-page close log per client noting what went wrong each month and the fix applied, and revisit the close calendar quarterly, because marketplace report timings shift, and a calendar nobody updates quietly stops matching reality. The close log in particular compounds: after three months it becomes the training document for whoever runs the close next.
Frequently asked questions
Which month does a settlement that spans two months belong to?
Pick a consistent rule, for example, settlements are recognised in the month the marketplace dates them, and apply it to every client every month. Consistency matters more than the specific choice, and it should be documented in the close process.
How long should a month-end close take for a marketplace client?
With reports collected on time and imports automated, the constraint becomes exception resolution and review. The close calendar approach spreads work across the month so the final days involve sign-off, not data entry.
What if the marketplace has not released the last settlement report?
Close the month with those orders explicitly marked as pending settlement rather than forcing a match. They carry forward to the open-items list and are matched when the report arrives, keeping the books honest about what is actually known.
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