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 active in the EU 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 EU vendor landscape

Four mid-market ERP names come up again and again across the EU: Odoo (a Belgian vendor), SAP Business One, Microsoft Dynamics 365 Business Central and Sage. They take noticeably different routes to the online store, and that difference matters more than the logo.

• Odoo is the one with a fully public price list. Its Standard and Custom plans are priced per user, and the pricing page states that they "include all apps for a single fee" — eCommerce and Website among them. In other words, the shop can live inside the ERP itself, which removes the store↔ERP sync for the fields Odoo owns, but ties the storefront to Odoo's own front end.
• Business Central publishes per-user prices on Microsoft's site, while the sale itself typically runs 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 own pages, so the cost of that piece only becomes clear in a partner's quote.

The reusable lesson isn't a figure: the headline per-user 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.

EU e-invoicing and the ViDA framework

The EU's harmonised e-invoicing framework is changing which document in the data-contract table above stops being "just a PDF from the ERP." Council Directive (EU) 2025/516 — ViDA — entered into force on 14 April 2025. Its new wording of Article 218 of the VAT Directive, which applies from 1 July 2030, says that "invoices shall be issued as electronic invoices", and that those invoices must follow the European standard on electronic invoicing under Directive 2014/55/EU — EN 16931, the structured-data standard originally built for invoicing public authorities. Member states may still accept paper or other formats for transactions that fall outside the new reporting obligations.

The timeline is slower than that sentence suggests. Digital reporting for cross-border B2B transactions applies from 1 July 2030, and member states that already run a domestic real-time reporting system have until 1 January 2035 to align it with the EU model. There is no single EU-wide domestic e-invoicing mandate on one timetable: member states run their own domestic mandates on their own schedules — Italy's SdI is already in force; in France every business must be able to receive e-invoices from 1 September 2026, while small and medium-sized firms have to start issuing them from 1 September 2027; Poland runs its own KSeF system. ViDA harmonises the cross-border layer from 2030 and pulls the existing domestic systems towards one model by 2035.

For a store selling B2B across the EU, two things follow. First, check whether the member state where your invoice is issued already runs its own domestic e-invoicing mandate — the rules and deadlines differ by country, so this needs a local check, not an EU-wide answer — and if it does, your ERP's output has to satisfy that local format now, not in 2030. Second, a common route for exchanging e-invoices between businesses in different member states is Peppol, the interoperability framework that "began in 2008 as a large-scale pilot financed by the European Commission and Consortium members" and works on a four-corner model: buyers and suppliers connect through any Peppol-accredited service provider, regardless of which ERP either side runs.

The practical consequence for the data contract above: whichever document flow applies in your member state, the ERP issuing the invoice needs complete, correct customer master data — VAT ID, address — at the moment of issue, not corrected afterwards in another system. A structured e-invoice isn't a place where a mistake in the customer record quietly gets fixed the way it might in an emailed PDF.

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