9 Common Reconciliation Errors on Amazon, Flipkart, and Meesho

Errors that show up across all marketplaces

Some reconciliation issues aren't specific to one platform — they show up in some form across Amazon, Flipkart, and Meesho alike, just labelled differently in each settlement report.

• Short settlements — the payout for a delivered order is lower than the expected sale price minus the standard commission and fees.
• Incorrect commission slabs — a product is charged the commission rate for the wrong sub-category, usually a higher one.
• Duplicate or double-charged fees — shipping, RTO, or packaging fees applied more than once to the same order.
• Unreimbursed customer returns — a return is processed and the customer is refunded, but the seller is never credited the compensation they're owed under the marketplace's return policy.
• TDS/TCS mismatches — the tax deducted doesn't match the rate that should apply to the transaction.

Amazon-specific errors

Amazon's FBA and Easy Ship programs introduce their own fee structures, and a few issues are particularly common for sellers:

• Long-term storage fees on FBA inventory that has been sitting for months without a clear alert.
• Lost or damaged warehouse inventory that was never reimbursed under Amazon's FBA reimbursement policy — Amazon has moved toward automatic reimbursements for inventory lost inside a fulfilment centre, but shipment-to-Amazon shortages, removal-order losses, and misclassified customer returns still usually require a manual case.
• Weight or dimension reclassification — Amazon recalculates a product's shipping weight and retroactively charges a higher fee.

Flipkart-specific errors

Flipkart sellers most often run into:

• Delayed settlements — payments for delivered orders that don't appear in the expected payment cycle at all.
• Return-to-origin (RTO) charges applied even when the return was not caused by the seller.

Meesho-specific errors

Meesho's supplier payment structure has its own quirks:

• Unscheduled deductions — charges that appear in a payment cycle with no clear order reference or explanation attached.
• Forward and return shipping charged on the same order without a corresponding valid return.

Category and referral fee misclassification

Amazon's referral fee is set by the product's assigned fee category, not by its browse category, its HSN code, or common sense — and the two can disagree in ways that materially change what a seller is charged. A real example from Amazon's own India seller forum: a seller listed a reusable stainless-steel bottle and was charged the 9.5% referral fee for "Health and Household – Sports Nutrition & Meal Replacement Shakes," even though the product was a durable container, not a consumable. The seller pointed to Amazon's own Associates classification (Kitchen and Dining) and the item's HSN code as evidence, but Amazon's community team rejected the appeal on the grounds that fee category and browse/HSN classification are separate systems — and told the seller to open a fresh case specifically requesting a "Referral Fee category correction."

That case illustrates two things sellers should take away: first, a product can be miscategorised for fee purposes even when its listing and tax classification are correct; second, disputing it requires filing the right case type in Seller Central's Case Log, instead of a general inquiry. A 5–7 percentage point swing in referral fee, multiplied across every unit sold before the error is caught, is one of the largest silent margin leaks on Amazon.

Inventory reconciliation report discrepancies

Amazon Seller Central's inventory and reimbursement reports (accessible under Inventory > Manage FBA Inventory, and the FBA Reimbursements report under Reports > Fulfillment) are meant to let sellers reconcile what Amazon says happened to a unit against what actually happened. In practice, sellers regularly find units marked "disposed," "lost," or "found" with no matching reimbursement line, or reimbursements issued at the wrong value. Amazon has shifted to a sourcing-cost basis for many reimbursement calculations rather than the item's selling price — sellers in the FBA seller community have reported recovery amounts dropping noticeably under the new model, which makes catching every eligible event, not just the biggest ones, more important than it used to be.

Claim windows here are unforgiving: most inventory reimbursement cases must be opened within 60 days of the event, with an absolute outer limit of 18 months from the inventory event, and claims are not honoured at all for carrier damage, customer-damaged returns, or expired items. Miss the window and the money is gone regardless of how clear the error is.

SAFE-T claims and seller-fulfilled reimbursements

For seller-fulfilled (non-FBA) orders, Amazon's SAFE-T claim process is the mechanism for recovering money lost to buyer-side refund abuse — return-fraud refunds, false "item not received" claims where tracking shows delivery, or refunds issued outside Amazon's stated return policy. Amazon has been steadily tightening this window; sellers should expect it to run in the range of 30 to 60 days from the return scan or refund date rather than assuming a generous buffer, and to lose eligibility once Amazon auto-refunds a return that wasn't inspected in time. The practical implication is that SAFE-T disputes need to be filed the same week the refund posts, not batched up at month-end during settlement review.

A-to-Z Guarantee claims and chargebacks

An A-to-Z Guarantee claim lets a buyer request a refund directly from Amazon when they believe an order wasn't fulfilled as promised. Amazon notifies the seller and gives seven calendar days to respond with evidence; if the seller doesn't respond in time, or Amazon finds the seller at fault, Amazon refunds the buyer and debits the seller's account for the full amount — item price, tax, and shipping. A parallel path exists through card-network chargebacks, and if Amazon has already granted the buyer an A-to-Z refund before a chargeback lands, Amazon represents the case to the issuing bank on the seller's behalf. From a reconciliation standpoint, every A-to-Z debit should be matched against an actual case in the Case Log — debits that don't trace back to a specific, documented claim are worth escalating on their own.

Weight and dimension reclassification disputes (Flipkart and couriers)

Flipkart, like most Indian marketplaces and courier partners, bills on whichever is higher: the actual gross weight or the volumetric (dimensional) weight calculated from the package's dimensions. A single mismeasured box can inflate the courier charge passed through to the seller by a meaningful amount per parcel, and for sellers on Flipkart Smart Fulfilment, repeated weight mismatches can also trigger penalties or account-level restrictions, not just a one-off fee.

The dispute mechanics are tight: the weight discrepancy charge typically posts to the seller's invoice around 10 days after dispatch, while the window to actually dispute it is often as short as 7 days from when the charge appears — meaning sellers who only reconcile monthly can miss the window entirely before they've even seen the charge. Packing photos or a short unboxing/packing video taken at the time of dispatch, showing the item and its measured dimensions, is the single most effective evidence in these disputes and is explicitly accepted by major courier partners.

TDS and TCS under GST: a compliance error, not just a settlement error

Two separate deductions apply to nearly every marketplace sale in India, and sellers frequently conflate them. TCS under GST Section 52 is collected by the marketplace (the current rate sits around 1% of the net taxable value) and is meant to be claimed back as credit against the seller's GST liability. TDS under Income Tax Section 194-O is deducted separately, on the gross transaction amount, and is credited against income tax rather than GST. Both show up as separate line items on the same settlement report from Amazon, Flipkart, and Meesho.

The reconciliation risk isn't just a smaller payout — it's a compliance one. TCS collected by an e-commerce operator only becomes usable credit once the seller matches it against the operator's own GSTR-8 filing (due by the 10th of the following month) inside their GSTR-2B. If the seller's own sales records don't match what the marketplace reported in its GSTR-8, the mismatch commonly surfaces later as an ASMT-10 scrutiny notice from the GST department — turning a settlement reconciliation gap into a tax notice months after the fact.

How to actually catch these

Every error above shares the same weakness: it's invisible in a dashboard summary and only shows up when the settlement report is compared against the seller's own order, return, and tax data, line by line — within the specific claim window each marketplace allows. Doing that manually in a spreadsheet is possible at low order volumes; at real scale, across three marketplaces with three different report formats, three different dispute processes, and three different claim clocks running at once, a tool that automatically flags order-level mismatches — like TheEcomWay's reconciliation engine — is the only practical way to catch every eligible discrepancy before its window closes, instead of only the ones large enough to notice by eye.