Razorpay reconciliation
without the spreadsheet.

The reconciliation problem is not that the data is missing. Razorpay publishes all of it. The problem is that the shape of what arrives in your bank account does not match the shape of what your accounting system expects, and the translation between them is dull, repetitive and error-prone — which is to say, exactly the kind of work software should be doing.

What actually lands in the bank

The standard cycle is T+2 working days: payments captured today are settled two working days later. What arrives is a single credit, net of Razorpay's fees and tax, with refunds and adjustments already netted off. Your ledger, meanwhile, holds hundreds of individual orders at gross value. Neither side is wrong. They are simply different views of the same money, and nothing automatically joins them.

The join key is the UTR — the bank reference on the credit. Every settlement carries one, and it is what lets you tie a line on a bank statement to a settlement record and from there to the payments inside it. A reconciliation design that does not use the UTR is guessing by amount and date, which works until two settlements land on the same day for similar amounts.

The three things people get wrong

1. Treating settlement.processed as money in the bank. The webhook fires when Razorpay initiates the transfer, not when your bank credits it. The NEFT or IMPS leg can take up to about three hours on top. Systems that mark cash as received on the webhook show a balance the bank does not agree with, usually at the worst possible moment on a month end.
2. Reconciling gross against net. The settlement is net of fees and tax. If your books record the gross order value, the two never match and somebody starts a manual adjustments column. Fees and tax have to be posted as their own lines, taken from the settlement payload rather than estimated from a percentage.
3. Forgetting the timing of refunds. A refund issued after a settlement is deducted from a later one. That means a settlement can be smaller than the orders it covers, for reasons that live in a different week. Any matching logic that assumes a settlement only contains that period's payments will throw false exceptions constantly, and people stop trusting it.

A reconciliation system that cries wolf gets ignored within a month. The measure of a good one is not how much it matches — it is how few exceptions it raises, and how often the ones it does raise turn out to be real.

What we build instead

The mechanics are unglamorous and they work.

1. Ingest settlements automatically. Subscribe to the settlement webhooks and pull the settlement recon report on a schedule as a backstop. Webhooks can be missed; a scheduled pull means a missed event costs you a delay, not a hole.
2. Explode each settlement into its parts. Payments, fees, tax, refunds and adjustments, each stored as its own row against the settlement's UTR. This single step removes most of the manual work, because it is the step the human was doing.
3. Match to your ledger on order identifiers, not amounts. Amount matching breaks on partial refunds and on two orders of the same value. Carry your own order reference through to Razorpay at payment creation and match on that.
4. Post to the accounting system in the shape it expects. Gross revenue, fee expense, tax, refunds contra — four lines rather than one net lump, so the P&L is right without anybody adjusting it later.
5. Raise exceptions, not reports. The output people should see is a short list of things that did not match and why. Everything that reconciled cleanly should be silent.

What it is worth

The saving people quote is the hours, and those are real — typically most of a day a week for a business doing a few hundred orders a month. The larger saving is the errors that stop happening: fees mis-posted as revenue, refunds counted twice, a month closed on numbers that were nearly right. Those cost more than the hours and they surface later, usually in front of an auditor.

When not to build this

If you take twenty orders a month, do not build this. The reconciliation takes twenty minutes and the software will cost more than it saves for years. The honest threshold is roughly where the manual work exceeds half a day a week, or where a mis-posting has already caused a real problem. Below that, we will tell you to keep the spreadsheet.