ERP for ecommerce — integrating ERP, WMS and CRM without data chaos

Most of the chaos in ERP for ecommerce integration doesn't come from missing technology — it comes from never agreeing on one simple answer: which system is the source of truth for this field. If a price lives in both the ERP and the store at once, and either version can change independently, the two will eventually disagree. This article separates ERP, WMS and CRM as three different data owners, looks at what the ERP vendors used in Switzerland actually offer for store integration, and lays out three integration architectures you can choose between before writing a single line of integration code.

ERP, WMS, CRM — what each one actually does

ERP (Enterprise Resource Planning) is where prices, sales documents (invoices) and usually a basic customer record live. In a small or mid-size business, this system often predates the online store, because accounting and offline sales needed it regardless of ecommerce.

WMS (Warehouse Management System) covers what's actually happening in the warehouse, not just a single "in stock" count — pick, pack and dispatch workflows, storage locations, and stock movements across more than one zone or site. In practice a WMS earns its own system once a warehouse has more than one storage zone or location, or once SKU count and turnover make manual stock counts unreliable.

CRM (Customer Relationship Management) is where the history of contact with a customer lives — marketing consent, segmentation — not the transaction itself (that's the ERP's job), but the relationship around it. In a small store this function often sits inside the ERP itself, or in the store platform's own customer record; a dedicated CRM appears once support and marketing need a wider view than "order history" alone — recording which marketing consents a customer gave and when, for instance, or segmenting customers by purchase behaviour rather than by a plain transaction list.

Three systems, three owners — but that doesn't mean you need three separate licences from three different vendors. Several mid-market ERP suites (see below) bundle a WMS module or a CRM module into the same licence; whether you use the bundled module or a dedicated, separate system depends on whether the bundled module actually covers your scale, not on the option simply existing.

None of the three has to exist in a full, separate form from day one — but every field you synchronise between the store and the rest of your stack (stock, price, customer record) needs one owner, even if that owner is temporarily the ERP doing all three jobs at once.

In practice, the smallest businesses run all three roles out of the ERP alone — stock counted manually in the ERP's own warehouse module, the customer record as a plain contact in the same system. That isn't a design flaw by itself; it only becomes a problem once scale outgrows what one system can sensibly handle (hundreds of SKUs across several locations, thousands of contacts with an interaction history wider than orders alone) — and that's the point where adding a dedicated WMS or CRM makes sense, rather than being bought "just in case."

ERP for ecommerce — the vendor landscape in Switzerland

Among the mid-market ERP systems on offer in Switzerland you will find the same international names as elsewhere in Europe — Odoo (a Belgian vendor), SAP Business One, Microsoft Dynamics 365 Business Central and Sage — alongside Swiss-developed products. They take noticeably different routes to the online store, and that difference matters more than the logo.

• Odoo publishes its price list per user, and its pricing page states that the Standard and Custom plans "include all apps for a single fee" — eCommerce and Website among them. The shop can therefore live inside the ERP itself. We did not verify the CHF price shown to Swiss customers, so check it on Odoo's page for your account.
• Business Central is typically sold through a Microsoft partner. For the store side, Microsoft ships its own Shopify Connector app, which its documentation describes as "preinstalled for all new sign-ups and trials" — a native connector to one specific platform, not to every platform.
• SAP Business One and Sage's mid-market products are sold mainly through partner networks. We did not find a public price for an ecommerce integration on either vendor's pages, so the cost of that piece only becomes clear in a partner's quote.

The reusable lesson isn't a figure: the headline licence price of an ERP tells you little about what the store integration will cost. Whether it is built in (Odoo), shipped as a connector for one platform (Business Central with Shopify) or delivered by a partner project changes the bill far more than the licence line does. Warehouse (WMS) and CRM functions follow the same pattern — bundled in the suite or sold as add-ons depending on vendor and tier — so confirm what applies to your case before assuming a feature is "included."

The data contract — who's the source of truth for what

Before you pick an integration technology, answer the simpler question first: for every field that lives in more than one system, which system wins when the two versions disagree. That's the "data contract" — not a legal document, just the agreement you go back to at every dispute.

If stock level has two owners at once (WMS and ERP updated independently), you don't have a data contract — you have two sources that will drift apart at the next manual correction in either one. The fix isn't technical, it's a decision: pick one system as the owner of that field, and let the other one only read it.

The concrete mechanism behind that drift: a warehouse worker makes a manual stock correction in the WMS after a stocktake, but the integration only syncs stock one way (from ERP to WMS, not back) — the WMS shows the corrected figure locally, while the ERP and the store keep showing the old number until the next sync overwrites the correction again. From the outside it looks like "the integration broke," even though neither system has a bug — the direction of data flow simply was never agreed as a single, explicit rule.

Rollout order — what to connect first

The typical path for a small or mid-size business looks like this: the ERP exists first, because accounting and sales needed it regardless of whether an online store ever launched. The first integration is usually a store↔ERP connector — prices and basic orders, exactly the ground covered, from the supplier's own side, in our article on supplier-feed integration. A WMS comes later, once SKU count, turnover or a second warehouse location make manual stock tracking in the ERP alone unreliable — that's the point where it's worth separating "stock" out of the ERP into a dedicated system. CRM comes last, once support and marketing need a view of the relationship wider than the ERP's own transaction history.

Reversing that order — implementing a CRM, say, before sorting out the source of truth for price and stock — usually just means the new system inherits the mess from the old ones, in a new interface. The mechanism is simple: a CRM fed customer data from two inconsistent sources (ERP and the store's own panel, updated independently) has two versions of the same contact from day one — which is the problem CRM was supposed to solve, not one it creates for itself.

Integration architecture — connector, iPaaS or your own API

You have three routes, and each makes sense at a different scale:

• Native connector — a ready-made integration between the ERP and a specific store platform, built by the ERP vendor or one of its partners. The lowest deployment cost, but limited to what the vendor built in — if your process needs a field the connector doesn't handle, there's nowhere to add it.
• iPaaS (Integration Platform as a Service) — a middleware layer between systems instead of point-to-point integration. This is an architectural option, not a specific tool — the specific tools in this category and their pricing are a separate topic in our article on ecommerce automation, because that's where they actually belong: event-driven flows and time saved, not data architecture.
• Your own API — a dedicated integration built for your own stack, using whatever integration layer the ERP vendor provides, or a fully separate service built around event queues. The highest build cost, but the only route if the data contract needs logic no off-the-shelf connector anticipated (unusual B2B pricing rules, say, or multi-warehouse stock allocation).

The signal that it's worth moving from one architecture to the next usually isn't "how much does this cost," it's "how many times a month are we working around the connector's limits by hand." If a manual fix (export to a spreadsheet, correct it, import it back) keeps recurring for the same problem, that's the signal a native connector has stopped being enough — independently of whether a formal integration budget already exists.

Which option pays off at your order volume and number of integrated systems is something you can work out in our ecommerce TCO calculator — the cost of a native connector and the cost of your own API spread out very differently over time.

Swiss invoicing — the QR-bill, and why the EU's ViDA framework doesn't apply

Switzerland isn't an EU or EEA member state, and EU directives bind only member states — so the EU's harmonised e-invoicing framework, ViDA (Council Directive (EU) 2025/516), does not govern invoices a Swiss business issues under Swiss VAT. Its dates (cross-border digital reporting from 1 July 2030, alignment of existing domestic systems by 1 January 2035) bind EU member states; if you sell B2B into the EU, your EU customers' own national rules may still shape what they ask your ERP to send.

What Switzerland does have is a structured-payment-reference standard: the SIX QR-bill, which has been "in circulation since June 2020" and "definitively replaced Swiss payment slips on 1 October 2022," with new requirements applying since 22 November 2025. That's a payment-reference standard, not a B2B e-invoicing mandate of the kind several EU member states run — it standardises how payment data is encoded and read on a bill, not whether the invoice itself has to be issued in a particular structured electronic format or reported to a tax authority. We found no general Swiss B2B e-invoicing mandate during this research; treat that as the current state rather than a permanent guarantee, and re-check before relying on it for a new build. For the ERP, the November 2025 change is the practical one: the QR-bill guidelines in force since then introduce structured addresses, which split an address into separate elements — easiest to produce when the customer master data already stores street, house number, postcode and town as separate fields rather than as free text.

The practical consequence for the data contract above is unchanged by this difference: whichever invoicing standard applies, the ERP issuing the invoice needs complete, correct customer master data — address, any applicable VAT reference — at the moment of issue, not corrected afterwards in another system. Switzerland's standard VAT rate is 8.1% (Federal Tax Administration, read 2026-10-01) — relevant if your ERP's invoice template has to show the rate correctly, though the data-contract point holds regardless of the rate itself.

How integrations fit into the rest of ecommerce operations — product data, KPIs, automation, security — is covered in our ecommerce operations section.