Razorpay Reconciliation Software for India — Settlement, MDR, GST, TDS Matching
Razorpay settles net of MDR, 18% GST on MDR, refunds from prior periods, chargebacks, and — where the merchant operates an e-commerce marketplace — Section 393(1)(j) TDS at 1% on gross sales. The bank credit is one line; the underlying composition is twenty. TransactIG ingests the Razorpay settlement report and transaction sidecar, rebuilds the gross-to-net waterfall per payment ID, classifies the GST-on-fee component for ITC, and produces a journal-ready, audit-ready reconciled close — without any TransactIG-side custom code on Razorpay's API surface.
What Razorpay Settles Natively, and Where the Reconciliation Gap Appears
What Razorpay handles natively
Razorpay acquires the payment across UPI, debit and credit cards, netbanking, EMI, wallets, international cards, and BNPL, settles on T+1 or T+2 (instant settlement on a per-transaction fee, weekly batch for marketplaces), and produces a settlement report plus a transaction-level sidecar that itemises every fee, GST, refund, and chargeback. Smart routing splits payments across acquirers transparently. RazorpayX adds payouts and vendor disbursement on the other side of the wallet.
For customers running disciplined order-management and a single GST registration, the dashboard answers the “did the customer pay” and “did the money arrive” questions cleanly.
Where the reconciliation gap appears
The bank credit is net. The ERP invoice is gross. In between sit MDR (varies by instrument), 18% GST on MDR (input tax credit subject to Rule 36(4) and the Razorpay tax invoice appearing in GSTR-2B), refunds reversing from prior payouts on T+5 to T+7, chargebacks with multi-stage dispute lifecycles, and — for marketplace structures — Section 393(1)(j) TDS at 1% on gross sales under payment code 1010 of the Income Tax Act 2025.
Without a reconciliation layer, finance teams either book the net credit straight to revenue (losing the ITC, mis-stating gross sales, breaking 3CD reporting) or spend the close cycle on a manual XLOOKUP exercise against the sidecar.
TransactIG Capabilities on Razorpay
Six matching surfaces that sit alongside Razorpay, reading the settlement report and sidecar as the source of truth and writing journal-ready output back into the customer's ERP.
Settlement file ingestion
Scheduled dashboard download to customer SFTP, or settlement.processed webhook to a customer-owned endpoint. Settlement report plus transaction sidecar joined on settlement ID.
MDR + 18% GST classification
MDR per instrument separated from the 18% GST on MDR. GST flagged ITC-eligible and aged against Razorpay's monthly tax invoice appearing in GSTR-2B under Rule 36(4).
Section 393(1)(j) TDS — code 1010
For marketplace structures: 1% on gross sales under Section 393(1)(j) of the Income Tax Act 2025 (payment code 1010, replacing legacy 194O). Reconciled to Form 26AS at code level.
Section 52 CGST TCS — 1%
Section 52 of the CGST Act 1% TCS — unchanged — applied by the marketplace operator, reconciled against the GSTR-8 filed by the operator. Carried separately from the income-tax TDS.
Refund / chargeback timing
T+5 to T+7 refund reversal pattern handled — refund liability aged from original payment to the bank debit. Chargebacks tracked through dispute lifecycle states.
Variance taxonomy
FEE_DEDUCTION, TAX_DEDUCTION, REFUND_REVERSAL, ROUNDING, PARTIAL_PAYMENT, DUPLICATE_PAYMENT, NARRATION_UNPARSED — structured codes that route to the exception queue with maker-checker.
Razorpay Integration — Settlement File Architecture
Each row is a discrete feed configured during implementation. Razorpay publishes via its documented dashboard exports and webhook events; TransactIG owns the matching schema, fee classification, and variance taxonomy.
| Source | Ingest method | Cadence | Field mapping | Variance codes |
|---|---|---|---|---|
| Settlement report (header) | Scheduled dashboard download to SFTP, or settlement.processed webhook | Daily (T+1/T+2 default), per-event on webhook | Settlement ID → payout batch in TransactIG | PAYOUT_MISSING_IN_BANK, AMOUNT_MISMATCH |
| Transaction sidecar (line items) | Sidecar CSV attached to settlement report | Per settlement | Payment ID → order / invoice in ERP | ORDER_MISSING, PARTIAL_PAYMENT, DUPLICATE_PAYMENT |
| Refunds | Refund line items in sidecar; refund.processed webhook | Per refund event | Refund ID → original payment ID | REFUND_REVERSAL, REFUND_TIMING, REFUND_UNAPPLIED |
| Chargebacks / disputes | Chargeback line items in sidecar; dispute lifecycle events | Per dispute event | Dispute ID → original payment ID + evidence pack | CHARGEBACK_OPEN, EVIDENCE_PENDING, CHARGEBACK_LOST |
| MDR + 18% GST | Fee + GST columns in sidecar; monthly tax invoice from Razorpay | Per transaction, monthly tax invoice | Fee GL + GST input GL | FEE_RATE_MISMATCH, GST_ON_FEE_UNCLAIMED, ITC_INELIGIBLE_2B |
| TDS withheld (where applicable) | TDS column in sidecar; quarterly 26AS download | Per transaction, quarterly 26AS | WT line → payment code 1010 (393(1)(j)) or 1007 (393(1)(f)) | TDS_NOT_IN_26AS, RATE_MISMATCH, SECTION_RECLASSIFIED |
| Bank credit (net payout) | MT940 / CAMT.053 / bank portal statement | Daily | Bank narration UTR → settlement ID | NARRATION_UNPARSED, CREDIT_TIMING, NET_AMOUNT_DIFF |
Common Razorpay Reconciliation Gaps
MDR rate mismatch by instrument
Card MDR, UPI MDR, netbanking MDR, EMI MDR, and international-card MDR all differ. Manual GL postings assume an average — the per-transaction reality differs.
18% GST on MDR unclaimed in ITC
The 18% GST on Razorpay's fees is ITC-eligible input tax. Without a classification layer, this is booked to expense and the credit is lost.
Refund timing across payout boundaries
Refund initiated today reverses from a payout T+5 to T+7. The original credit and the eventual debit appear in different settlement reports — manual matching is error-prone.
Chargeback reversal lifecycle
Chargebacks move through initiated, evidence-submitted, won, lost — each state shifts the cash impact. Lost chargebacks need write-off; won ones need re-credit tracking.
Partial payments and multi-payment orders
A single order may receive multiple payments (split tender, EMI down payment plus instalment, deposit plus balance). Matching at order level requires N-to-1 logic, not 1-to-1.
Smart-routing acquirer drift
Smart routing sends one payment through one of several acquirers transparently — the merchant sees the same Razorpay payment ID, but the bank narration and timing characteristics vary by route.
How TransactIG Reconciles Razorpay
Ingest settlement file
Razorpay settlement report and transaction sidecar land via scheduled SFTP drop or webhook event. Bank statements, GSTR-2B, and Form 26AS feeds land in parallel.
Decompose deduction layers
Gross-to-net waterfall rebuilt per payment ID — MDR, GST on MDR, TDS where applicable, TCS where applicable, refunds, chargebacks. Each layer posted to the correct GL.
Classify variances + evidence
Unmatched items route to the exception queue with structured variance codes, ageing, and audit-ready evidence pack. Maker-checker workflow before any GL posting.
Frequently Asked Questions
What does the Razorpay settlement file contain and how does TransactIG ingest it? +
Razorpay publishes settlements through its dashboard with a downloadable settlement report and a transaction-level sidecar that itemises each payment, refund, chargeback, fee, GST on fee, and any TDS withheld. TransactIG ingests the settlement report and the sidecar together, joins them on the settlement ID, and rebuilds the gross-to-net waterfall for every payout. Customers configure either a scheduled dashboard download to SFTP or a Razorpay webhook landing on a customer-owned endpoint that pushes events into the same matching schema. No invented API endpoints — the publicly documented Razorpay settlement report download and webhook surface are both options.
How does TransactIG handle MDR and 18% GST on Razorpay fees? +
MDR varies by instrument — UPI is typically zero-rated for person-to-merchant flows, debit and credit cards carry materially different rates, netbanking sits in between, and EMI and international cards are higher again. Razorpay deducts MDR per transaction plus 18% GST on the MDR. TransactIG classifies the GST-on-fee component as ITC-eligible input tax (subject to the buyer's GST registration and Rule 36(4) availability in GSTR-2B), separates the MDR from the GST in the journal entry, and ages any provisional ITC until the Razorpay-issued tax invoice appears in 2B. Variance codes: FEE_RATE_MISMATCH, GST_ON_FEE_UNCLAIMED, ITC_INELIGIBLE_2B.
Where does Section 393(1)(j) TDS apply on Razorpay flows? +
Section 393(1)(j) of the Income Tax Act 2025 (payment code 1010, replacing legacy Section 194O) applies at 1% on gross sales where an e-commerce operator facilitates the sale of goods or services through its digital platform on behalf of a participant seller. Pure payment gateway acquiring — where Razorpay only acquires the payment without being the platform that lists or fulfils the sale — does not attract 393(1)(j) on the merchant. The provision applies in marketplace structures (Razorpay-powered marketplace operator paying the seller). TransactIG distinguishes the two structures at onboarding and applies the correct treatment per payment ID. Commission on aggregator services attracts Section 393(1)(f) at 5% (payment code 1007, replacing legacy 194H).
How are refunds and chargebacks handled in the reconciliation? +
Razorpay refunds reverse on a T+5 to T+7 cycle in most cases, with the refund debited from a future payout rather than the same payout that originally credited the payment. TransactIG matches the refund to the original payment by payment ID, ages the open refund liability until the bank debit appears in a later settlement, and tags the variance as REFUND_REVERSAL with the expected settlement date. Chargebacks follow a similar timing pattern but with a dispute lifecycle — initiated, evidence submitted, resolved — that TransactIG tracks as a separate state machine. Both flows reconcile back to the underlying order and SD billing document in the customer's ERP.
Does TransactIG handle Razorpay smart routing, instant settlement, and weekly batch payouts? +
Yes. Smart routing splits a single payment intent across multiple acquirers under the hood — the customer sees a single Razorpay payment ID, but the underlying acquirer (HDFC, ICICI, Axis, others) varies. Instant settlement settles in minutes instead of T+1 or T+2 against a per-transaction fee. Weekly batch payouts net a week of activity into a single Sunday or Monday credit. TransactIG handles all three by treating the Razorpay payment ID as the canonical key, ingesting the actual settlement timestamp from the settlement report, and applying the correct fee schedule per settlement type. The variance taxonomy is the same across all three modes.
How long does Razorpay reconciliation implementation take? +
2 to 4 weeks for most customers. Week one configures the settlement report download (scheduled dashboard export to customer SFTP, or webhook ingestion via a customer-owned endpoint), maps the Razorpay account IDs and sub-account hierarchy to the customer's GL chart of accounts, and aligns the MDR rate card to the fee classification rules. Week two configures the TDS treatment (e-commerce 393(1)(j) versus pure acquiring), the refund timing tolerance, and the ITC ageing thresholds. Weeks three and four cover the bank statement matching layer, the journal-entry generation, and the maker-checker workflow.
Reconciliation that fits the way Razorpay actually settles
Settlement file plus sidecar, gross-to-net per payment ID, ITC-classified GST on fees, Section 393(1)(j) handled where the structure calls for it. 2 to 4 weeks, ISO 27001:2022, AWS Mumbai.