Microsoft Dynamics 365 Business Central and Amazon Seller Central integration

What moves between them

The main flow runs from Amazon Seller Central into Microsoft Dynamics 365 Business Central. ml-connector reads Amazon orders and the financial events and settlement reports behind them, then posts sales into Business Central as sales invoices and posts the marketplace fees, refunds, and adjustments as general ledger entries, each mapped to the matching Business Central item, customer, and GL account. Catalog and SKU references are aligned so every order line resolves to a real Business Central item number. The general ledger is read-only on the Business Central API and Amazon is treated as a read source for accounting, so ml-connector never writes ledger entries back to Amazon. Polling cadence follows your settlement and order schedule.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Amazon side it exchanges the Login with Amazon refresh token for an access token, caches it for its one-hour life, and refreshes before expiry, sending the access token and marketplace ID on every call and routing to the correct regional base URL. On the Business Central side it requests an Entra ID client-credentials token for the api.businesscentral.dynamics.com scope and builds the base URL from the stored environment name and company ID. Because Amazon settlement is async and offers no plain HTTP webhook or settlement notification type, finance data is polled: orders are read incrementally by LastUpdateDate, and the settlement report is fetched through the create-report, poll, download pattern, with the settlement report treated as the authoritative disbursement record over event-level finance data. Items and customers are mapped first so each posted line lands on a valid item and GL account. Neither API has a universal idempotency key, so ml-connector dedupes on the AmazonOrderId and settlement ID with a BullMQ jobId before posting, and checks Business Central by OData filter on the number field to avoid double-booking a re-read order. Buyer name, address, and phone are restricted on Amazon and require a Restricted Data Token, so the connector only requests those fields when a flow actually needs them. Rate-limit 429s on either side trigger exponential backoff with jitter, and every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods brand sells about fifteen hundred orders a week on Amazon and runs Microsoft Dynamics 365 Business Central for inventory and finance. Before the integration, an accountant downloaded the Amazon settlement report every two weeks and keyed the gross sales, referral fees, FBA fees, and refunds into Business Central by hand, then spent the first days of month-end close trying to make the Amazon payout match the sales it was supposed to cover. With Microsoft Dynamics 365 Business Central and Amazon Seller Central connected, each order posts as a sales invoice and each settlement posts its fees and refunds to the right GL accounts automatically, so the deposit ties out to the orders behind it. The manual re-keying is gone and close starts from reconciled numbers.

What you can do

• •Post Amazon Seller Central orders into Microsoft Dynamics 365 Business Central as sales invoices.
• •Record Amazon settlement fees, refunds, and adjustments as Business Central general ledger entries against the right accounts.
• •Keep Business Central item numbers aligned with Amazon SKUs so every order line lands on a real item.
• •Bridge Login with Amazon refresh tokens and the Business Central Entra ID client credentials grant.
• •Poll orders and settlement reports on a schedule with jobId dedup, backoff on 429, and a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and Amazon Seller Central?

The main flow is Amazon Seller Central into Business Central. Orders post as sales invoices and settlement fees, refunds, and adjustments post as general ledger entries, while SKU and item references are aligned so order lines resolve to real items. The Business Central general ledger is read-only on the API and Amazon is treated as a read source for accounting, so ml-connector never writes ledger entries back into Amazon.

Does Amazon push orders, or does ml-connector poll for them?

ml-connector polls. The Selling Partner API delivers push events only through AWS EventBridge or SQS, with no plain HTTP webhook and no notification type for financial settlement. Orders are read incrementally by LastUpdateDate and the settlement report is fetched through the create-report, poll, then download pattern on the schedule you set.

Why use the Amazon settlement report instead of the order total for accounting?

Amazon settlement is async and the settlement report is the authoritative record of what was actually disbursed, including referral and FBA fees, refunds, and adjustments that an order total alone does not show. ml-connector posts these to the matching Business Central GL accounts so the payout reconciles against the orders behind it. The Finances API gives event-level detail sooner, but the settlement report remains the canonical disbursement source.