Case study · Forensic ledger
तुम्हारा पैसा कहाँ जा रहा है?
Founder & Engineer·2025 – present·Node.js · TypeScript·Multi-tenant · Row-level security
On every archive I audit, 3–5% of the settlement totaltypically shows up as recoverable: pending penalties, unpaid RTOs, below-cost SKUs, and settlements that simply don't reconcile. Here is the machine that finds it, and the engineering behind each piece.
Under the hood
A multi-tenant pipeline: isolated per seller, reconciled by 15+ detectors, and traceable end to end.
The problem
Sellers don't lose money in big ways. They lose it in the gaps.
A penalty here, an uncredited return there, a SKU that quietly sells below cost. Each one is small enough to ignore and frequent enough to matter. A monthly total hides all of it, and an accountant reconciling by hand can't read thousands of sub-orders a month. Bahi Mitra reads every one.
every figure traces back to one sub-order ✦
What it surfaces, and how it's caught
RTOs that returned but never reached the warehouse. Every parcel stalled 30+ days gets flagged: the courier scanned it back, but the credit never landed in the settlement.
1 in 12 RTO rows
How it's caught: Return events and settlement credits arrive as separate feeds, often out of order. Detector joins them per sub-order and flags anything unmatched past a 30-day window, tolerant of partial and late rows.
True landed cost vs. listing price, line by line. Some SKUs lose money even when they sell, the kind of slow bleed that never shows up in a monthly total.
₹120–₹250 / order bleed
How it's caught: Landed cost is rebuilt per order (product + platform fees + shipping + amortized returns), then compared to the actual payout and rolled up per SKU, so a line-level loss surfaces even when the month looks fine.
Line items that don't sum to Meesho's stated total. Every ₹50+ drift is a row to chase, and across an archive the drift adds up.
3–5% of settlement
How it's caught: Every line item is summed per order and diffed against the stated total. Money is handled as exact integer amounts, so a real ₹50 gap is never rounded away and never invented.
Ranking, not anomaly-counting. Every figure slices across four axes so you can see exactly where the money concentrates, and where it leaks.
4 axes
How it's caught: Pre-aggregated rollups across four dimensions, queried as rankings rather than alerts. The question is 'where does the money concentrate,' not 'flag the weird row.'
The hard parts
Every figure on the dashboard drills back to a single sub-order. That rules out any 'mostly right' model: the reconciliation has to be arithmetic a seller can replay against Meesho, line by line. It's the hardest constraint and the reason anyone trusts the total.
Multi-tenant from the first commit. Row-level security seals each seller's data, files are encrypted, and a DPA guarantees no cross-tenant aggregation. One seller's archive never touches another's, by construction, not by convention.
Meesho changed its export format (Vintage A before Nov 2025, Vintage B since). Both parse into one normalized sub-order model, so every detector downstream stays format-agnostic and old archives still reconcile.
A deliberate call: no ML alerts crying wolf. The system ranks the biggest leaks first and shows the receipts, so the output is a prioritized to-do list a seller can act on, not a mystery to investigate.
By the numbers
40+
Sellers onboarded
100+
Shops audited
₹5Cr+
Monthly settlement audited
15+
Detectors / upload
3–5%
Recoverable / settlement
<5 min
First findings
What I took from it
Bahi Mitra is the first product I've owned end to end: the ledger math, the multi-tenant backend, the dashboard, and the seller on the other side of it. Owning all of it changed how I build. Every decision now traces back to one question, whether a seller can trust the number, and that turns out to be a good question to ask of any system.