RecoBeanMulti-tenant SaaS for marketplace settlement reconciliation
- Custom Software Development
- UI/UX Design
- SaaS
- Fintech
- Workflow Automation
- India
- Live site
01 — The Challenge
Nobody can check the marketplace's arithmetic.
BlackBeans asked us to build a platform that ingests whatever an Indian marketplace exports, detects payment discrepancies on its own, and gives a seller one financial view worth trusting.
Three assumptions had to go before any of that worked.
The first is that the settlement figure is the settlement. Commission, shipping, fixed fees, collection fees, TCS and TDS all come off before the money moves, and the arithmetic is buried in exports running past fifty columns. Platforms rarely err in the seller's favour. The only way to know a payout is wrong is to recompute it independently from the seller's own rate cards.
The second is that three marketplaces can share one model. They genuinely settle differently — different formulas, different fee names, different cycles. Flattening them into one generic order would lose exactly the detail a discrepancy hides in.
The third is that finding the discrepancy is the job. A seller who reconciles by hand already spends 15–20 hours a month cross-referencing order sheets against payment sheets, and still catches only the obvious errors. What they cannot do is assemble the evidence fast enough to file a claim before the window closes.
02 — The Engine
Fifty-two models, eight shared contracts.
Each marketplace gets its own model of how money should move — fifty-two in all — held together by eight base contracts, one per domain concept: product, order, payment, return, TCS, claim and upload history.
| Platform | What the engine models |
|---|---|
| Meesho | Separate settlement formulas for delivered, cancelled (pre- and post-pickup), RTO, exchange and lost orders, each with its own TCS and TDS treatment |
| Flipkart | 19 models covering commission rates, shipping rates, fixed fees, collection fees, MP fee rebates and VAS transactions |
| Amazon | SP-API settlement reports covering referral fees, closing fees, weight handling fees, FBA reconciliation and SAFE-T claims |
Rate cards drive the arithmetic. Commission percentages by category, shipping rates by weight and zone, fixed fees per order — the platform ingests them, independently computes what the settlement should have been, and compares it to what actually arrived. When a rate card changes, every affected order is re-evaluated automatically, which is the only thing that catches a fee revision applied retroactively.
03 — Flags
A discrepancy that ships its own evidence.
Every flag carries the whole chain rather than a bare alert: the expected calculation, the actual settlement, the source files and the exact line items behind both. That is the difference between a number that disagrees and a claim a seller can file.
Flags carry one of four severities and escalate on their own as they age — a payment still missing 45 days after dispatch, or 30 days after a return was created — both store-configurable — climbs from medium to high to critical without anyone watching it. They carry a working state too, including one for issues waiting on the seller's own decision, so a quality dispute does not sit in the same queue as an arithmetic error.
Reverse shipping gets no tolerance at all. The charge is recomputed from product weight, return quantity and the courier partner's own rate card, and any variance is flagged.
The order model is the hub. Flags synchronise out to payments, returns and claims, so a seller chasing one problem sees every related record in one place rather than three.
04 — Getting Data In
An ingestion pipeline for whatever the dashboards export.
We built ingestion around the CSV and Excel exports the platform dashboards already produce, so sellers change nothing. The pipeline validates the format, maps each platform's column layout, deduplicates against existing records and triggers reconciliation without being asked. Files over 10MB go to an async queue so the browser never waits, and upload history is retained on a configurable window, 120 days by default.
What comes out the other side is a dashboard rather than a spreadsheet: revenue trends, fee breakdowns and margin analysis; return rates, quality issues and claims impact; and reconciliation health — outstanding discrepancies, timing violations and settlement accuracy scores — each on its own board.
05 — Isolation
One deployment, many sellers, no leakage.
The store is resolved from the request before application code runs, so scoping is a property of the platform rather than a thing each query has to remember.
| Guarantee | What it means for sellers |
|---|---|
| Complete data separation | Orders, settlements and reports are isolated end to end, verified across all layers rather than only in the UI |
| Isolation by default | Middleware resolves the store and rejects inactive ones before a view is reached, so no new feature can cross a boundary by omission |
| Independent catalogues | The same SKU or order number can exist in two stores without collision |
| Team access | Store owners invite team members into their own store only |
06 — The Visual Language
A quiet interface for numbers people already distrust.
Reconciliation is a trust product before it is a data product. The seller is being told a marketplace kept more than it should have, so the interface has to read like a ledger rather than a pitch.
There is no webfont anywhere in the app. The system stack paints on first render, and every monetary figure across the Amazon, Flipkart and Meesho views is set in tabular numerals — so amounts align down a column and a discrepancy registers as a shape before it is read.
One teal carries the whole product. The dark theme pairs a lighter teal against a deep ground rather than inverting the light one, so the same colour stays legible in both without turning into a different brand.
07 — Snapshot
The RecoBean build: stack, scope, shipping model.
| Client | BlackBeans Technologies |
| Segment | E-commerce payment reconciliation SaaS |
| Scope | SaaS development on Django — ingestion pipeline, reconciliation engine, flag system, multi-tenant architecture |
| Marketplaces | Meesho, Flipkart, Amazon |
| Data models | 52, platform-specific, over 8 shared base contracts |
| Detection | Flag-based, four severities, escalating with age and financial impact |
| Tenancy | Strict per-store, resolved at the middleware layer |
| Stack | Django, Celery, PostgreSQL, Redis |
08 — FAQ
What buyers ask about Django SaaS development and multi-tenant systems.
How does RecoBean know a settlement is wrong?
It does not trust the marketplace's number. It recomputes the settlement independently from the seller's own rate cards — commission by category, shipping by weight and zone, fixed and collection fees, TCS and TDS — and compares that to what arrived. Where the two disagree, the difference is the finding, and the arithmetic behind it is attached.
Why do three marketplaces need separate models?
Because they genuinely settle differently. Meesho needs distinct formulas for delivered, cancelled pre- and post-pickup, RTO, exchange and lost orders. Flipkart takes 19 models to express commission rates, shipping, fixed fees, collection fees, MP fee rebates and VAS transactions. Amazon arrives as SP-API settlement reports carrying referral, closing, weight handling and FBA fees. They inherit from eight shared base contracts so the engine stays coherent, but flattening them into one generic model would lose exactly the detail a discrepancy hides in.
What happens when a rate card changes?
Every affected order is re-evaluated automatically. This matters more than it sounds: marketplaces revise fee structures frequently, and a change applied retroactively can turn a batch of previously correct settlements into underpayments. Re-running the affected orders is the only thing that catches that class of error.
Can two sellers on the same deployment ever see each other's data?
No. The store is resolved from the request by middleware — before any view runs — and inactive stores are rejected there too. Scoping is therefore a property of the platform rather than something an individual query has to remember, which is what stops a newly added feature leaking by omission. Catalogues are independent, so the same SKU or order number can exist in two stores without collision, and team invitations are bounded to the inviting store.
How large a file can a seller upload?
Up to 100MB for the Flipkart and Amazon reports, 50MB for most Meesho ones, in CSV or XLSX, with platform-specific column mapping handled on ingest. Anything over 10MB is processed asynchronously through a Celery queue so the upload does not block the browser. Records are deduplicated on the way in, and upload history is kept on a configurable retention window, 120 days by default.
What does a multi-tenant SaaS like this cost?
A single-tenant tool and a per-tenant platform are different builds, and this one sits in the 4–8 month band; a single-marketplace version is a much shorter build. We price discovery separately, so you can stop after it holding a specification you own — whoever ends up building it.