Marketplace Settlement Reconciliation Automation for Indian Sellers

Marketplace settlement reconciliation automation is a rules-based AI worker that takes the settlement report from a seller panel, such as Amazon Seller Central, and recalculates what each order should have paid. It works through commission, shipping, returns, GST TCS under Section 52 of the CGST Act and income tax TDS under Section 194-O. Where the bank credit falls short, or a tax line appears twice, the item is flagged with the rupee gap and a draft claim is prepared. A person reviews and approves the claim. A log records which claims were raised and which were paid, so a reconciler no longer matches each report by hand.
In short
- The worker rebuilds the expected payout for each order and flags shortfalls and double deductions in rupees.
- GST TCS under Section 52 is 0.5 per cent from 10 July 2024, and income tax TDS under Section 194-O is 0.1 per cent from 1 October 2024.
- Every draft claim is approved by a named person, and every outcome is written to a log.
- Automation cannot make a marketplace accept a claim, and disputed or unusual items still need a person.
Most sellers on Indian marketplaces discover a short payment weeks after the money should have arrived. By then the settlement report is one of dozens, the order lines are hard to trace, and the claim window is harder to meet. This page explains what an automated reconciliation worker does, who it suits, what it costs you in attention, and where it will not help.
What the service is
AiStaffo sets up an AI worker that downloads each settlement report from your marketplace seller panel, rebuilds the expected payout order by order, and reports every gap in rupees. The worker drafts the claim, a person approves it, and the outcome is written to a log. The reconciler keeps the judgement calls. The matching, which is the slow part, runs without them.
Who it is for
The service fits businesses that sell through one or more marketplaces, where settlement reports arrive on a regular cycle and someone on the finance or operations team checks them against the bank. That covers a five-person seller working on a single platform and a group with several brands, warehouses and thousands of orders a month. The volume changes the design, not the principle.
It is a weaker fit if you sell on one platform at a few dozen orders a month and the settlement report already ties to the bank within minutes. In that case a simple checklist in Tally or a spreadsheet is cheaper to run and easier to explain to an auditor.
What is included
- A written map of every settlement line type your marketplaces use, including commission, fixed and variable fees, shipping and shipping recovery, returns and refund reversals, reserves, promotions and adjustments.
- An expected-payout model for each order, built from the order value, the fee lines and the GST TCS and income tax TDS lines, with the rule set kept in plain language so your team can read it.
- A check that flags short payments and double deductions, with the rupee gap, the order reference, the settlement period and the line that explains the difference.
- Draft claim emails or portal submissions, prepared for a named person to approve before anything is sent.
- A claims log showing each item raised, the date, the amount claimed, the outcome and the amount actually credited.
- A monthly summary that ties the settlement totals to bank credits and to the TCS and TDS figures your accountant uses for returns.
- A short handover note covering how to add a new marketplace, a new fee type or a new tax rule.
How it runs
- Audit. We review the last three to six settlement cycles, the bank credits that matched them, and every unmatched line. We also check which reports can be downloaded directly and which need to be uploaded by your team.
- Process map. We write down each step a reconciler takes today, mark which steps are matching and which are judgement, and agree the rules for the judgement steps with your finance lead.
- Build. We connect the report source, build the expected-payout model, set the flags and the claim templates, and test the logic against past cycles where the answer is already known.
- Run. The worker runs alongside your existing process for at least one full cycle. Differences between its output and the manual result are reviewed and the rules are corrected before the manual step is retired.
- Support. We watch for report format changes, new fee types and new tax notifications, and update the rules. Your team sees the log and the exceptions queue at all times.
Why the tax lines matter
Two tax lines make a settlement harder to read than its headline payout. The first is GST TCS under Section 52 of the CGST Act. Under CBIC Notification 15/2024, effective from 10 July 2024, the total TCS rate was reduced to 0.5 per cent of the net value of taxable supplies, split equally between CGST and SGST for intra-state sales, or charged as IGST on inter-state sales. The second is income tax TDS under Section 194-O, which applies at 0.1 per cent of the gross sale value from 1 October 2024, with a higher rate where the seller has not furnished a PAN.
The two taxes use different bases. TCS is calculated on net taxable value after returns, while TDS is calculated on gross sales. A reconciler who compares the settlement against a simple sales figure will see gaps that are correct and gaps that are errors, and cannot tell them apart without the rules written out. The worker applies those rules to every order, which is where most of the hand-matching time goes.
Timeline in weeks
These are planning ranges based on the steps above, not guarantees. They assume your settlement reports are accessible and your finance lead can answer rule questions within a few working days.
| Stage | Typical duration (weeks) | What you see at the end |
|---|---|---|
| Audit | 1 to 2 | A list of report sources, fee types and unmatched lines |
| Process map | 1 | Agreed rules for every judgement step |
| Build and test | 3 to 5 | Expected-payout model tested on past cycles |
| Parallel run | 2 to 4 | At least one full settlement cycle checked against the manual result |
| Run and support | Ongoing | Claims log, exception queue and monthly summary |
Marketplaces usually settle on a cycle of about two weeks. Novadata's 2026 guide to Amazon settlement reports describes that cycle, which is why a parallel run of two to four weeks normally covers at least one full settlement.
What you provide
You provide access to each seller panel with a user who can download settlement reports, read-only access to the bank statement or bank feed for the account that receives payouts, and the name of the person who approves claims. You also provide your accountant's view on how TCS and TDS should be recorded, because the worker will follow the treatment you choose and should not invent one. Finally, you give us a few hours with the reconciler, since that person knows the exceptions that never appear in any document.
What it does not cover
Automation does not make a marketplace pay. It finds the shortfall and prepares the claim, but the marketplace decides whether to accept it, and some claims are rejected or take longer than the normal cycle. The worker does not file GSTR-8, your income tax return or any TCS or TDS deposit, and it does not give tax advice. A chartered accountant still signs the numbers.
Some items need a human decision every time. Disputed returns, reserves held against customer complaints, account suspensions and unusual promotions can change the expected payout in ways no fixed rule covers. The worker flags these and stops. It does not guess.
Reports are only as complete as the panel allows. If a marketplace changes its report layout or stops offering a download, the feed has to be fixed before the worker can run again. That is a support task, and until it is done the reconciler is back on manual matching.
Next step
If your team spends days each cycle matching reports to the bank, the first useful step is a short review of your last few settlements to see where the time goes. That review shows whether the work is worth automating and which parts should stay manual.
Sources
- GST TCS Section 52 for E commerce: How to Record and Reconcile in BUSY
- GST TCS under Section 52: E-Commerce Operators Tax Compliance
- Setting up for GST TDS and GST TCS - Business Central
- TCS Under Section 52 of CGST Act: Single Transaction With Multiple e-Commerce Operators
- GST TCS Section 52: E-Commerce Operators And Tax Collection
How AiStaffo would automate this
AiStaffo connects to the settlement report source you already use, or has your team upload the file where the panel does not allow a download. The worker rebuilds the expected payout for every order, using commission, shipping, return, GST TCS and income tax TDS lines, and flags each shortfall or double deduction with its rupee gap. It drafts the claim and records it in a log without sending anything. Your reconciler reviews the exceptions, approves the claims and handles the disputes that need judgement. Book a free automation audit
Questions people ask
Can an AI worker download settlement reports directly from the seller panel?
Which tax lines does the reconciliation check?
How long does it take before the manual process can be switched off?
Will the worker recover every short payment?
Is this worth it for a small seller on one marketplace?
What happens when a settlement line does not match any rule?
Book a free automation audit
Thirty minutes. We look at one process you run every week and tell you exactly what an AI worker would take off your desk, and what it would not.


































