Payment Gateway Reconciliation Platform for Indian Merchants
Every payment gateway settlement reaches your bank account net of MDR, GST on MDR, TCS deducted under Section 52, customer refunds, and platform fees. When you operate across Razorpay, PayU, Cashfree, and one or more marketplaces, a single month can produce dozens of settlement NEFT credits, each covering thousands of individual orders. Without structured reconciliation software for India, the gap between gross order revenue and net bank receipts becomes a standing unresolved variance — one that compounds every month and creates exposure during GST audits and annual financial close.
Why Payment Gateway Reconciliation Is Hard at Volume
The multi-deduction problem
A payment gateway does not transfer your gross order revenue. It transfers gross revenue minus MDR, minus 18% GST on that MDR, minus any customer refunds processed since the last settlement, and minus chargebacks still in dispute. MDR rates vary by instrument: UPI attracts 0%, debit cards 0.4–0.9%, credit cards 1.5–2%, and international cards 2.5–3.5%. A merchant processing all four instrument types will have a different effective MDR for every settlement batch.
For merchants selling through marketplaces, the deduction stack deepens further. Amazon, Flipkart, and Meesho settlement files include commission at varying rates by category, outbound logistics charges, return reversal debits, TCS under Section 52 of the CGST Act, and penalty deductions for SLA violations — all within a single settlement NEFT that may cover 5,000 or more individual orders. The volume of line items renders manual spreadsheet reconciliation unreliable within months of reaching any meaningful transaction scale, as reported across digital payment infrastructure tracked by the Reserve Bank of India.
The timing mismatch problem
Settlement cycles and refund cycles operate on different timelines. Razorpay and PayU settle on T+1 to T+3. Refund reversals, however, appear at T+5 to T+7 from the date the refund was initiated — and they are deducted from a future settlement, not the original one. This means a refund for an order settled in the March 28 batch may reduce the April 3 settlement. Your revenue register for March shows gross order value; your bank shows a net of MDR plus a refund deduction that belongs to a March order but appears in April's data.
Multi-gateway complexity adds a third dimension. A merchant running Razorpay for website payments, Amazon Pay for marketplace orders, and Cashfree for subscription billing will receive settlement files in three different formats, on three different cycles, with different deduction line-item naming conventions. Consolidating these into a single reconciled revenue view without a structured matching engine requires a finance analyst to spend days each month on a task that should take minutes.
What TransactIG Payment Gateway Reconciliation Does
TransactIG ingests settlement files from all your gateways and marketplaces, matches them to order-level data from your ERP or OMS, and classifies every deduction — improving match rates from the 51% typical of manual processes to 88% through automated matching rules configured for India's deduction taxonomy.
Multi-gateway settlement file parsing
Ingests settlement files from Razorpay, PayU, Cashfree, Amazon Pay, Paytm for Business, CCAvenue, and Stripe India via API or SFTP. Normalises each file format into a common transaction schema before matching begins — so format differences across gateways do not require separate handling by your team.
Deduction layer classification
MDR, GST on MDR, TCS, refunds, commissions, and penalties are classified into separate variance codes rather than treated as a single net deduction. Each deduction type routes to the correct accounting treatment: input-eligible fees to your ITC register, TCS to your Form 26AS matching queue, and penalties to operating expense.
TCS (Section 52) matching against Form 26AS
TCS deducted by marketplace operators at 1% on net taxable supplies is extracted from settlement files and matched against your Form 26AS Part A-I entries by PAN and quarter. Discrepancies where the deducted amount has not yet reflected in Form 26AS are held in a dedicated exception queue with settlement references, so your CA has the evidence needed to follow up with the marketplace.
Marketplace settlement matching at order level
Amazon, Flipkart, and Meesho settlement sidecar files are parsed at order level. Every commission charge, logistics fee, return reversal, and TCS deduction is linked back to the originating order ID and matched against your OMS records. One settlement NEFT covering 8,000 orders produces a fully itemised reconciliation register, not a single unresolved difference.
Refund timing reconciliation
Refund reversals deducted at T+5 to T+7 are traced back to their originating order ID regardless of which settlement period carries the deduction. Cross-period matching eliminates false open items that would otherwise persist as unresolved variances in month-end close, and provides an auditable trail linking each refund debit to the original order and customer.
GST input credit identification on gateway fees
GST at 18% charged on MDR and on marketplace commissions is input tax credit-eligible for GST-registered merchants. TransactIG identifies these amounts from settlement data, cross-references gateway and marketplace GSTINs against your GSTR-2B entries, and surfaces the claimable ITC so it is not left unclaimed at the end of the quarter.
Deduction Types in Indian Payment Gateway Settlements
Each deduction type in a gateway or marketplace settlement file requires different accounting treatment and a different match key. TransactIG classifies all six automatically.
| Deduction Type | Description | Tax Treatment | Match Key |
|---|---|---|---|
| MDR (Merchant Discount Rate) | Gateway processing fee deducted from settlement amount before payout | Input-eligible — 18% GST on MDR is claimable as ITC | Settlement ID + transaction date range |
| GST on MDR | 18% GST charged on MDR by the gateway on its tax invoice | Input tax credit claimable — gateway GSTIN appears in GSTR-2B | GSTIN of gateway + billing period |
| TCS (Section 52 CGST Act) | 1% TCS deducted by marketplace operators on net value of taxable supplies | Credit available in Form 26AS Part A-I and GST portal TCS ledger | PAN + quarter + marketplace operator |
| Refund / Chargeback Reversal | Customer refunds debited from future settlements, not the original settlement period | Net revenue reduction — reverses the original supply | Order ID + refund transaction ID |
| Platform / Commission Fee | Marketplace commission charged as a percentage of gross order value | Input-eligible — commission invoice with GST appears in GSTR-2B | Order ID + commission rate |
| Penalty / Adjustment | Deductions for late shipping, SLA breach, return fraud, or policy violations | Operating expense — not input-eligible | Case ID or order ID in settlement sidecar file |
How TransactIG Payment Gateway Reconciliation Works
Ingest gateway settlement files
TransactIG connects to Razorpay, PayU, Cashfree, Amazon Pay, and other supported gateways via API or SFTP. Settlement files are pulled daily or weekly on a schedule you define. Each file — including the sidecar transaction detail file — is ingested and normalised into a consistent schema. No manual download or format conversion is required from your team.
Match to order-level data from ERP or OMS
Order records from your ERP, OMS, or accounting system are mapped to TransactIG's matching schema during implementation. The matching engine compares each settlement transaction against your order register at Order ID and amount level. For marketplace files, individual order lines within a bulk NEFT settlement are matched separately. Cross-period matching links refund reversals to originating orders regardless of settlement date.
Exception queue with deduction classification and ITC identification
Unmatched items and classified deductions are routed to a structured exception queue. Each exception carries a variance code (FEE_DEDUCTION, TAX_DEDUCTION, REFUND_REVERSAL, PENALTY, ROUNDING), its deduction amount, the applicable tax treatment, and the suggested resolution action. Input-eligible deductions are surfaced separately for your GST ITC claim. TCS discrepancies are flagged with Form 26AS cross-reference data.
Industry Use Cases for Payment Gateway Reconciliation
Payment gateway reconciliation requirements vary by business model. The deduction types and match complexity differ across D2C brands, marketplace sellers, healthcare providers, and hospitality operators.
Multi-gateway revenue matching
D2C brands typically operate Razorpay or Cashfree on their own website alongside Amazon Pay or Paytm on marketplace channels. Each gateway settles on different cycles with different MDR rates. TransactIG consolidates all gateway settlements into a single daily reconciliation view — gross orders, net settlements, MDR by instrument type, GST on MDR for ITC claim, and refund exposure by gateway.
Order-level marketplace settlement matching
Sellers on Amazon, Flipkart, and Meesho receive bulk NEFTs covering thousands of orders. Commission rates vary by category, return rates vary by product type, and TCS deductions vary by quarter. See the full scope of this challenge in our retail and e-commerce reconciliation coverage.
TransactIG matches every order in the sidecar file to your OMS, classifies deductions by type, and produces a settlement register auditable at order level.
UPI and card collection reconciliation
Hospitals and diagnostics chains collecting patient payments via UPI, debit cards, and credit cards through payment gateways need to match each collection against the patient billing record in their HMS. TransactIG links gateway transaction IDs to patient encounter IDs, reconciles refunds to cancelled appointments, and produces a daily collection-to-bank register that supports statutory audit requirements.
OTA settlement reconciliation
Hotels receiving bookings through MakeMyTrip, Goibibo, or Booking.com face settlement structures analogous to marketplace sellers: commissions deducted at varying rates, cancellation refund reversals, and TCS where the OTA is classified as an e-commerce operator. TransactIG matches OTA settlement reports against your PMS reservation records, links cancellation debits to original bookings, and classifies OTA commissions for GST ITC treatment.
Manual Reconciliation vs. TransactIG
The operational and compliance cost of manual payment gateway reconciliation grows linearly with transaction volume. TransactIG's automated approach to the platform settlement pattern keeps reconciliation effort flat regardless of order count.
| Dimension | Manual / Spreadsheet | TransactIG |
|---|---|---|
| Match rate | 51% average — remainder carried as unresolved differences or written off | 88% automated match rate — unmatched items go to a classified exception queue, not a discard pile |
| Refund handling across periods | Refunds deducted from April settlement are rarely traced back to the March order — they stay as unexplained differences | Cross-period matching links every refund debit to its originating order ID regardless of which settlement period carries the deduction |
| TCS (Section 52) tracking | Manually extracted from settlement files and cross-checked against Form 26AS each quarter — prone to omission | Automated TCS extraction matched against Form 26AS Part A-I entries by PAN and quarter — discrepancies flagged in real time |
| GST ITC on MDR and commissions | Often unclaimed — MDR is netted as a single expense without separating the 18% GST component | GST on MDR and commission fees surfaced automatically with gateway GSTIN cross-referenced against GSTR-2B for ITC claim |
| Effort as volume scales | Finance team effort scales with order volume — 10,000 orders per month requires proportionally more analyst time than 1,000 | Matching effort is constant regardless of order volume — 50,000 orders processes in the same run time as 5,000 |
What is Payment Gateway Reconciliation
Payment gateway reconciliation is the process of matching payment gateway settlement reports against your order management system (OMS) and bank statements to account for every deduction between the gross transaction value and the net settlement amount deposited in your bank account. These deductions include MDR (Merchant Discount Rate), 18% GST on MDR, TCS at 1% under Section 52 of the CGST Act, customer refund reversals, chargeback debits, and platform-specific fees.
Each payment gateway — Razorpay, PayU, Cashfree, Paytm for Business, CCAvenue — settles on different cycles (T+1 to T+3 for domestic transactions, T+5 to T+7 for refund reversals) and embeds these deductions differently in their settlement files. A single bank credit from a gateway represents the net of dozens or hundreds of individual orders, each with its own deduction composition. Without order-level reconciliation, the finance team cannot determine whether the net settlement amount is correct, which deductions were applied to which orders, or whether the MDR rate charged matches the contracted rate.
For Indian businesses, payment gateway reconciliation carries additional tax implications. GST on MDR is an input tax credit claimable against the gateway's GSTIN in GSTR-2B. TCS deducted by marketplace operators appears as a credit in the GST electronic cash ledger. Treating the net settlement as a single accounting entry — rather than decomposing it into revenue, fees, tax credits, and adjustments — leads to unclaimed ITC, misclassified expenses, and GST return discrepancies that surface during annual audit.
UPI Reconciliation for Indian Businesses
UPI transactions account for a growing majority of digital payment volume in India, with over 14 billion monthly transactions as of 2024. While UPI is described as a zero-MDR payment method for person-to-merchant (P2M) transactions under ₹2,000, the operational reality for businesses is more complex. Payment gateways charge platform fees — typically 1.5% to 2% — for UPI collection through their APIs, making the effective cost non-zero even when MDR itself is waived.
The primary reconciliation challenge with UPI is reference matching. UPI transactions generate a 12-digit RRN (Retrieval Reference Number) that does not correlate directly with invoice numbers, order IDs, or any business-generated identifier. Unlike card transactions where the authorization code links to a specific order, UPI settlement reports contain RRNs that must be mapped back to orders through the payment gateway's transaction log. When this mapping breaks — due to gateway API timeouts, duplicate payments, or partial captures — the RRN appears in the bank statement without a corresponding order reference, creating an unmatched entry.
Settlement timing further complicates UPI reconciliation. UPI settles on T+1 for most gateways, compared to T+2 for credit cards and T+3 for net banking. This means UPI settlements arrive a day earlier, creating timing differences in the bank reconciliation that must be handled as a separate settlement stream. For businesses processing 10,000 or more UPI transactions per month, the volume of RRN-only entries in the bank statement exceeds what manual reconciliation can match within the close window.
TransactIG handles UPI reconciliation by ingesting the payment gateway's transaction-level data alongside the bank settlement feed, cross-referencing RRNs against order IDs through the gateway's mapping file, and matching each UPI settlement entry at the transaction level. For the full UPI reconciliation workflow, see the UPI settlement reconciliation guide.
Payment Reconciliation Best Practices
These practices are drawn from reconciliation patterns observed across Indian businesses processing 5,000 to 500,000 gateway transactions per month. Each addresses a specific failure mode that manual or ad-hoc reconciliation processes commonly exhibit.
Reconcile daily, not monthly
Daily reconciliation catches settlement discrepancies within the gateway's dispute window. Monthly reconciliation discovers them after the window has closed. For Razorpay, the dispute window for settlement shortfalls is 30 days. For Amazon SAFE-T claims, it is 90 days. A variance discovered on day 5 is recoverable. The same variance discovered on day 35 may not be. Daily reconciliation also reduces the month-end close burden — there are no 30 days of accumulated unmatched entries to work through on the first of the following month.
Set tolerance windows for settlement timing
Different payment methods settle on different cycles: UPI at T+1, debit cards at T+2, credit cards at T+2 to T+3, net banking at T+3, and refund reversals at T+5 to T+7. A reconciliation process that expects same-day settlement matching will generate false exceptions for every card and net banking transaction. Configure settlement timing tolerance per payment method and per gateway — this eliminates the majority of timing-based false positives and focuses exception review on genuine discrepancies.
Automate MDR verification against contracted rates
Payment gateways periodically revise MDR rates — sometimes unilaterally through updated terms of service. Without systematic verification, businesses discover rate increases only during quarterly reviews or annual audits. Automated MDR verification compares the MDR deducted on each settlement against the contracted rate per payment method and flags any deviation. For a business processing ₹5 crore monthly through gateways, a 0.1% undisclosed MDR increase costs ₹5,000 per month — ₹60,000 annually — without any notification to the merchant.
Track rolling reserves separately
Some payment gateways hold a rolling reserve — typically 5% to 10% of settlement value — as security against chargebacks and refunds. This reserve is withheld from settlements and released after a holding period (90 to 180 days). If the rolling reserve is not tracked as a separate receivable, the withheld amount appears as a permanent settlement shortfall in the reconciliation. Maintain a rolling reserve ledger that tracks withholding, ageing, and release dates per gateway to prevent these from aging as unresolved reconciliation items.
Maintain a 90-day settlement report archive
Gateway settlement files are the primary evidence for reconciliation, dispute resolution, and audit queries. Most gateways make settlement reports available for download for a limited period — typically 90 days for Razorpay, 60 days for PayU. After this window, historical reports require a support request and may take days to retrieve. Implement automated daily archival of settlement files from every active gateway to ensure that reconciliation evidence is available for the full financial year — as required by GST audit and income tax audit documentation standards.
Frequently Asked Questions
What is payment gateway reconciliation? +
Payment gateway reconciliation is the process of matching settlement deposits from payment gateways — Razorpay, PayU, Cashfree, Amazon Pay — against your order-level revenue records in your ERP or OMS. Each settlement is paid net of MDR, GST on MDR, TCS deducted under Section 52, customer refunds, and platform fees, which means a single bank credit rarely equals the sum of your gross order values. Reconciliation identifies which deductions apply to which orders, flags timing mismatches caused by T+3 settlement cycles and T+7 refund reversals, and produces a matched, auditable register for your finance and tax teams.
How does Razorpay settlement reconciliation work? +
Razorpay settles on a T+1 to T+3 cycle, depositing a net amount to your bank account after deducting MDR, 18% GST on MDR, and any pending refunds or chargebacks. Each settlement is accompanied by a sidecar transaction file that lists every order, its deductions, and the net settlement contribution. TransactIG ingests both the bank credit and the sidecar file, rebuilds the gross-to-net reconciliation at order level, and classifies each deduction separately — so your finance team sees MDR as a fee expense and GST on MDR as a claimable input tax credit, not a single opaque deduction.
How is TCS from marketplaces matched in reconciliation? +
Under Section 52 of the CGST Act, e-commerce operators including Amazon, Flipkart, and Meesho deduct 1% TCS on the net value of sales made through their platform. This amount appears as a deduction in your marketplace settlement file and must also appear in Form 26AS Part A-I (or in your GST portal under TCS credits). TransactIG matches TCS deductions from settlement files against your Form 26AS entries using PAN and quarter as the primary match keys. Discrepancies — where a marketplace has deducted TCS that has not yet reflected in Form 26AS — are held in a separate exception queue with the settlement reference for follow-up.
How does refund reconciliation work with payment gateways? +
When a customer refund is initiated, payment gateways process the reversal and debit it from a future settlement — not from the original settlement that included the order. Razorpay processes refund reversals at T+5 to T+7 from the initiation date, which means a refund for a March order may reduce an April settlement. This timing mismatch is the most common source of unresolved differences in gateway reconciliation. TransactIG links refund debits back to the original order ID regardless of which settlement period carries the deduction, closing the reconciliation loop across periods and eliminating false open items.
Can TransactIG handle marketplace settlement reconciliation for Amazon, Flipkart, and Meesho? +
Yes. Marketplace settlement files from Amazon, Flipkart, and Meesho include multiple deduction types in a single file: commission on gross order value, logistics charges, return reversal credits and debits, TCS under Section 52, penalty deductions for SLA or policy violations, and sometimes GST adjustments. TransactIG parses these files at order level, classifies each deduction into its correct category, and matches every order ID against your OMS records. The output separates commission (input-eligible), TCS (claimable credit), and penalties (operating expense) — providing the classification your accounts and tax teams need without manual re-sorting.
How long does payment gateway reconciliation implementation take? +
Implementation takes 2 to 4 weeks. The first week covers gateway integration — either via API connections to Razorpay, PayU, or Cashfree, or via SFTP for daily settlement file delivery. The second week maps your ERP or OMS order data to the reconciliation engine's matching schema. Weeks three and four apply configuration for your specific deduction types, tolerance settings, and exception routing rules. No code development is required on your side. TransactIG is cloud-only and does not require on-premise installation.
Stop carrying gateway settlement differences as open items
TransactIG connects to your gateways and your ERP in 2 to 4 weeks. No code development. ISO 27001:2022 certified. Order-level reconciliation from day one.