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.