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 2-4 weeks 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.