Regional sellers running on Shopee, Lazada, TikTok Shop, Tokopedia and Bukalapak-class channels usually end up with one browser tab per marketplace and one spreadsheet per country. Orders are keyed into ERPNext by hand or by CSV import, so the Sales Order and Delivery Note trail never matches what the marketplace shipped. Stock is a single Bin figure the seller mentally divides across five storefronts, so the same last unit sells three times and the oversell penalties follow. Payouts arrive net of commission, service fees, shipping subsidies, coin and voucher offsets and withholding, and nobody can tie a settlement line back to a Sales Invoice. ERPNext core handles the accounting perfectly well; what it does not have is any concept of a marketplace channel, a per-channel stock reservation, a settlement file, or an identifier coming back from a partner API — and the community connectors that exist are single-marketplace, so five channels means five unrelated apps with five reconciliation styles.

What we build is one Frappe application — a proper installable app with its own module, fixtures and hooks.py, not a pile of Server Scripts — that treats every marketplace as a configured instance of the same model. A Marketplace Channel DocType holds credentials (encrypted Password fields), region, currency, shop ID and the tax profile; a Marketplace Order DocType is the raw, immutable landing record for every pulled order, keyed on the marketplace order ID with a unique index so a re-pull is idempotent. Scheduler events registered in hooks.py poll each active channel on your chosen cadence, and where the marketplace supports push, a whitelisted endpoint (@frappe.whitelist(allow_guest=True) with HMAC signature verification) accepts the webhook, enqueues via frappe.enqueue and returns immediately. From the landing record we map to a real ERPNext Sales Order using the channel's Item mapping — marketplace SKU to your Item Code, including bundle explosion where one listing ships as several Items — and then let ERPNext's own logistics do the work: Delivery Note, Sales Invoice, and, where a country requires it, the localized tax document via your existing regional compliance app rather than a second implementation of it.

Per-marketplace stock buffers are the piece that stops the overselling. Rather than pushing your raw actual_qty to every channel, the app maintains a Marketplace Stock Allocation per channel and Item — a fixed reserve, a percentage of free stock, or a priority-ordered waterfall — and a scheduled job computes publishable quantity from Bin less reserved-for-other-channels less open marketplace orders, then pushes only the delta to each channel API. Every push is logged with the request, the response and the resulting quantity, so when a marketplace disputes what you sent you have the record. Doc events on Stock Ledger Entry, Sales Order and Delivery Note mark affected Items dirty for the next cycle, so a warehouse transfer or a cancelled order re-publishes within minutes instead of overnight.

Payout reconciliation gets its own document. A Marketplace Settlement is pulled or uploaded per payout batch, its child table holds every fee line the marketplace reports — commission, transaction fee, service fee, shipping fee and subsidy, voucher and coin offsets, adjustments, withholding — and a matching routine links each line to its Sales Invoice by marketplace order ID. What matches becomes a Journal Entry or Payment Entry posting the net receipt to the marketplace's receivable account and each fee to the expense account you nominate per channel and per fee type; what does not match lands on an exceptions list with the reason stated. Returns and refunds run the same way in reverse: a marketplace return creates a Sales Return / Credit Note against the original invoice, restores stock to a per-channel inspection warehouse rather than straight to sellable, and the settlement's refund line reconciles against it. Role profiles and permission rules ship with the app so a marketplace operator can process orders and returns without seeing the General Ledger, and the Frappe REST API plus whitelisted methods let your 3PL or BI tooling read the same records.

This is a build-to-order engagement, not a download. It starts with a scoping call where we confirm which marketplaces and countries are in play, which API programs you already have seller access to, your Item and warehouse structure, your tax and invoicing obligations per country, and your Frappe/ERPNext version. We then quote a fixed scope, build against your version (v15 or v16), and deliver on a staging copy of your site for UAT before anything touches production. Typical delivery is one working week from confirmed scope, longer if a marketplace requires an app-approval process on their developer portal — we will tell you at scoping if that is on the critical path. You receive the full source, the git repository, documentation and training, and a post-go-live support window.