The question
We build accounting software for freight forwarders. It handles their books and their balance sheet, so it knew exactly what they owed their vendors, but it couldn't pay them. The question was whether anyone would pay us to change that.
How a vendor actually gets paid
A vendor sends an invoice. Someone in the accounts team enters it into our software, which records who needs to be paid, how much, and by when.
Our system could only record the payment, not make it. The actual transfer happened in the company's bank portal, usually done by a different person working off a spreadsheet exported from us. So we knew what was due. We found out what was actually paid when someone matched the bank statement against our records by hand, usually at the end of the day.
What I thought was going on
For a long time I agreed with our CEO on this one.
He wanted the team on collections — QR codes on invoice links, money coming in faster. Payouts had been on the roadmap for months without getting picked, and I didn't push for it, because of something I'd learned selling to businesses. Almost nobody pays for speed. They pay for more revenue, better compliance, or money not leaking out. Productivity is a soft promise, and a finance team can't point to it the way they can point to revenue or savings.
Connected payouts looked like a productivity feature to me. Fewer steps, less manual work, a few hours saved each week. By my own test it shouldn't have sold.
Watching it happen
I had just taken over the finance and accounting part of the product. A customer in Mumbai was being onboarded, so I went to their office and asked the accounts team to show me how they actually paid a vendor.
The invoice went into our system. From there, someone exported every payment due that day into one Excel sheet and posted it in a WhatsApp group. Their finance manager had to approve it, so the team kept messaging him until he did. He checked each line against old email threads to confirm the amount was right. Then he uploaded the sheet to the Kotak portal. The founder gave the final approval, though since two people had already checked it, he mostly read the total. The money went out.
The real checking happened after that. At the end of the day someone downloaded the bank statement, uploaded it back into our system, and matched every payment by hand.
Three people looked at this, and the first check that could actually catch a mistake happened after the money had gone. I asked what would happen if the same vendor ended up in that sheet twice. They said someone would probably catch it, but nobody could tell me who.
That was the first time I doubted my own read on it. But I'd been wrong in this direction before, so I went to check properly.
What the customers said
I spoke to six enterprise account owners, and I avoided asking whether they wanted faster payouts. I asked what goes wrong instead.
None of them talked about paperwork. Their worry was that if a vendor gets paid twice and doesn't send it back quickly, that cash is stuck. Stuck cash means a gap in working capital, and covering a gap can mean borrowing, which means paying interest on money that's technically still yours.
That changed how I saw it. It wasn't a productivity feature, it was money going out that shouldn't, which is one of the few things businesses do pay for.
Then one of them asked what it would cost, and that question was the real answer. Everyone says yes to things that are free. Some were happy with a flat fee for the add-on, others preferred paying per bank connection, and three of them put money down for beta access. I took the commitments to the CEO rather than the interview notes, and it went on the roadmap.
Which banks, and why
There were two ways to actually move money. We could use a payments company — Open Money, Cashfree, Easebuzz — that already connects to every bank and sells that access. Or we could build a direct connection to each bank ourselves.
The payments companies were faster to work with, but payouts weren't core to their products, and the ones that did it well charged enough that we'd have had to pass the cost on. Our customers were already paying their vendors, so asking them for a cut to move their own money was a hard sell on top of a feature they were already paying for. We went direct to the banks instead, which meant each bank was its own integration and we couldn't do them all.
I ran a query across our 120 customers. The top five or six banks covered 80% of them, and the three enterprise accounts who'd build alongside us and give feedback were all on Kotak, HDFC and ICICI. That made phase one straightforward. Later phases would take us to eight or ten banks and 80–90% coverage.
We also surveyed all 120 customers to check I wasn't building for six loud voices. 68% said they wanted it, and 12% worried it would add to their workload.
Catching a duplicate payment
Flagging a possible duplicate wasn't difficult. We match a payment against existing entries on vendor, amount, date, invoice number and bank account.
Deciding what to do next was harder. Blocking the payment was the obvious answer and the wrong one, because legitimate repeats exist — the same vendor, the same amount, two months running. If we blocked those, the team would go back to the bank portal, which was the workflow we were replacing. This was exactly what the 12% in our survey had been worried about: a new system that made their day harder instead of easier.
So we flag it and route it to the accounts head instead of back to the person who entered it, because nobody should be clearing their own flag.
The founder's approval was the other call. Automating it was tempting, but we left it alone. It isn't friction, it's the control, and the bank already does it well — the approval reaches his phone with the beneficiary and the amount, which is what that decision needs. We were trying to automate the mechanical steps, keep the judgment calls, and put each judgment with the person who has the context for it.
Where it stands
Everything up to the accounts head's approval now happens in one place, and the final approval stays at the bank. Connected Payouts is in beta with Kotak, HDFC and ICICI, across a group of customers who move about ₹100 Cr in payouts every month. The next phase takes it to eight or ten banks.
What I'd do differently: I was right that businesses don't pay for speed. I was wrong to assume that's all this was, and I assumed it without validating with customers or observing their workflow. Three customer conversations would have settled it months earlier.