What a settlement actually settles

There is a question every Indian seller using a payment gateway asks at least once in their first year, usually after a tense glance at their bank app. The Razorpay dashboard shows one number for the day's sales. The bank shows a smaller number, and often it shows up a day or two later than expected. The seller assumes the gateway has shorted them — and they fire off a polite-but-firm email to support. In nearly every case, no money is missing and nothing is late. The confusion is sitting on two axes at once. On amount, the dashboard, the settlement report, and the bank credit are three views of the same transactions at three different layers of the fee stack. On timing, the gap between capture and bank credit is T+N — where N depends on the rail and the calendar. Recognising both axes is the first step.

Between the gross transaction value and the rupee that lands in the seller's bank account, there are four legitimate deductions — every one on the gateway's settlement report. The first is the Merchant Discount Rate — the per-transaction fee, typically a percentage of gross. The second is the GST on the MDR itself (18%, claimable as input credit by GST-registered sellers). The third is TDS under Section 194-O — the gateway as e-commerce operator withholds 1% on gross transaction value where applicable. The fourth is a refund reserve hold, typically 0.5% to 1%, retained against chargebacks and released after a configurable settlement window. None of these is a shortfall; all of them are visible if you read the report.

The MDR is the layer that hides the most variance, because a single payout aggregates transactions across multiple card schemes — domestic debit cards, domestic credit cards, international cards, network-tokenised cards, UPI, net-banking, and wallet rails — each at its own rate. A 'blended' MDR of 2.0% is just an average; the underlying could be 0.4% on debit, 1.9% on credit, and 3.5% on an international transaction. When the actual blended rate deviates from the contract — say, the seller agreed to 1.8% blended and the settlement is at 2.0% — the variance could be a genuine rate-card breach by the gateway, or it could be an unusually high share of international cards that day. The only way to tell is to reconcile per scheme.

TDS u/s 194-O is the deduction that most often confuses sellers because it is invisible in the dashboard's 'Sales' line but very real on the bank credit. Section 194-O of the Income Tax Act, introduced in 2020, treats payment gateways as e-commerce operators and obliges them to deduct 1% TDS on gross transaction value at the point of settlement (thresholds and exemptions vary by PAN status and aggregate annual volume). The deduction shows up on the seller's Form 26AS as advance tax already paid — credit-able in their income-tax return. The practical implication: the bank credit is smaller than the gateway's 'Settlement Amount' line by the TDS, but the TDS isn't lost — it's a prepayment against the seller's annual tax liability.

The other dimension where settlements confound first-time sellers is timing. A bank credit doesn't arrive the same day the transaction was captured — it arrives T+N, where N depends on the card scheme, the payout cycle, the gateway's settlement bank, and the calendar. Most Indian gateways operate on T+1 or T+2 for domestic card payments and UPI, T+3 or T+4 for COD remittances, and T+5 to T+7 for international cards (Visa, Mastercard, and Amex international corridors clear through correspondent banks, which adds latency). The 'T' in T+N is the day the gateway captures funds; the 'N' counts only banking working days, not calendar days. A capture on Friday evening for a T+2 cycle does not settle Sunday — it settles Tuesday at the earliest, and slips further if Monday is a public holiday.

Holiday calendars are the most-missed cause of settlement-date drift. India has three layers of holiday calendar that affect when money moves between accounts. First is RBI's national bank-holiday list (Republic Day, Independence Day, Gandhi Jayanti, regional festivals declared as national bank holidays) — on these days, all bank clearing pauses. Second is each settlement bank's local-state holiday calendar — HDFC's Mumbai clearing pauses on Maharashtra-specific holidays even if Bangalore continues operating, and the seller's payout bank may sit in a different state than the gateway's clearing bank. Third is the RTGS, NEFT, and NACH operating windows — RTGS runs 24×7 since December 2020, but NEFT runs in half-hour batches between 00:30 and 19:00, and NACH has fixed cut-offs that close at 5 PM. A payout instruction issued at 6 PM on the eve of a long weekend can sit for three days before its first batch window opens.

The reconciliation implication is that gross-vs-bank cannot be matched on a same-day basis. The honest pattern is to maintain a rolling window — typically T−7 to T+0 for domestic and T−10 to T+0 for international — and let the matching engine pair settlements across that window. When today's bank credit ties back to a capture from four days ago, that's not a break; it's a T+N settlement landing on its calendar-shifted date. The reconciliation needs to know the expected window per scheme and flag exceptions only when items fall outside it. Tools that force same-day matching produce a cycle of false exceptions every Monday and after every long weekend, and over time the team learns to dismiss them — which is when a real break slips through.

The actual reconciliation work, once both the three-numbers and the T+N confusions are cleared up, isn't proving the bank credit equals gross sales on the same date. The math will always tie if the four deductions are computed correctly and the date window is set to the right span. The real work is per-layer and per-rail: proving every captured transaction made it into the eventual payout (no missed txns, no duplicate captures); proving the MDR applied per scheme matches the contracted rate card; proving the TDS was deducted on the right gross base (not on a post-fee base, which is a known mis-application); tracking the rolling refund-reserve balance so it isn't silently written off when released; and confirming each settlement landed within its expected T+N window for the rail it travelled. A finance team that runs these checks every cycle catches rate-card breaches in the cycle they happen, and surfaces genuine timing breaks (a missed payout, a stuck NEFT batch) as exceptions rather than absorbing them into a 'maybe tomorrow' bucket that everyone eventually stops watching.