Selling on Mirakl-powered marketplaces looks like one channel until you actually run it. Each operator — a retailer, a distributor, a B2B platform — runs its own Mirakl instance with its own API host, its own shop ID, its own category attribute set, its own acceptance window and its own transaction-log format. Dynamics 365 Business Central has no concept of any of it. Out of the box there is no offer entity, no per-operator price, no order acceptance lifecycle, and no place to land a Mirakl transaction log so a payout reconciles against posted sales invoices. Teams end up with a spreadsheet per operator, a person re-keying orders before the acceptance deadline lapses, and a finance close where marketplace commission and payouts are booked as one lump journal nobody can trace back to an order line.

We build a Business Central AL extension that treats Mirakl as a protocol rather than as one partner. A Mirakl Operator setup table holds base URL, credential reference, shop ID, currency and per-operator behaviour flags; every codeunit takes the operator code as a parameter, so adding a fifth marketplace is a setup record and an attribute mapping, not a second integration project. Offer publication maps Business Central items and variants to Mirakl offers — SKU, price, quantity, leadtime-to-ship, logistic class, state — plus per-operator category attributes held in a mapping table, so one item can carry different attribute values for different operators. Price and stock feeds run as separate, lighter jobs on their own Job Queue Entry cadence, because inventory moves far more often than catalog content does. Order import polls each operator for orders awaiting acceptance, creates a Business Central sales order (or sales invoice, per your flow) with the Mirakl order ID, shipping details and per-line commission carried on table extensions, and posts the acceptance back so the clock stops. Shipment confirmation and tracking flow outbound automatically through an event subscriber on the sales shipment posting codeunit — no manual second step.

The integration is written the way a maintainable BC app should be. HTTP calls sit behind a dedicated communication codeunit using HttpClient with retry and typed error surfacing, never scattered inline. Every operator exchange is written to a log table with a correlation id, payload excerpt and outcome, so a support question ends with a record instead of a guess. Long imports are batched and resumable, so a job queue timeout does not leave partial or duplicated state. Credentials live in isolated storage rather than plain setup fields. All new objects are gated by dedicated permission sets, and read models are exposed as API pages (REST API v2.0 / OData v4) so Power BI, Power Automate or a Dataverse virtual table can consume offer status, order backlog and settlement variance without anyone opening the ERP. The extension targets current Business Central release waves and ships as a per-tenant extension for SaaS, or as a deployable app for on-premises, matching your environment.

Settlement is the part most connectors skip, and the part your controller cares about. We import the operator transaction log into a Business Central settlement worksheet, match each line to the originating order and posted sales invoice, split gross order value from commission, marketplace fees, refunds and adjustments, and expose the unmatched residual as an exception list rather than burying it. A reconciled batch then generates the journal lines that clear the marketplace receivable against the actual bank payout, so each operator's payout ties back to document numbers you can open.

This is built to order, not downloaded. You request a quotation, we run a short scoping call to confirm which operators you sell through, your item and variant structure, which order flow you post to and what your settlement rules look like, and we quote fixed scope. Typical delivery is two to four weeks from confirmed scope: we build against your Business Central version, deploy to your sandbox for UAT using Mirakl staging credentials where the operator provides them, train your team, and go live with a rollback plan in hand. You receive the AL source, the git repository, documentation and a post-go-live support window.