Cross-border eBay selling looks simple until you try to close the books. Orders arrive across several eBay sites, in several currencies, against listings that carry size and colour variations. Payouts land as net deposits with the fees already deducted. Somewhere between the marketplace and Zoho Books, the detail disappears, and what should be a reconciliation becomes a monthly reconstruction.
The native marketplace sync inside Zoho Inventory handles the straightforward case: a flat item, one site, one currency, an order that arrives and an invoice that follows. Sellers who have outgrown that shape hit the same wall. Variation listings flatten into a single item, so stock for the medium blue shirt is deducted from a pooled quantity that does not exist. The final value fee, insertion fee, promoted listing spend, international fee and store subscription arrive as one net number, so gross revenue, cost of sale and marketplace expense are all wrong in the ledger even though the bank balance matches. Orders raised in one currency settle in another with no exchange difference recorded. Returns, cancellations and partial refunds are handled on eBay and then keyed into Zoho by hand, or not at all.
The result is a business that cannot answer basic questions. Which listings are actually profitable after fees. What the true landed margin is per site. Whether the oversell that cost a defect last week was a sync delay or a variation mapping error. None of that is visible when the ledger only sees a net deposit.
What ECOSIRE builds
We build a connector inside your own Zoho org using Deluge custom functions, a Zoho Creator application for mapping, scheduling and logging, and direct calls to the Zoho Inventory, Zoho Books and Zoho CRM REST APIs on one side and eBay's Sell APIs on the other. It runs on your credentials, on schedules you control, and every run is logged.
Variation listings mapped properly
Each eBay variation is mapped to a distinct Zoho Inventory item, grouped under an Item Group so the parent listing stays coherent. Quantity sync then works at the variation level: stock moves against the specific SKU that sold, not a pooled parent. Where a listing is fulfilled from a bundle or kit, it maps to a Zoho Inventory Composite Item so components are drawn down correctly. Mapping is held in a Creator table you can see and edit, not buried in code, and unmapped SKUs are surfaced as exceptions rather than silently invented.
Orders, fulfilment and stock
Orders are pulled from the eBay Fulfillment API on a schedule and created as Zoho Inventory Sales Orders against a customer record we resolve or create, with the buyer's shipping address, marketplace order reference and site written onto the record. Packages and Shipments created in Zoho Inventory push tracking numbers and carrier details back to eBay so the order is marked dispatched without anyone touching the seller portal. Available quantity flows the other way, from the Zoho Inventory warehouse you nominate back to the eBay listing, with a buffer you set to protect against sync-window oversells.
Fees broken out instead of netted off
This is the part most sellers buy the connector for. Transaction and payout data is pulled from eBay's finance endpoints and decomposed: gross sale, final value fee, fixed per-order fee, promoted listing spend, international and cross-border charges, shipping label cost and refunds. Gross revenue posts as an invoice in Zoho Books, each fee category posts to its own expense account in your Chart of Accounts, and the net payout posts as a bank deposit that matches your statement to the cent. Cost of goods flows from the Zoho Inventory item, so gross margin per listing is real rather than estimated.
Multi-site and multi-currency
Each eBay site in scope gets its own configuration: currency, price list, tax treatment, and the Zoho Books account mappings that apply to it. Invoices are raised in the transaction currency, payouts are posted in the settlement currency, and the difference is recorded against the exchange gain or loss account you nominate rather than being absorbed silently.
Returns, refunds and cancellations
Marketplace returns and cancellations create the matching Zoho Books Credit Note and, where stock comes back, a Zoho Inventory receipt against the right variation. Partial refunds are matched to the original invoice line rather than posted as an unexplained adjustment. Every write is idempotent, so a re-run or an API retry cannot duplicate an order or a payment.
Visibility
Customers and order history are written to Zoho CRM Contacts and your order module through a custom function, so repeat buyers are visible to the team. Zoho Flow handles the peripheral fan-out, such as alerting a channel on a failed sync or a stock threshold, while the money and stock paths stay in tested code.
Who this is for
Cross-border eBay sellers running Zoho Inventory and Zoho Books who list with variations. Sellers active on more than one eBay site or in more than one currency. Businesses that have outgrown the basic sync and are reconstructing payouts in spreadsheets. Sellers who need per-listing profitability after real marketplace fees, not revenue minus a guess.
How delivery works
This connector is built to order for your account and your chart of accounts. Nothing is pre-packaged and there is no instant download.
1. Scoping call. We review the eBay sites and currencies in scope, your listing structure and variation depth, how bundles are fulfilled, your warehouse setup, and how you want each fee category posted in Zoho Books. 2. Fixed quote. A written scope covering the sites, entities, sync directions, fee categories and postings, with deliverables, timeline and a fixed price. No work starts before you approve it. 3. Build. Typical lead time is two to four weeks depending on the number of sites, currencies and the complexity of your variation and bundle mapping. 4. Install in test. We install into a test Zoho environment and run a scripted pass using your eBay sandbox or a controlled set of live listings: order import, variation stock movement, tracking push, quantity push, fee decomposition against a real payout statement, refund, cancellation and a duplicate-run replay. 5. Production. We install into your live org, complete the initial mapping of existing listings, and walk your finance lead through the first full payout reconciliation before handover. 6. Support. A defined support window follows go-live for defects and configuration changes, extendable afterwards.
Scope boundaries
We integrate with the eBay APIs as published, under your own developer credentials and rate limits. We do not create or optimise listing content, manage repricing strategy, or influence marketplace policy outcomes. If a data point you need is not exposed by the marketplace API, we tell you at scoping rather than after the build.