Daraz Seller Marketplace Connector

The pain

Most Daraz sellers run two disconnected systems: the seller centre, where orders arrive and labels get printed, and Zoho Books, where the business is supposedly accounted for. The bridge between them is a person typing. That person types order lines, types customer names, types payout summaries at the end of a cycle, and does it again for every country the business sells into. Every hour spent typing is an hour not spent buying stock or fixing listings, and every typed figure is a figure nobody can audit.

The cost shows up in three places. Stock is wrong, because marketplace sales only reach Zoho Inventory when someone remembers to record them, which means other channels oversell. Margin is unknown, because commission, payment fees, shipping charges and promotional deductions are netted out of a payout and never posted per order. And cash is unexplained, because the bank credit from the marketplace rarely equals any number the books contain, so a clearing balance drifts month after month until it is quietly written off.

Cash on delivery makes all of this sharper. Revenue is recognised at one point, cash arrives much later, and a meaningful share of orders never converts at all because the buyer refuses the parcel. Without per-order tracking, the difference between shipped and settled is a guess.

What ECOSIRE builds

ECOSIRE builds a connector that runs inside your own Zoho organisation using Deluge custom functions, scheduled jobs, Zoho REST APIs and, where useful, Zoho Flow and a Zoho Creator control app. You own it. There is no middleware subscription and no per-order charge from us.

Order ingestion into Zoho Inventory

Scheduled functions poll for new and updated orders and create Sales Orders in Zoho Inventory. Each record stores the marketplace order number, per-item identifier, shipping provider, tracking number, delivery type and current status in custom fields. Ingestion is idempotent on the item-level identifier, so overlapping polls and manual re-runs never duplicate an order — a failure mode that quietly corrupts stock in most hand-built integrations.

Packing and dispatch workflow

The connector drives the ready-to-ship lifecycle rather than just reading it. Orders move through pack, ready-to-ship and shipped states, tracking numbers are written back into Zoho Inventory, and the corresponding Package and Shipment records are created so your warehouse works entirely from Zoho. Where your account supports it, status updates and tracking are pushed back to the marketplace so you are not maintaining state in two systems.

SKU mapping

Seller-centre SKUs, variant identifiers and your internal item codes rarely agree, especially across three country accounts. We build a mapping application — a Zoho Creator app or a Zoho Inventory custom module — holding marketplace SKU, seller SKU, Zoho Item, variant and bundle composition. Unmapped items are quarantined in an exception queue with an alert rather than creating orphan items in your catalogue.

Multi-country structure

Pakistan, Bangladesh and Sri Lanka mean different currencies, different tax rules and usually different seller accounts. We configure the Zoho Books structure your accountant requires — separate organisations per country, or one organisation with branch and currency segregation — and set base currency, exchange-rate handling and exchange differences on settlement explicitly. For Pakistani sellers we configure sales tax treatment, invoice numbering and any withholding-tax posting your tax adviser specifies.

Returns, refusals and cancellations

Cancellations release stock reservations. Customer returns and delivery refusals create Credit Notes in Zoho Books linked to the originating Sales Order, and post the physical movement into a returns warehouse or a damaged-goods bin. Because cash on delivery means a refused parcel was never paid for, the connector distinguishes a refusal from a post-payment return and posts each correctly instead of collapsing them into one adjustment.

Payout statement reconciliation in Zoho Books

Payout statements are parsed line by line. For each cycle the connector posts the customer receipts plus separate Bills or Expense entries for commission, payment fees, shipping and logistics charges, promotional or campaign deductions, and penalties — each to an account you nominate. The payout is matched against the bank transaction in Zoho Books, and the marketplace clearing account is expected to reconcile to zero. Lines that cannot be matched to an order stay open as exceptions; nothing is force-balanced to make a report look tidy.

Exception handling and audit trail

Every run is logged with the raw payload retained. Unmapped SKUs, API errors, unmatched payout lines, quantity mismatches and status conflicts raise exception records with Zoho Cliq or email alerts. When you dispute a deduction with the marketplace, you can show exactly what their API returned and when.

Reporting

We deliver Zoho Analytics or Zoho Books reports for net realisation per SKU after all deductions, delivery-success and return rate by SKU and by city or region, cash-on-delivery ageing between shipment and settlement, and outstanding amounts owed but not yet paid out.

Who this is for

Sellers doing enough Daraz volume that manual entry has become a full-time job, brands selling across Pakistan, Bangladesh and Sri Lanka who need one consolidated inventory and margin picture, businesses running Daraz alongside their own store or another marketplace, and accountants who need marketplace revenue posted at line level rather than as a monthly summary journal.

How delivery works

1. Scoping call. We review your seller accounts and countries, your Zoho Books organisation structure, warehouses, SKU conventions, chart of accounts, tax registrations and how your accountant wants marketplace deductions posted. You share sample order and payout exports. 2. Fixed quote and specification. A written scope covering every custom field, function, mapping table and report, with stated assumptions and a fixed price. Nothing is built until you approve it. 3. Build. Typically two to four weeks, extending where multiple country accounts and a large catalogue are in scope. We build in our environment and against a sandbox or trial Zoho organisation, never your live books. 4. Install in test. Installed into a test Zoho organisation, then run against your real historic orders and a real payout statement so you and your accountant can reconcile the output before anything touches production. 5. Production go-live. After sign-off we install into production, configure credentials and schedules, and run the first live payout cycle with your team. 6. Support. A defined post-go-live support window covers defects, marketplace API or report changes, and configuration adjustments. Ongoing support is available separately.

What this is not

This is not an off-the-shelf app and there is no instant download or free trial — the connector does not exist until it is built for your organisation. What the connector can read and write depends entirely on the API credentials and permissions your own seller account holds; we confirm that during scoping and build to your actual access rather than an assumed one.