Sellers running three or four Southeast-Asian marketplaces at once end up running three or four businesses. Each channel has its own order states, its own fee schedule, its own settlement cycle, its own returns window and its own idea of what an invoice should look like in Indonesia versus Malaysia versus the Philippines. Odoo core has no concept of a marketplace: sale.order has no channel, stock.quant has no per-channel allocation, and account.payment has no notion of a settlement statement that arrives two weeks after the sale with commission, shipping subsidy, campaign fees and a currency adjustment already deducted. Teams bridge the gap with CSV exports and a spreadsheet, and the spreadsheet quietly becomes the system of record — which is where the oversell and the unreconciled payout come from.

This pack puts the channel into the data model. We add a marketplace.channel model carrying credentials, currency, fee profile and fiscal position, and stamp every imported order with it, so sale.order gains marketplace_channel_id, an external reference and the raw channel payload for audit. Orders land through a scheduled ir.cron polling job or a webhook controller (whichever the channel supports), are de-duplicated on the external id with a database-level unique constraint, and map to your existing products through a marketplace.listing bridge — one Odoo product, many channel SKUs, so a bundle or a variant sold under three different listing codes still moves one product.product. Stock is not simply mirrored: a marketplace.stock.buffer model holds per-channel reserve rules (fixed units, percentage, or a compute reading forecasted quantity), and a @api.depends-driven compute publishes an adjusted availability figure per channel rather than your real free-to-use quantity, which is the single most effective defence against oversell during a 9.9 or 11.11 campaign.

The money side is where the build earns itself back. Settlement files and payout APIs are imported into a marketplace.settlement document with typed lines — commission, service fee, shipping subsidy, campaign contribution, adjustment, refund — and each line maps to an account through a configurable fee profile so posting produces a real journal entry rather than a lump-sum bank line. The settlement reconciles against the originating invoices and against the bank statement, and anything that does not match is left on an exception list with the order reference attached instead of being silently absorbed. Tax and invoicing follow the same rule: fiscal positions and tax mappings are driven per channel and per delivery region, and channel-specific document layouts are QWeb templates you can edit, not hard-coded HTML. Returns are modelled as their own flow, so a marketplace-initiated return creates the reverse picking and the credit note with the channel's own return id preserved on both.

Everything is a proper Odoo addon: a real __manifest__.py with declared dependencies on sale_management, stock and account, models under models/, access rights in ir.model.access.csv plus record rules so a country team sees only its own channels, list/form/kanban views in XML with OWL components only where a plain view genuinely cannot do the job, a settlement and reconciliation report in QWeb, and automated actions for the routine escalations. Credentials are stored per channel and never in source. The models are exposed over the standard XML-RPC/JSON-RPC API like any other, so your BI tool or a warehouse device can read them. We build against Community and note explicitly where an Enterprise-only feature (for example accounting bank-statement automation) changes the recommended flow, and we ship on whichever of Odoo 17.0, 18.0 or 19.0 you actually run.

This is a build-to-order product, not a download. You request a quotation, we run a scoping call, and we come back with a written scope naming the exact marketplaces, the settlement formats we will parse, the tax jurisdictions in play and the acceptance criteria. Typical delivery is one working week from confirmed scope. We install on a staging copy of your database first, run UAT with your own historical orders and a real settlement file, and only then go to production with a documented rollback. You receive the full source in a git repository you own.