The hidden cost of T+N: how settlement float quietly compresses merchant cash flow

The standard merchant question about a payment gateway is 'what's the MDR?' That's the visible cost — the percentage fee deducted from each capture before the net is settled. The invisible cost is the gap between capture date and bank-credit date, and for many Indian merchants it adds up to more than the headline rate.

Consider a merchant doing ₹1 crore per month through a gateway on a T+2 settlement plan. At any given moment, roughly two days of revenue — about ₹6.6 lakh — is sitting in the rail, captured but not yet credited. That's working capital the merchant can't deploy. If the merchant funds inventory or payroll on a 14-percent annual line of credit instead, the carrying cost of those two float days is roughly ₹2,500 per month. Small. Now run that across a ₹50 crore annual GMV and three gateways and a year, and you're at multiple lakhs of pure financing cost — paid silently, never invoiced, never on the P&L as a line item.

The 'instant settlement' tier most gateways now offer compresses this. Razorpay, Cashfree, and PhonePe all sell T+0 or near-instant settlement at a premium of typically 0.1–0.2 percentage points on top of the standard MDR. The arithmetic is straightforward: if the float-days savings exceed the premium, take the upgrade. For most growing merchants past a few crore monthly GMV, it does.

The harder problem is that float isn't uniform — it's concentrated around weekends, festivals, and quarter-ends. A T+2 settlement captured on Friday lands on Tuesday at the earliest, often Wednesday. A capture on the eve of Diwali might not credit for five business days. These spikes are when working capital strain is highest, and they're invisible until cash gets uncomfortably tight at exactly the wrong moment.

Reconciliation is what makes the float problem visible. A reconciliation system that reports per-cycle settlement timing — capture date, expected credit date, actual credit date — exposes the float distribution rather than just the average. The averages look fine; the tail is what hurts. Once a finance team can see that 12 percent of last quarter's captures took more than four business days to credit, the conversation with the gateway changes. So does the conversation about whether to keep the standard plan.

There's a related pattern around marketplace settlements that's often even larger. Amazon India remits prepaid roughly weekly and COD on a 14-day cycle; Flipkart runs cycles in T+7 to T+10 ranges; Meesho can stretch further depending on seller tier. A seller doing meaningful COD volume on a 14-day cycle is structurally lending the marketplace 14 days of cash, every day, forever. Some of this is unavoidable — it's the nature of the rail — but a meaningful fraction is recoverable through tier upgrades, faster-settlement options, or factoring arrangements.

The frustrating part is that this is rarely flagged in the way other costs are. A 0.5-percent MDR change provokes a renegotiation; a two-day float-extension goes unmentioned because no one tracks float as a measurable line. The reconciliation system is the natural place for it to live: it already has the capture data and the bank-credit data on the same axis. Adding 'days from capture to credit' as a reported metric and trending it month over month is a half-day engineering exercise with disproportionate financial visibility.

The deeper point is that merchant cash flow is shaped by a portfolio of settlement cycles — UPI essentially instant, gateways at T+1 to T+2, marketplace prepaid at T+7 to T+10, COD at T+14 to T+21, B2B receivables on whatever terms the contract specifies. Each cycle is a separate cost-of-capital decision. A finance function that treats reconciliation as just a bookkeeping accuracy problem misses this; one that treats it as a working-capital instrumentation problem turns it into the most important data source in the business.