Selling on Lazada while running Dynamics 365 Business Central usually means someone downloads a seller-centre order export every morning and keys it into a sales order page, then keys the stock back the other way at night. The cost is not the typing — it is the drift. Lazada shows quantity you have already sold in a shop, an item goes out of stock two hours before the sync catches it, a return is refunded on the marketplace and never credited in Business Central, and the monthly payout lands as a single bank line that nobody can tie to individual orders. Business Central is a genuinely strong ERP for inventory, costing and finance, but out of the box it has no concept of a Lazada order, a marketplace SKU, a commission fee or a settlement statement. Sales orders, item ledger entries and general journals are all there; the marketplace-shaped layer that feeds them is not, and Shopify is the only first-party e-commerce connector Microsoft ships.

What we build is an AL extension for your Business Central tenant that adds that missing layer as first-class BC objects. Lazada order documents land in a staging table with the raw payload preserved, then a mapping engine turns each one into a Business Central sales order — customer, ship-to address, currency, item lines resolved through an explicit SKU-to-Item cross reference (Item Reference records, so a Lazada seller SKU never has to equal your No.), shipping fee lines and voucher/discount lines posted to the G/L accounts you nominate rather than being silently absorbed into unit price. A configurable status map decides what a Lazada order state means to you: pending may sit as an unreleased order, ready_to_ship may release and create a warehouse shipment, delivered may post the shipment and invoice, canceled may cancel the document and write an audit note. Nothing posts by a rule we invented — the map is a setup page your controller owns.

Technically it is ordinary, maintainable Business Central work, which is the point. Integration runs through codeunits scheduled as job queue entries, not through a timer nobody can see: an order-pull codeunit, a stock/price-push codeunit, a listing-export codeunit and a settlement-import codeunit, each with its own recurrence, its own error log and its own retry behaviour, so a Lazada API outage delays one queue rather than blocking posting. Outbound stock sync hangs off event subscribers on item ledger and reservation changes so an availability change queues a push within seconds instead of waiting for a nightly batch; the push itself is throttled and batched to respect Lazada's rate limits. Authentication, endpoint region (Lazada operates per-country endpoints), app key and signing secret live in Isolated Storage, never in a plain table field. Everything readable is exposed through API pages (REST API v2.0 / OData v4) so Power BI, Power Automate or a Dataverse virtual table can read marketplace order and settlement data without a second integration. Dedicated permission sets separate the person who runs a sync from the person who changes the credentials.

Settlement is where most marketplace integrations stop and where the finance team's pain actually is. The connector imports the Lazada settlement/transaction statement for a payout period, matches each line back to the originating order, and produces a draft general journal that splits gross sales, commission, payment fee, shipping subsidy, refunds and adjustments to the accounts and dimensions you specify — leaving a reconciling balance that should equal the bank line. You review and post it; the extension never posts a financial document unattended unless you explicitly turn that on. Unmatched lines are held on an exceptions page with the raw statement row attached, so a mismatch is investigable rather than mysterious.

This is a build-to-order product, not an AppSource download. After a short scoping call we confirm your Business Central version and deployment (SaaS online or on-premises), your Lazada seller regions, your item/SKU structure, the status map and your settlement chart-of-accounts treatment; then we build against your actual data. Typical delivery is one working week from confirmed scope. You get the AL source, an installable extension package built for your release wave, deployment into a sandbox for UAT, then production install with a rollback plan, training for the people who will live with it, and a post-go-live support window while the first real payout cycle runs through.