Meesho Seller Marketplace Connector

The pain

Meesho sellers live on volume. Thin per-unit margins mean an order that looked profitable at dispatch can end up negative once a return ships back, a commission slab changes, or a shipping charge is deducted at settlement. Most sellers work from downloaded Meesho payment reports and a spreadsheet, then re-key summary journal entries into Zoho Books days or weeks later. By then nobody can answer the only questions that matter: which SKUs are actually making money, how much stock is sitting in transit against RTO, and whether the settlement Meesho paid matches the orders it claims to be paying for.

The manual pattern also breaks GST. Marketplace sales, returns and TCS need to land in Zoho Books with the right place of supply, HSN and tax treatment for GSTR-1 and GSTR-3B. Aggregated monthly entries hide the detail that a notice will ask for.

What ECOSIRE builds

ECOSIRE builds a connector that lives inside your own Zoho organisation. There is no third-party middleware account, no data sitting on someone else's server, and no per-order surcharge from us.

Order ingestion into Zoho Inventory

A scheduled Deluge custom function polls the Meesho seller endpoints your account is entitled to and creates Sales Orders in Zoho Inventory against a dedicated Meesho contact or per-buyer contact, as you prefer. Each order carries a stored meesho_order_id, meesho_sub_order_id, AWB, dispatch-by date and status in custom fields, so nothing depends on parsing a reference string later. Idempotency is enforced on the sub-order identifier — a re-run of the same window never doubles an order.

SKU and catalogue mapping

Meesho catalogue identifiers rarely match your internal SKU. We build a mapping layer — either a Zoho Creator app or a Zoho Inventory custom module with a lookup — holding Meesho SKU, your Zoho Item, pack size and a multiplier for combos. Unmapped SKUs are quarantined in an exception queue with a notification rather than silently creating junk items.

Inventory, packages and shipments

On confirmed orders the connector reserves and decrements stock in the correct Zoho Inventory warehouse, creates the Package and Shipment records, and writes the courier AWB back so your team can track from Zoho rather than from the seller panel. Warehouse selection is rule-driven — by pincode zone, by stock availability, or fixed — and is defined during scoping.

Returns, RTO and cancellations

This is where marketplace accounting usually fails. The connector handles the full reverse path: cancellations before dispatch release the reservation; customer returns and RTO create Credit Notes in Zoho Books and a receipt back into a nominated returns warehouse or a damaged-goods bin. Each reverse movement is linked to the original Sales Order so per-order profitability stays intact.

Settlement and commission reconciliation in Zoho Books

Settlement files are parsed line by line, not summarised. For each payout the connector creates the invoice-level receipt plus separate Bills or Expense entries for Meesho commission, shipping/logistics charges, penalties, and any adjustment head present in your report. TCS and TDS deductions are posted to the accounts you nominate. The payout total is then matched against the bank transaction in Zoho Books so the marketplace clearing account reconciles to zero instead of drifting.

GST treatment

We configure tax rates, HSN codes, place of supply derivation from the ship-to state, and the correct treatment for returns and TCS so that Zoho Books reports feed GSTR-1 and GSTR-3B without manual restatement. Where your CA has a preferred posting structure, we build to that structure.

Exception handling and visibility

Every run writes to a log. Failures — an unmapped SKU, an API error, a settlement line with no matching order, a quantity mismatch — raise a record in an exception queue with the raw payload attached and, optionally, a Zoho Cliq or email alert. Nothing fails silently.

Reporting

We deliver custom Zoho Analytics or Zoho Books reports for net realisation per SKU after commission and returns, RTO rate by SKU and by pincode zone, and settlement ageing so you can see money Meesho owes but has not yet paid.

Who this is for

Sellers running meaningful Meesho volume who already keep books in Zoho Books, brands operating Meesho alongside their own D2C store or other marketplaces, and finance teams or CAs who need marketplace revenue to be auditable at line level rather than reconstructed from spreadsheets at year end.

How delivery works

1. Scoping call. We walk through your Meesho account setup, your Zoho Books organisation, warehouse structure, SKU conventions, existing chart of accounts and how your accountant wants marketplace revenue and charges posted. You share sample order and settlement exports. 2. Fixed quote and specification. You receive a written scope with the exact objects, fields, functions and reports we will build, the assumptions, and a fixed price. Nothing starts until you approve it. 3. Build. Typically one working week. We build in our environment and against a sandbox or trial Zoho organisation, not against your live books. 4. Install in test. The connector is installed into a test Zoho organisation or a controlled segment of your live org. We run real historic orders and a real settlement file through it and reconcile the output with you. 5. Production go-live. After you sign off on the test results we install into production, configure credentials, set schedules, and run the first live cycle together. 6. Support. A defined post-go-live support window covers defects, marketplace field changes and configuration adjustments. Ongoing support beyond that window is available separately.

What this is not

This is not a pre-built app you download and install today. Every deployment is built for your Zoho organisation and your Meesho account structure. Access to Meesho seller data depends on the API access, credentials or report exports available to your own seller account — we build against what your account can legitimately provide, and we confirm exactly which channels are available during scoping.