Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
What Platform Settlement Reconciliation Involves
Platform settlement reconciliation is one of the most structurally complex reconciliation types in Indian enterprise finance. Unlike bank reconciliation — where the goal is to match book entries to a single-column bank statement — settlement reconciliation must unpack a multi-layer deduction structure before matching is even possible.
Consider a D2C brand selling through Razorpay on its own website and also listing on Amazon and Flipkart. Each channel generates a different settlement file format, with different deduction logic, different payment cycles, and different TCS treatment. The amount received in the bank from each channel is a net figure — and that net figure must be reconciled not just to a sales total, but to individual order IDs in the order management system, each with its own return and refund history.
At 50 orders per month, this is manageable in a spreadsheet. At 5,000 orders per month across three channels, it is not — not because the matching is conceptually difficult, but because the data preparation, format normalisation, and exception classification consume more time than the team has before the books need to close.
The Deduction Structure in Platform Settlements
Every platform settlement — whether from a payment gateway or a marketplace — applies deductions before paying out. Understanding the deduction hierarchy is a prerequisite for reconciliation: you cannot match a net settlement to gross orders without knowing what was taken out and why.
| Deduction | Applied By | Typical Rate | Tax Treatment |
|---|---|---|---|
| MDR (Merchant Discount Rate) | Payment gateways (Razorpay, PayU, Cashfree) | Typically 1.5–2.5% of transaction value | GST at 18% on MDR charged by gateway |
| TCS (Tax Collected at Source) | Marketplaces (Amazon, Flipkart, Meesho) | 1% of net taxable value (0.5% CGST + 0.5% SGST) | Adjustable against seller tax liability via Form 26AS Part F |
| Platform / commission fee | Marketplaces and aggregators | Category-based, typically 5–25% of selling price | GST at 18% on commission charged by platform |
| Refund adjustments | All gateways and marketplaces | Full or partial refund deducted from settlement batch | MDR and GST may or may not be reversed (gateway-specific) |
| Penalty / policy violations | Marketplaces | Variable; listed in settlement detail as penalty line items | GST may apply depending on nature of charge |
Each deduction layer must be separated and recorded independently in your books. See platform settlement matching pattern →
Where Platform Settlement Reconciliation Breaks
Settlement file format divergence
Each aggregator uses a different settlement file format. Razorpay's settlement detail export has different column names, settlement groupings, and refund handling than PayU or Cashfree. Amazon's settlement report uses a different structure entirely from Flipkart's. A team managing three channels manually maintains three different spreadsheet templates — and when any platform changes its settlement file format (which happens without notice), all three templates break simultaneously.
Batch-level vs transaction-level settlement
Payment gateways typically batch multiple transactions into a single settlement and provide a net payout. The batch may contain 200 transactions settled as a single bank credit. Matching a single bank credit to 200 individual orders requires a two-step process: first explode the batch into constituent transactions, then match each transaction to the corresponding order ID. Missing this two-step structure — and instead trying to match the bank credit directly to a daily sales total — produces a nominal match that hides individual transaction errors.
Refunds and return processing timing
Refunds create the most problematic mismatches in platform settlement reconciliation. A refund processed in a different settlement cycle than the original order reduces a future settlement's net amount without the corresponding reversal appearing in the same file as the original order. In marketplace scenarios, returns can happen 7 to 30 days after the original settlement, creating a sustained trail of partially offsetting entries across multiple settlement files.
TCS recording and Form 26AS matching
For marketplace sellers, TCS deducted by Amazon, Flipkart, or Meesho must be extracted from each settlement batch and credited to a TCS receivable account. This TCS must then be matched to the TCS certificate provided by the operator and to Part F of Form 26AS, where it should appear after the operator deposits it with the government. A seller with ₹50 lakh gross monthly sales across two marketplaces may have ₹50,000 in TCS each month — if this is not tracked and claimed correctly, it becomes a permanent credit loss.
The Platform Settlement Reconciliation Process
A structured platform settlement reconciliation process has three phases.
Phase 1 — Settlement file ingestion and normalisation
Ingest the settlement file from each platform (API pull or SFTP download), then normalise it to a common schema: transaction ID, order ID, gross amount, deduction type, deduction amount, net amount, transaction date, settlement date. Each deduction line becomes a separate row in the normalised output, not a summary column in the original file. This normalisation step is where most manual reconciliation processes are weakest — different people treat multi-deduction rows differently, creating inconsistent outputs.
Phase 2 — Order-level matching
Match each settlement transaction to the corresponding order in your order management system or ERP using the transaction reference ID or order ID. For payment gateways, the gateway payment ID maps to the order ID in your system. For marketplaces, the Amazon or Flipkart order number maps to your internal SKU and sales order. Where exact matches exist, confirm the gross amount and classify any deductions. Where no match exists, flag as an exception: either the order was captured in the settlement but not in your system, or a settlement entry has been received for an order that appears in your system as pending or failed.
Phase 3 — Bank credit confirmation
After all settlement transactions are matched to orders, confirm that the net amount across all matched transactions equals the credit received in the bank statement for that settlement period. If the bank credit matches the net settlement, reconciliation is complete for that batch. If there is a difference, it indicates either a settlement file error or a bank credit error — both of which require follow-up with the aggregator.
How Automated Matching Handles Platform Settlements
TransactIG's platform settlement pattern is pre-configured for Razorpay, PayU, Cashfree, Paytm for Business, and the major Indian marketplaces. Field mapping templates handle the format differences between platforms so that the normalisation step is automated rather than manual.
The matching engine applies a two-level approach: first, match by transaction reference ID (exact match); then, for unmatched entries, apply fuzzy matching on order ID, amount, and date within a configured tolerance window. Refunds are matched to their parent transaction using the refund ID field, not treated as standalone exceptions. TCS deductions are extracted automatically and posted to the TCS receivable account with the operator GSTIN as the source identifier.
For organisations managing multiple platforms simultaneously, see how retail and e-commerce settlement reconciliation works end-to-end, including the multi-channel aggregation logic. The complete reconciliation software guide covers platform settlement alongside TDS, GSTR-2B, and NACH in a unified framework.
According to RBI payment system data, UPI transaction volumes crossed 16 billion in a single month in 2025. As digital payment volumes grow, the settlement reconciliation problem grows proportionally — making structured automation increasingly necessary even for mid-size organisations.
Revenue Leakage in Platform Settlements
Revenue leakage in platform settlements is not a theoretical risk — it is a measurable, recurring cost that most sellers absorb without realising it. Based on reconciliation data across Indian marketplace sellers, 2-3% of gross payment volume is typically lost through deduction errors that go undetected in unreconciled settlements.
The most common sources of leakage include: commission applied under the wrong product category (a 15% commission charged instead of 8% because the listing was miscategorised), weight-based shipping overcharges where the actual shipment weight is lower than the weight used for fee calculation, return processing fees not reversed when the return was cancelled or rejected by the seller, and duplicate penalty deductions for the same SLA violation.
For a seller with ₹5 crore monthly GMV across marketplaces, a 2% leakage rate represents approximately ₹10 lakh per month in avoidable losses. Over a financial year, this compounds to ₹1.2 crore — often exceeding the cost of the reconciliation infrastructure needed to detect and recover it.
Recovery mechanisms exist but have strict deadlines. Amazon's SAFE-T claims (Seller Assurance for E-Commerce Transactions) must be filed within 90 days of the settlement. Flipkart's seller support tickets for fee disputes have a 60-day window. Missing these deadlines converts a recoverable error into a permanent loss. Structured reconciliation that identifies deduction anomalies within the settlement cycle — not at quarter-end — is the only reliable way to stay within these recovery windows.
Platform Settlement Comparison: Cycles, Rates, and Key Deductions
Each platform has a different settlement cycle, fee structure, and deduction methodology. The table below summarises the key parameters that affect reconciliation configuration for the most common Indian platforms.
| Platform | Settlement Cycle | Primary Fee | Key Deductions |
|---|---|---|---|
| Razorpay | T+2 business days | MDR 1.5-2.5% | MDR, GST on MDR, refund adjustments |
| Amazon Seller | T+2 (Easy Ship), T+7 (FBA) | Referral fee 2-22% by category | Referral fee, closing fee, FBA fee, TCS 1%, weight handling |
| Flipkart | T+5 to T+15 (tier-based) | Commission 2-20% by category | Commission, shipping fee, fixed fee, collection fee, TCS 1% |
| Meesho | T+7 to T+15 | Zero commission model | Shipping fee, penalty deductions, TCS 1% |
| PayU | T+2 business days | MDR 1.5-2.5% | MDR, GST on MDR, refund adjustments, chargeback deductions |
The variation in settlement cycles alone creates reconciliation complexity. A seller receiving a Razorpay settlement on Day 3, an Amazon settlement on Day 9, and a Flipkart settlement on Day 16 must maintain three parallel reconciliation timelines for the same sales period. Each timeline has different deduction line items, different reference ID formats, and different dispute resolution mechanisms. For detailed platform-specific guidance, see our articles on Razorpay settlement reconciliation, Flipkart seller settlement, and Amazon Pay settlement.
GST on Platform and Marketplace Fees
Every platform fee — MDR, commission, shipping charge, closing fee — attracts GST at 18%. This GST is deducted from the settlement along with the base fee, creating a two-layer deduction that must be separated and recorded independently in the seller's books. The base fee is a business expense; the GST on that fee is claimable as Input Tax Credit (ITC) — but only if recorded correctly.
For marketplace sellers, an additional tax layer applies: TCS (Tax Collected at Source) under Section 52 of the CGST Act at 0.5% CGST + 0.5% SGST (or 1% IGST for inter-state supplies) on the net taxable value of goods sold. This TCS is deducted from the settlement and must be tracked separately — it is not an expense but a tax credit adjustable against the seller's GST liability.
Additionally, TDS under Section 194-O of the Income Tax Act applies at 0.1% on the gross amount of sales facilitated by the e-commerce operator, for sellers whose previous year turnover exceeds ₹5 lakh. This TDS is reflected in Form 26AS and is adjustable against income tax liability — but it must be reconciled separately from the GST TCS.
The reconciliation requirement is therefore threefold for each settlement: (1) separate the base fee from GST on the fee and record ITC, (2) extract TCS and post to the GST TCS receivable account, and (3) extract TDS under 194-O and post to the income tax TDS receivable account. Sellers who consolidate these deductions into a single "platform charges" entry lose ITC on the GST component and fail to claim TCS/TDS credits — a permanent and compounding financial loss. For more on TCS treatment, see our guide on TCS for e-commerce operators.