Webshop orders placed in Shopware post into Microsoft Dynamics 365 Business Central exactly once each, with a reference that makes a repeat attempt recognisable rather than a second posted invoice.
Every webshop eventually sends the same order twice. A payment callback retries, a queue is replayed, somebody reprocesses a batch after a failure, and Microsoft Dynamics 365 Business Central does what it is designed to do: it posts what it is given, through its number series, into the open period. Nothing looks wrong until a customer receives two invoices for one purchase. Connecting Shopware and Microsoft Dynamics 365 Business Central puts the order reference at the centre, so a second attempt is matched to the first instead of becoming another posted document.

A repeated Shopware order is recognised by its reference before it reaches Business Central, so a retry updates the existing document instead of creating a rival to it.
The hours spent keying webshop orders into Business Central come back, since each order arrives with its lines, customer and payment reference already resolved.
Item availability from Business Central reaches Shopware, so the storefront sells from the figure the ERP holds rather than from one that was accurate earlier this morning.
Shipment status posted in Business Central returns to the Shopware order, so a buyer checking their account sees progress without anybody answering an email about it.
A Shopware order is paid. Alumio creates the Microsoft Dynamics 365 Business Central document with its lines, customer and payment reference, and records the reference so a later retry resolves to the same document.
Item availability maintained in Microsoft Dynamics 365 Business Central publishes to Shopware as often as you choose, so the storefront stops selling stock the warehouse has already committed to somewhere else entirely.
A shipment posted in Business Central updates the matching Shopware order, so the customer sees dispatch and a tracking reference in their own account rather than waiting for somebody in the office to reply to a query.
Alumio sits between sales channels and fulfillment systems as a governed integration backbone. Orders are routed, transformed, and validated, while status updates return to every channel.
Authenticate your systems using Alumio's pre-built connectors. Choose from 200+ connector packages in the marketplace, plus unlimited custom integrations.
Define how data fields map between systems in a visual interface. Adjust formats, enrich records, and apply business logic, no custom code required.
Configure flows to run in real time on events, on a schedule, or both. Reduce manual data entry and let Alumio handle movement and transformation between systems.
Once your first integration is live, adding your ERP, PIM, WMS, or CRM connects to the same hub. Existing flows keep running. No rebuilding from scratch.
A payment service provider is the usual next connection, because orders post cleanly and settlement still arrives as a statement somebody reconciles by hand. Alumio holds those connections centrally and reuses the order reference already configured, so a payout line can be matched to the document it settles rather than to an amount that looks about right.
Yes, and the emphasis here is on posting each order exactly once. Alumio can act on the order event as it happens, checking the reference against what has already been sent, so a replayed message resolves to the existing Business Central document. Availability travels the other way on a schedule you control, which keeps repeated lookups off the ERP.
No. Alumio is config-first, so the route is assembled from reusable building blocks rather than written from scratch. Order references, tax codes and the Business Central dimensions each order posts against are configured once and reused, which is what makes a second sales channel an addition rather than a rebuild. Custom logic stays available through the Code Transformer.
The reference, checked before the document is created. Business Central posts what it receives through its number series, so it has no reason to refuse a second copy of an order it has already accepted, and it will not overwrite the first. Alumio therefore matches each incoming Shopware order against what it has already sent, so a retry becomes an update and never a duplicate invoice.
One order posted twice is the failure worth engineering against, because a missing order gets noticed and a duplicate gets invoiced. Alumio monitors each transfer in real time and logs the reference it used, so an order Business Central refuses alerts immediately with the reference and the reason. Retries run automatically where configured and resolve against the existing document, so nothing is silently duplicated or dropped.
Talk to an Alumio integration specialist. We'll map the right architecture for your systems, at the right scale, so your operations stay reliable through every change.