Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Order lines and the discounts applied to them reach Microsoft Dynamics 365 Business Central separately, so a promotion shows up as a cost the business chose rather than as revenue it never earned.
A discounted webshop order is not a smaller sale, it is a sale plus a decision, and Microsoft Dynamics 365 Business Central posts through accounts that have to be told which is which. Without that split, a Lightspeed eCommerce order arrives net and the promotion disappears into lower revenue, so nobody can say what a campaign cost or which codes were worth repeating. The finance team knows the margin moved and cannot show why. Connecting Lightspeed eCommerce and Microsoft Dynamics 365 Business Central posts the gross line and the discount against the accounts each belongs to.
DATA THAT FLOWS BETWEEN THEM
Order lines
Discount codes
Gross line values
Shipping charges
Customer records
Posted invoices
The gross line and the discount reach Microsoft Dynamics 365 Business Central as separate postings, so a promotion reads as a decision rather than as revenue that never existed.
Discount codes travel with the order lines they applied to, so finance can tell which campaign a reduction belonged to without matching shop exports against a ledger by hand.
Shipping charged and shipping discounted are posted apart, so free delivery stops being invisible in the accounts and starts being a number somebody can decide to keep or stop.
Because the split happens before the ERP receives anything, Microsoft Dynamics 365 Business Central holds one version and no report has to work backwards from a net figure.
When a Lightspeed eCommerce order is placed, Alumio posts the gross lines and the discount separately into Microsoft Dynamics 365 Business Central, so the invoice matches what the customer paid and the accounts show the cost.
Discount codes arrive on the posted lines, so a Microsoft Dynamics 365 Business Central report can compare one campaign against another on actual margin rather than on the order counts the shop happened to report that week.
A shipping discount is posted to its own account rather than netted against the delivery charge, so the running cost of offering free delivery over a threshold is visible in Business Central instead of being spread across revenue.
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.
.svg){kind=icon}
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.
Money that went somewhere nobody booked is the thread worth following, and it usually leads to affiliate and partner payouts. A Lightspeed eCommerce discount is one cost of winning an order and a commission is another, and only one of them currently reaches Microsoft Dynamics 365 Business Central. Alumio holds that connection alongside this one, so the cost of an order arrives in one place rather than being assembled from a webshop report and a supplier invoice.
Which document each element becomes is what gets configured, and after that it posts without anybody splitting a figure by hand. Alumio reads Lightspeed eCommerce order lines, discounts and shipping charges and writes them into Microsoft Dynamics 365 Business Central as postings against the accounts you nominate for each. The invoice still shows the customer what they paid, because the split is an accounting treatment rather than a change to the order.
Mostly not, and it is worth naming the exception first. Where a discount is calculated across an order rather than sitting on a line, apportioning it back to lines is the one part configuration alone will not settle, and the Code Transformer takes that rule so the rest stays configuration. Everything else, which Lightspeed eCommerce field feeds which Dynamics 365 Business Central account, is set up in the interface.
The account you nominate for that kind of reduction, which is a decision worth making before the first order posts. Microsoft Dynamics 365 Business Central posts through account setup rather than inferring intent, so a discount arriving inside a net line simply becomes less revenue, while a discount posted separately stays a cost you can look at. Mapping each Lightspeed eCommerce discount type to its own account is what preserves the difference.
The line nobody can post is what stalls here, and it stalls loudly rather than quietly, which is the better failure. Each posting is watched live and the Lightspeed eCommerce order recorded with it, so an order Microsoft Dynamics 365 Business Central will not accept, usually a discount type nobody mapped to an account, surfaces at once and names the cause. Automatic retries run where configured, and unposted orders stay on the list, so nothing is invoiced on a guess and no order goes missing.
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.
.svg)
