Reconciliation Exceptions: How to Resolve Them
Run settlement reconciliation on any real month of marketplace data and most orders will match cleanly. The value of the exercise is the remainder: the exceptions, orders and settlement lines that do not tie out. Exceptions are not failures of the reconciliation; they are its product. Each one is either an explanation waiting to be recorded or money waiting to be recovered, and the difference between sellers who benefit from reconciliation and those who merely perform it is what happens to this list. This is a field guide to the common exception types and a workflow for clearing them.
The exception taxonomy
| Exception | What it usually means | First move |
|---|---|---|
| Order with no settlement | Timing, if recent; a problem, if aged past the payout cycle | Age it; chase with the marketplace once overdue |
| Settlement with no matching order | Order missing from your sales report, or a cross-period settlement | Search adjacent periods' reports before assuming error |
| Short payment | Fees above expected, or an unexplained adjustment | Compare deductions to the rate card, line by line |
| Refund without fee reversal | Return processed, reversible fees not credited | Check the reversal policy; claim if due |
| Unknown fee line | New fee head, or a charge outside the rate card | Identify against marketplace documentation; dispute if unmatched |
| Apparent duplicate | Same order or fee appearing twice | Confirm whether it is a re-imported file or a genuine double charge |
The apparent-duplicate row deserves a note: distinguish data duplicates (the same report processed twice, a self-inflicted problem that duplicate-safe importing prevents) from genuine double charges by the marketplace, which are claimable. The two look identical in totals and completely different in evidence.
The resolution workflow
Exceptions should live in a queue, not an inbox, one list per client or channel, where every item carries its source rows and stays visible until resolved. The workflow per item has four steps:
- Classify: assign one of the types above. Classification alone resolves many items, since timing cases simply need an age check and a wait.
- Investigate: pull the linked order and settlement lines and establish the expected figure. This is where an evidence trail pays off, if vouchers link to source rows, investigation is retrieval, not archaeology.
- Act: record the explanation, raise a marketplace claim with order IDs attached, or correct your own data, whichever the finding dictates.
- Close with a note: who resolved it, how, and on what basis. Closed-without-note is how the same mystery gets re-investigated next quarter.
Ageing and escalation discipline
An exception queue without ageing becomes a graveyard. Set explicit thresholds: items unresolved past one settlement cycle get investigated, items past two get escalated, to a marketplace claim, or internally to a write-off decision made deliberately by someone with authority, never by silent abandonment. Write-offs should be recorded as such, with tax treatment confirmed with your CA. The queue's health metrics, count, average age, oldest item, are also the fastest read on whether your reconciliation process is actually working; a growing queue means the intake side is generating more mysteries than the resolution side clears, which is a staffing or a data-quality signal, as covered in our multi-client workflow article.
Reducing exceptions at the source
Mature reconciliation operations resolve fewer exceptions each month, not because they look less carefully but because they fix generators: collecting all report files on schedule (missing returns reports manufacture false mismatches), keeping expected-fee logic current with rate cards, importing through a duplicate-safe pipeline, and matching at order level so offsetting errors cannot hide, the case made in order-level versus summary reconciliation. This is the shape TallySutra gives the whole loop: uploaded Amazon, Flipkart and Meesho files are matched at order level, everything that ties out becomes balanced TallyPrime vouchers awaiting review, and everything that does not lands in the exception queue with its source rows attached, classified and aged, see the features page for how the queue works. However you implement it, the principle stands: a reconciliation is only as good as the fate of its exceptions. A final habit worth stealing from audit practice: once a quarter, review a sample of closed exceptions rather than open ones. Closures with thin notes, or the same explanation recurring across many items, point to a resolution shortcut that has become policy without anyone deciding it, and catching that early is far cheaper than re-opening a year of comfortable closures.
Frequently asked questions
How many exceptions are normal for a month of marketplace data?
It varies with volume, return rates and report completeness, so track your own trend rather than an external benchmark. A rising exception rate at stable volume is the meaningful signal, usually a format change, a missing report type, or fee drift.
When should an unresolved exception become a write-off?
After defined ageing thresholds and a failed escalation, by an explicit decision from someone with authority, recorded with a note. Silent abandonment is the failure mode; deliberate write-off with tax treatment confirmed by your CA is legitimate closure.
Can exceptions be resolved automatically?
Some classifications can, timing cases that clear when the next settlement file arrives, for instance. Judgement calls like disputes and write-offs should stay human, which is why a good tool queues them with evidence attached rather than deciding for you.
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