A build-to-order Dynamics 365 Business Central extension that consolidates orders, stock allocation, tax-compliant invoicing, payouts and returns across the major Southeast-Asian marketplaces. ECOSIRE builds, installs and supports it for your tenant after a scoping call. Built to order by ECOSIRE for Dynamics 365 BC (build-to-order) — indicative price from $499.00 USD; request a quote for a scoped proposal.
Illustrative previewA build-to-order Dynamics 365 Business Central extension that consolidates orders,
stock allocation, tax-compliant invoicing, payouts and returns across the major Southeast-Asian marketplaces.
ECOSIRE builds, installs and supports it for your tenant after a scoping call.
No DIY setup — a working app, built, installed and supported by ECOSIRE.
Start with a one-time build price. We scope it with you at kickoff.
ECOSIRE builds, configures and installs it on your Dynamics 365 Business Central.
You go live in about 2–4 weeks, with a post-launch support window.
Selling on Shopee, Lazada, TikTok Shop, Tokopedia and their regional siblings means running five different order lifecycles at once. Each marketplace has its own order states, its own cancellation window, its own escrow-and-payout cycle, and its own fee schedule — commission, service fee, affiliate fee, free-shipping subsidy, coin cashback — all deducted before the money lands. Dynamics 365 Business Central has an excellent sales order, inventory and finance core, but it has no concept of a marketplace channel. Out of the box you get one availability figure, one sales order flow, no per-channel stock reservation, and no way to tie a single bank statement line to the 180 orders and 640 fee lines that produced it. Most sellers bridge that gap with spreadsheets and a bookkeeper, and discover the size of the gap only when the trial balance stops tying out.
The Southeast Asia Marketplace Pack is an AL extension we build for your Business Central tenant. It adds a Marketplace Channel setup table plus channel-scoped connection records, and a normalized Marketplace Order staging layer that every channel connector writes into before it becomes a Business Central Sales Order. Ingestion runs on job queue entries — one recurring codeunit per channel, with a watermark cursor, exponential back-off on HTTP 429, and idempotent upsert keyed on channel code plus external order id, so a replayed webhook or an overlapping poll never creates a duplicate order. Item mapping lives in table extensions on Item and Item Variant (channel SKU, channel item id, listing status) so your existing item numbers stay canonical. Table extensions on Sales Header and Sales Invoice Header carry the channel code, external order number and payout batch, and those fields flow through posting into the customer ledger and value entries — which is what makes channel profitability a real Business Central analysis rather than a report bolted on the side.
Stock is where multi-marketplace sellers actually lose money, so the pack treats it as a first-class problem. A Channel Stock Buffer table holds per-location, per-channel reserve quantity and a publish rule (fixed buffer, percentage, or priority waterfall across channels). A codeunit recalculates publishable quantity from item availability by location, net of the buffer and existing reservations, and pushes stock updates to each channel on its own cadence — because Shopee and Lazada throttle differently and a single global push simply gets you rate-limited. Event subscribers on OnAfterPostSalesDoc and the warehouse shipment events trigger a targeted re-push rather than a full catalogue sync, so an oversell window is measured in seconds instead of "until the nightly batch".
Tax and money handling are localized rather than generic. Invoice generation respects the Indonesian, Malaysian, Thai, Philippine, Vietnamese or Singaporean localization you actually run — VAT/GST/SST posting groups, tax-inclusive marketplace pricing unwound to net plus tax, and the reference fields your local e-invoice regime requires. Marketplace-collected tax posts to a separate account so you can prove what the platform withheld. Payout reconciliation imports each settlement statement into a Marketplace Payout header with fee lines mapped to G/L accounts through a configurable fee-type table, matches the order lines back to the posted sales invoices, and produces a payment journal that clears receivables and books every commission, subsidy and adjustment. Unmatched lines land on an exception page instead of quietly rounding into a suspense account. Returns come back through the same spine: a channel return creates a Sales Return Order or Credit Memo, restores the buffer, and reverses the associated fees where the marketplace refunded them. Everything is exposed through API pages (REST API v2.0 / OData v4) with dedicated permission sets, so Power BI, Power Automate and Dataverse-based flows read the same data your accountants close on.
This is build-to-order, not a download. You request a quotation, we run a scoping call, and we confirm which marketplaces, which country localizations, which Business Central release wave, and whether you are on SaaS (per-tenant extension or AppSource-track app) or on-premises. From confirmed scope, typical delivery is two to four weeks: we build against your version, deploy to a sandbox for UAT with your real order and settlement files, then install into production with a rollback plan. You receive the AL source code, a git repository handover, technical and user documentation, a training session, and a post-go-live support window. Nothing is pre-built and nothing is instant — the point is that the extension fits your channel mix and your chart of accounts on day one.
Runs storefronts on three or more Southeast-Asian marketplaces and currently reconciles orders in spreadsheets. Needs every channel order to land in Business Central as a real Sales Order with its channel identity intact, so picking, shipping and customer service work from one queue instead of five seller centres.
Closes the books across multiple countries and cannot explain the gap between gross marketplace sales and the cash that actually arrives. Needs payout statements imported, commissions and subsidies booked to the right G/L accounts, local VAT/GST/SST posted correctly, and unmatched settlement lines surfaced rather than absorbed.
Sells the same SKUs on every channel out of shared locations and has been burned by oversells during campaign days. Needs per-channel stock buffers, waterfall allocation across marketplaces, and stock pushes that react to posting events instead of waiting for a nightly job.
Owns the Business Central tenant and must approve anything installed on it. Needs readable AL source, a documented object range with no collisions, proper permission sets, API pages instead of ad-hoc data pulls, and a build that survives the next Microsoft release wave upgrade.
| Criterion | ECOSIRE | Custom Build | Competitor | Dynamics 365 Business Central Native |
|---|---|---|---|---|
| Fit to your channel mix and chart of accounts | Built after a scoping call against your exact marketplaces, countries and G/L structure | Fits perfectly if your AL team has marketplace API and settlement experience | Fits the vendor's assumed model; you adapt your accounts to their fee mapping | No marketplace concept exists — everything is manual entry or import |
| Time to production | Typically 2-4 weeks from confirmed scope, including sandbox UAT | Usually several months once discovery, build and hiring are counted | Installs in a day, then weeks of configuration and workaround discovery | Immediate, but the gap is filled by spreadsheets and a bookkeeper |
| Payout and fee reconciliation | Settlement import, fee-type-to-G/L mapping, invoice matching, exception page for unmatched lines | Achievable, but usually the last module built and the first to be under-tested | Often summary-level journal posting; line-level matching is a premium tier | Manual matching of bank lines to orders outside Business Central |
| Per-channel stock control | Channel buffers with fixed, percentage or waterfall rules and event-driven re-push | Depends entirely on how availability logic is designed up front | Commonly a single global stock push with one flat safety quantity | One availability figure; no channel reservation concept at all |
| Source code and ownership | Full AL source plus git repository handover; no lock-in | You own it outright, and you own the maintenance burden with it | Closed binary extension; changes go through the vendor's roadmap | Not applicable — nothing custom to own |
| Release wave upgrades | Maintenance arrangement recompiles and regression-tests before each Microsoft wave | Your team re-tests twice a year alongside their other work | Vendor updates on their schedule; you wait if they are late | Microsoft handles it, since there is nothing extra installed |
| Integration surface for BI and automation | API pages on REST API v2.0 / OData v4 with dedicated permission sets | Whatever endpoints you decide to build and document | Varies widely; some expose only their own UI pages | Standard BC APIs, which carry no channel or payout data |
| Cost shape | Fixed quotation for the build, plus an optional maintenance arrangement | Open-ended developer time, plus ongoing salary or contractor cost | Per-user or per-order subscription that scales with your growth | No extra licence cost, paid for in reconciliation labour instead |
This is a build-to-order extension, so nothing ships instantly. Typical delivery is two to four weeks from confirmed scope — that is, after the scoping call has settled which marketplaces, which country localizations, which Business Central version and release wave, and which fee and tax mappings apply. Scope changes mid-build (adding a fourth marketplace, adding a second country's tax treatment) shift the date, and we tell you by how much before we accept the change.
We build the channels you name at scoping. The architecture is channel-agnostic: each marketplace is a connector codeunit writing into the same normalized staging layer, so the sensible scope is the two to four platforms that actually carry your volume. Additional channels can be added later as an incremental engagement without touching the shared order, buffer and payout spine.
You get a post-go-live support window for defect fixes and configuration adjustments, agreed at quotation. Beyond that, Microsoft ships two major release waves a year plus monthly service updates; we offer a maintenance arrangement that recompiles and regression-tests the extension against each new wave before your tenant is updated. Because you hold the source and the git repository, you can also maintain it in-house or through another partner — there is no lock-in.
Yes. On SaaS we deliver a per-tenant extension, or an AppSource-track app where you need that packaging. On-premises we deliver the same AL extension compiled for your version and installed against your service tier. The differences are practical rather than architectural: outbound API calls from on-premises need your own network egress and credential store, and job queue scheduling depends on your NAS configuration — both are covered in the install documentation.
We build against the Microsoft localization you already run and against the specific countries in scope — Indonesia, Malaysia, Thailand, the Philippines, Vietnam or Singapore. Marketplace prices are usually tax-inclusive, so the extension unwinds them to net plus tax against your VAT/GST/SST posting groups, books marketplace-collected tax to a separate account, and carries the reference fields your local e-invoice regime requires. It does not replace a certified local e-invoicing solution where one is legally mandated; it integrates with it.
We review your installed extension list at scoping and allocate an object ID range that does not collide. Because the pack uses table extensions and event subscribers rather than modifying base objects, it coexists with most localization, warehouse and payment apps. If we find a genuine conflict — another app subscribing to the same posting event with incompatible behaviour — we raise it during scoping, not at UAT.
Yes. The AL source and a git repository with full commit history are part of the standard handover, along with the build pipeline notes needed to recompile against a future Business Central version. You own what we build for you.

A build-to-order Business Central AL extension that maps your 3PL warehouses into native sales and purchase flows — sending fulfillment orders, ingesting ASN and shipment confirmations, and reconciling on-hand quantities against each 3PL's stock balances.

A build-to-order Business Central (AL) extension that validates, standardizes and geocodes shipping addresses in real time at order entry, flags residential vs. commercial and surcharge risk, and catches duplicate customers before delivery failures cost you money.

A build-to-order Business Central extension that streamlines physical and cycle counting with barcode scanning, simultaneous multi-user count sheets, zone-based counting, and variance reconciliation that posts clean Item Journal entries — installed and supported by ECOSIRE on your tenant.

Closes mobile-scanning, label-printing and rapid-count gaps in Dynamics 365 Supply Chain Management's warehouse module. ECOSIRE builds, installs and supports a per-tenant AL extension on your own environment — no generic AppSource compromise.
A build-to-order Dynamics 365 Business Central extension that consolidates orders, stock allocation, tax-compliant invoicing, payouts and returns across the major Southeast-Asian marketplaces. ECOSIRE builds, installs and supports it for your tenant after a scoping call.