Magento Business Central integration

What moves between Magento and Business Central

Business Central holds items, prices, stock and the books. Magento shows the catalog and takes the order. The integration connects six flows, each with a fixed direction and a fixed endpoint on both sides.

A Magento order has two numbers. entity_id is the number in every API path. increment_id is the number the customer sees, for example 000010482. The increment_id goes to externalDocumentNumber on the sales order, a field of 35 characters. The integration keeps the entity_id to post the shipment back later. The general setup is on e-commerce ERP integration.

Which system owns what

Salable quantity is the one row where Magento calculates and Business Central only supplies. Most stock differences in this pair start there.

What Magento and Business Central store differently

Item variants against configurable products

In Business Central a work jacket is one item with a number of at most 20 characters. Each color and size is an itemVariant with a code of at most 10 characters, for example BL-M. Color and size are not separate fields.

In Magento each variant is its own simple product with its own SKU, under a configurable product. Color and size are attributes with an option ID per value, and those IDs differ per installation. The integration reads them from your Magento and looks up the ID for BL. A color code that does not exist in Magento yet goes on a checklist.

Linking a child to its parent is one call per child: POST /V1/configurable-products/{sku}/child takes a single childSku. A jacket in 4 colors and 6 sizes is 24 variants. That is 24 simple products, 1 configurable product, 2 calls for the color and size options and 24 link calls: 51 requests for one style. A collection of 300 styles is 15,300 requests. The simple products go through the bulk endpoint; the link calls run from a queue. See variant mapping.

Attribute sets

Every Magento product needs an attribute_set_id. Business Central has no attribute sets, only an itemCategoryCode. The integration keeps a translation table: category WORKWEAR belongs to attribute set 9. An item in a category that is not in the table is held, not created under the default set.

Stock: one total against sources

The inventory property of a Business Central item is one read-only number across all locations. Magento works with sources and reservations: salable quantity is the sum of the sources minus open reservations, and a reservation clears only when the shipment exists in Magento.

The sum, as in the diagram: Business Central has 20. An order of 4 comes in, Magento reserves 4 and shows 16. The shipment is posted and Business Central drops to 16. If the integration writes 16 to the source before the shipment is in Magento, Magento calculates 16 minus 4 and shows 12. So the shipment is sent first and the stock after it. With more than one location, the quantity per location comes from a query published as an OData web service. See multi-location inventory and which stock counts.

Posting groups Magento does not know

A Business Central customer has a general business posting group, a VAT business posting group and a customer posting group; an item has a general product and an inventory posting group. Magento sends none of these, and the customers resource in the API has no fields for them. A template on the API Setup page fills empty fields when a customer is created. One template gives every web customer the same groups, so the integration picks the VAT group from country and VAT number on the billing address and sets it through a custom API page.

Addresses

Magento sends the street as an array of lines and the country as a two-letter country_id. Business Central has shipToAddressLine1 of 100 characters and shipToAddressLine2 of 50. An address with three or four street lines is joined, and the length is checked before the order is sent. More in address field mapping.

The technical reality of this pair

The two APIs are limited in opposite ways. Business Central online counts requests per user. For Magento on your own server, Adobe documents no general REST rate limit: the server is the limit, and an integration that reads too much at once slows the store.

Checked on October 3, 2026 in Microsoft's operational limits and Adobe's API security page. Magento's input limits, 20 items per synchronous request and 5,000 per asynchronous request, are off by default. Since 2.4.4 an integration token no longer works as a standalone bearer token.

Prices, worked through. 2,000 items, 3 customer price groups and 2 quantity breaks each is 12,000 tier prices. At 20 per synchronous request that is 600 requests. Through the asynchronous bulk route at 5,000 per request it is 3. Business Central delivers the same 12,000 price list lines in one page. After the first run only changed lines go.

The bulk route depends on a consumer. A bulk request returns a bulk_uuid at once and the work happens in the message queue. If the consumer async.operations.all is not running, every operation stays at status 4, open, without an error. The integration reads GET /V1/bulk/{uuid}/status after each batch and reports operations that stay open.

Business Central webhooks expire after three days and are renewed with the same handshake used to create them. Shipments have no webhook and no tracking field, so the integration reads posted shipments by date, takes the tracking number from a published page and sends track_number, title and carrier_code to Magento. Throughput for your own numbers: integration throughput.

Where standard connectors stop

Standard connectors and iPaaS templates for this pair describe their own limits.

• Their own extension in Business Central. The vendor installs an app that adds fields and endpoints. The mapping follows that extension, not your setup.
• Posting groups as one fixed value. The required groups are added to every order as a default. A second VAT regime or a group per channel does not fit.
• Customer match on email only. An unknown email creates a new customer, even when the company already exists under another address. See duplicate customers and orders.
• Split shipments. The documentation of such a connector warns of unexpected behavior with partial shipments.

Microsoft ships its own connector for Shopify, for Business Central online only. Microsoft's documentation lists none for Magento. A built integration has no fixed points: the attribute set table, the posting group rule and the customer match follow how your Business Central and your Magento are set up.

When it goes wrong

An order that keeps failing is stored with its original payload and sent again once the cause is fixed. Every attempt uses the increment_id as its key, so a retry does not create a second sales order. A reconciliation run compares recent Magento orders with externalDocumentNumber in Business Central and picks up anything a run missed.

Before go-live the integration runs as a dry run: it reads both sides and shows which products, prices and orders it would write, without writing. After that every run shows a diff per record. We host and monitor it and change it when Adobe or Microsoft changes an interface. The system side is on Business Central integration, the platform side on Magento integration, all flows on integrations. Sibling pages: Shopify Business Central integration, Magento NetSuite integration and Magento SAP integration. Tell us which Magento version and which Business Central you run.