Milaan: how we built a reconciliation engine that matched every rupee across UPI, cards, COD and bank settlements

Milaan's founder did not open with a feature list. She opened a spreadsheet. It had forty tabs: one per payment gateway, one per courier partner's COD remittance, one per bank account, and a dozen with names like "FINAL v3 (use this)". Two people in her finance team spent most of every month copying numbers between them.

Her D2C business sold across its own website, two marketplaces and a growing offline channel. Money arrived through UPI, cards, wallets, pay-later providers and cash on delivery collected by four different couriers. Each source reported in its own format, on its own schedule, with its own idea of what a transaction ID was.

The result was a month-end close that took three weeks, refunds that were sometimes paid twice, and COD cash that couriers had collected but not yet remitted — nobody could say how much. "I know we're profitable," she told us, "I just can't prove it on any given day."

The brief said "a reconciliation dashboard". In the first workshop we asked the finance lead to walk us through a single order, from click to cash in the bank. It took forty minutes and touched seven systems. That walk-through changed the project: a dashboard would only show the mess faster. What Milaan needed was a single ledger where every rupee had one identity from order to settlement.

We proposed a three-layer design. Ingestion would pull raw data from every source without changing it. A normalisation layer would translate each source into one common transaction model. A matching engine would link orders, payments, refunds, fees and bank credits, and anything it could not match would land in a queue for a person to resolve.

Before designing screens we asked for six weeks of raw exports from every source. This was the least glamorous and most valuable part of the project. We found gateways that split one payment into several settlement lines, a courier that remitted COD in weekly lumps with no order references, refunds that appeared in the gateway report two days before the order was marked returned, and bank statements where the narration was cut off after 30 characters.

Every one of these quirks became a matching rule. By the end of the audit we had a catalogue of 43 edge cases, each with a real example, and we built the matching engine's test suite from them before writing the engine itself.

Finance teams trust spreadsheets because they can see every number and how it was calculated. Our designer's rule was that Milaan should never ask them to trust a number they could not trace. Every total can be clicked open to the underlying transactions, and every match shows which rule made it.

The daily workflow became an exceptions inbox: the engine handles everything it is sure about, and the team spends their morning on the handful of items it is not. Each exception shows the likely cause — a partial refund, a missing courier reference, a fee that does not match the contract — and suggests the most probable match.

Reconciliation is a data problem wearing a UI, so the team was weighted toward backend and data engineering. The designer and the engagement lead spent a day a week sitting with Milaan's finance team throughout the build.

Money software punishes shortcuts, so we wrote down the expensive decisions and agreed them with the founder and her finance lead before building.

Twenty-eight features shipped in the first production release, organised around the finance team's day: bring the data in, match it, handle what does not match, and close the books.

We built Milaan alongside the existing spreadsheet, not instead of it. For two full month-end closes the finance team ran both, and we compared Milaan's numbers with theirs line by line. Every difference was either a bug in Milaan or an error in the spreadsheet; roughly half turned out to be the spreadsheet.

The matching engine went through four major revisions. The biggest leap came from matching in passes — exact reference matches first, then amount-and-date windows, then many-to-one settlement groups — rather than one clever algorithm trying to do everything at once.

Milaan became the system of record at the start of a new financial quarter, which gave the team a clean opening balance. The first month-end close on Milaan took a fraction of the usual time, and for the first time the founder could see outstanding COD per courier on a single screen during a board meeting rather than promising to follow up.

The feature the finance team talks about most is not the matching engine. It is the fee audit, which compares every gateway and courier charge against the contracted rate and flags overcharges automatically.

Reconciliation projects are won or lost in the data audit. The six weeks spent collecting ugly real-world exports saved months of guessing, and the edge-case catalogue became the most valuable artefact of the whole project.

Explainability is the product. Finance teams will adopt automation only when they can see why it did what it did; every match in Milaan carries its reason, and that is why the team trusted it within weeks.