Still importing orders as CSV? How webshop-ERP integration actually works

An uncomfortable amount of Nordic e-commerce still moves order data by hand: export a CSV from the webshop, import it into the ERP, fix the rows that didn't map. This article covers why that routine became the default, why custom-built integrations didn't replace it, and what actually happens under the hood when middleware takes over.

The CSV routine

The workflow looks the same in most shops that run it. Orders accumulate in the webshop — Shopify, WooCommerce, Centra. Bookkeeping and stock live in the ERP — Fortnox, Visma, Business Central. Between them sits a person: export orders as a CSV file, import it into the ERP, and manually correct whatever didn't map — VAT rates that landed wrong, customers that got duplicated, payment methods the import didn't recognize.

At five orders a day, this is a coffee-break task. At fifty, it's a daily routine someone has to own. Research from Politecnico di Milano's Digital Innovation Observatory (2025) found that while 78% of European SMBs run management software, only about a third have integrated it with their online sales channels — and the disconnected majority spend 4-6 hours per week on manual data entry, with a 3-5% error rate that shows up as incorrect invoices and wrong stock levels.

The errors are the expensive part. A mistyped VAT rate isn't visible until reconciliation. A duplicated customer record pollutes the register permanently. And every hour spent on the import routine is an hour not spent on the shop.

Why manual won by default

The CSV routine didn't survive because nobody thought of automating it. It survived because the alternative — a custom-built integration — historically lost on three counts:

Time. A bespoke integration between one webshop and one ERP took months to specify, build, and test. Most merchants needed the orders flowing this week.

Fragility. Both the webshop and the ERP evolve their APIs continuously. A custom integration is code that one consultant wrote for one company — when either API changes, it breaks, and the person who built it may no longer be around.

Cost asymmetry. The build cost the same whether you processed 10 orders a day or 1,000. For SMBs, the math rarely closed.

So the manual routine won — not because it was good, but because it was the only option that started today and never sent an invoice.

What middleware changes

Middleware — an integration platform sitting between the systems — inverts all three problems. The integration already exists; you configure it instead of building it. And because the same connector serves every merchant on the platform, API changes are handled once, centrally, instead of per company.

Here's the actual flow when an order is placed:

1. The webhook fires. The webshop notifies the integration layer the moment an order is created or captured — no polling, no schedule, no export button.

2. The payload is transformed. The order data is mapped to the ERP's schema: line items with the correct VAT rates, the payment method translated to the ERP's terms, shipping as its own line where the ERP expects it.

3. The customer is matched, not duplicated. The integration checks whether the customer already exists in the ERP and links the order to the existing record — or creates one if it's genuinely new. No more three versions of the same customer.

4. The order is posted through the API and exists in the ERP seconds after it existed in the webshop — as an order or a finished invoice, depending on configuration.

Data flows the other way, too. Stock levels, where the ERP is the source of truth, sync back to the webshop on a schedule — every five minutes by default — so the shop shows what the warehouse actually holds.

Beyond orders

Order sync is where most merchants start, because it's the most visible pain. But the same layer typically handles the surrounding flows:

• Stock levels — ERP to webshop, so campaigns don't oversell what isn't there.

• Payouts — payment provider reports fetched and matched to invoices, fees and refunds booked where they belong, so the lump sum on the bank statement reconciles against the ERP.

• Refunds — credit invoices created automatically when a refund is issued in the shop.

• Product data and order statuses — depending on which system owns which truth.

Each flow is a toggle, with a direction. Which flows make sense — and which direction they run — depends on the systems and how the business works. That's a configuration conversation, not a development project.

What this means in practice

The honest summary: the CSV routine is a solved problem. Not by heroic custom development, but by the same economics that made SaaS win everywhere else — one integration, built once, maintained centrally, configured per merchant.

If you're running the export-import-fix routine today, the first question isn't "should we integrate" — it's "is our combination of systems already supported." For the systems named in this article and a few hundred other combinations, the answer is usually yes.