Introducing the Alumio Route Builder
Now connect, orchestrate, and govern integrations at scale from one visual interface
Webshop sales from WooCommerce post into Exact Online with a tax treatment the ledger will accept, so orders stop stacking up unposted while somebody works out what was wrong with them.
Exact Online is strict about tax, and it is right to be. Every sales line needs a tax treatment it recognises, and if one does not arrive the entry is refused rather than posted with a guess. A webshop, meanwhile, applies rates by country and product type and does not much care what the ledger happens to call them. Left unmapped, orders pile up unposted while the shop shows everything as perfectly fine. The WooCommerce to Exact Online integration settles that translation once, so sales post as they happen and a month with no refused entries becomes normal.
DATA THAT FLOWS BETWEEN THEM
Orders
Order lines
Tax treatment
Customers
Payments
Credit notes
Each order arrives with a tax treatment Exact Online recognises, so entries go through as they happen rather than collecting in a queue nobody looks at until the month end.
Webshop sales reach the ledger with their customer, lines and totals already in place, so the hours spent copying orders across come back to whoever was doing that job.
A refund in the shop becomes a credit note in Exact Online, so reported sales reflect what the business actually kept rather than what it happened to take at the checkout.
Because orders post as they are paid, the figures the business looks at are a day or two old at most, which is what makes a question worth asking mid-month at all.
An order is paid in WooCommerce and Alumio creates the entry in Exact Online with the right tax treatment on each line, so the sale is in the books the same day without anybody keying it in again at the end of the week.
A refund in the webshop produces the matching credit note in Exact Online, so the customer's balance and the reported revenue are both correct without a correction made by hand weeks afterwards by whoever happens to spot it.
A shop starts selling abroad and the new rates map to treatments Exact Online accepts, so expansion does not mean a month of refused entries and a bookkeeper working out what each one of them should have been in the first place.
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.
A payment reminder tool is a frequent addition, because once invoices land in the ledger promptly the next job is chasing the ones nobody paid. Adding it means drawing on the customer matching rather than building a second version of it, so a reminder goes to the right person about the right invoice rather than off a list somebody exported last week.
Yes, and the tax translation is what makes it work. Alumio maps each shop rate to the treatment Exact Online expects, so an entry arrives complete rather than being refused for something the shop never knew it needed. Refunds follow as credit notes, and anything that cannot be mapped is held and flagged rather than posted on a guess.
No, and the test of that is what happens when you add a second shop. With this set up in a form, another storefront reuses the same tax mapping and the same customer rules, so it is an afternoon rather than a project. A hand-built script would mean doing the work twice and maintaining both. The Code Transformer covers genuine one-offs.
Neither, strictly. The shop applies a rate and the ledger recognises a treatment, and those are two different vocabularies for the same thing. What matters is that every rate the shop can apply has somewhere to land in Exact Online, agreed once, so a new country or product type is a mapping decision made deliberately rather than a run of refused entries discovered at the close.
An order sitting unposted while the shop shows it as complete is the failure that catches people out, because nothing looks wrong until the month will not close. Alumio detects a refusal as it happens and logs the entry it had built, then notifies somebody with the reason, usually a treatment that could not be matched. Retries run where configured, so nothing is quietly missing from the books.
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)
