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 Poland 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 Polish vendor landscape

The Polish ERP names that come up most often around an online store are InsERT's Subiekt, Comarch ERP (Optima, XL), enova365 and Symfonia. They take noticeably different routes to the store, and that difference matters more than the logo.

InsERT. Subiekt GT has a dedicated integration layer, Sfera, described as a "mechanism that makes it possible to write extensions using the internal algorithms of Subiekt GT", built on COM and OLE Automation; among its example uses InsERT names "handling orders placed in an online shop" (insert.com.pl, Subiekt GT Sfera, read 2026-10-05). InsERT sells it as a separate variant, Subiekt GT Sfera, for PLN 2,090 net, against PLN 1,045 net for Subiekt GT alone (product pages, read 2026-10-05). In the newer generation the equivalent sits only in the higher edition: "Sfera for Subiekt nexo" is listed among the solutions "available in the PRO version", with technical documentation in nexo SDK (insert.com.pl, Subiekt nexo PRO, read 2026-10-01); the product pages give no nexo prices. InsERT describes Subiekt 123 as a system "without warehouse management" and does not list Sfera for it. If you want to base the store integration on Sfera, look for it in Subiekt GT Sfera or Subiekt nexo PRO, not in Subiekt 123.

Comarch. According to the vendor, Comarch e-Sklep is "a solution fully integrated with ERP-class systems", and its price list names integration with Comarch ERP Betterfly, Optima, XL and Altum (comarchesklep.pl and comarchesklep.pl/cennik, read 2026-10-05). ERP integration is only one layer here: the platform also declares over 30 payment integrations (including Comarch Pay, PayU, BLIK, Przelewy24, PayPal), shipping integrations (including InPost Paczkomaty, DHL, UPS), a free integration with Allegro and abandoned-cart reminders. For the warehouse, Comarch ERP XL has a separate module, Comarch WMS Magazynier (comarch.pl, read 2026-10-01). The e-Sklep prices are public — the Standard package "from PLN 150/month", Enterprise from PLN 599, B2B from PLN 899 a month (the price list does not say whether these are net). The product pages give no Comarch WMS prices; the same model — a quote through an implementation partner — repeats with enova365.

enova365. It integrates natively with "Allegro, Shoper, PrestaShop, Magento, WooCommerce and Base" and names specific functions: automatic download of orders from online shops, automatic update of stock levels in the shops, automatic creation of customer records, updates of order statuses in the shop, sending waybill numbers to customers and scheduled synchronisation (enova.pl, read 2026-10-01). The vendor does not publish a price for the integration module — the page leads to a form asking for a demo or a quote.

Symfonia. The Symfonia Handel e-commerce integrator is said to support "two-way data exchange" of orders, product and stock data in real time, payment data and automatic invoice generation, and communicates "via API (broker)" (symfonia.pl, read 2026-10-01). The page names neither the supported store platforms nor a price.

WMS as a SaaS service with a public price. Unlike WMS systems sold through partners without a published price, Sellasist, a Polish order integrator, publishes the prices of its warehouse modules. Mini WMS (picking and packing modes in the app) is a "paid add-on: PLN 50 net per user / month", and the full Sellasist WMS with locations and virtual shelves is "from PLN 199 per user / month"; implementation is run only by Sellasist specialists or certified implementers (sellasist.pl/cennik, read 2026-10-05). It is a reference point when comparing WMS cost, not proof that such a module replaces a dedicated system in a large warehouse.

The reusable lesson isn't a figure: the headline price of an ERP tells you little about what the store integration will cost. Whether it is a separate integration layer (Sfera), a store sold as part of the ERP family (Comarch e-Sklep), a native connector list (enova365) or 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.

How to write the data contract before integrating

A data contract fits on a single spreadsheet, as long as it answers the same questions for every field. You don't need a contractor or a tool for this — just someone who knows how goods and documents move through the company.

1. List the fields that exist in more than one system — stock, price (split into the base price list and promotions), the customer record, order status, tracking number, documents.
2. Give each field one owner — the system in which it may be changed. Every other system only reads it.
3. Set the direction and timing of each sync — from which system to which, and when: on every change, on a schedule or on demand. The example in the previous section shows what happens when the direction is never agreed.
4. Write down the conflict rule — what the integration does when the versions differ: overwrite with the owner's data, hold the order, or flag the problem to a person.
5. Name the person who is told about sync errors — without that, a mismatch only comes to light in a customer complaint.

That spreadsheet is also the best brief for whoever builds the integration: instead of "connect the store to our ERP", they get a list of fields, directions and rules they can actually price.

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.

KSeF — what changes in the flow of documents

Since 2026 a B2B invoice from your ERP is no longer just a PDF — it goes through the National e-Invoicing System (Krajowy System e-Faktur, KSeF). The obligation came in stages: "from 1 February 2026 for companies whose 2024 sales exceeded PLN 200 million (with VAT), from 1 April 2026 for the rest", with a transition period — "until 31 December 2026 you can still issue invoices outside KSeF (paper or electronic) if the sum of sales with VAT on such invoices in a given month does not exceed PLN 10,000" (ksef.podatki.gov.pl, read 2026-10-05). In an online store this mainly concerns B2B sales (business buyers, wholesale, a marketplace as a counterparty). Invoices to consumers (B2C) stay voluntary in KSeF, "both before and after 1 February 2026", and invoices from cash registers (including receipts with a tax ID up to PLN 450) may stay outside KSeF until 31 December 2026 (ksef.podatki.gov.pl, read 2026-10-05). Both obligation dates have already passed. If your ERP issues B2B invoices for store orders and the integration has not accounted for that so far, check that the path to KSeF works — before the transition exceptions end on 31 December 2026.

For the data contract this means one thing: if a B2B invoice goes through KSeF, the ERP as the issuer must have complete, correct customer data (tax ID, address) at the moment of issue, not corrected afterwards in another system. KSeF is not a place where a mistake in the customer record can be quietly fixed the way it can in a PDF sent by email.

The EU layer sits behind this as background. Council Directive (EU) 2025/516 — ViDA — entered into force on 14 April 2025; from 1 July 2030 digital reporting applies to cross-border B2B transactions, and member states that already run a domestic real-time system have until 1 January 2035 to align it with the EU model. If you sell B2B to other EU countries, check the e-invoicing rules of the country where the invoice is issued or received, and note that a common route for exchanging e-invoices between businesses in different member states is Peppol, which works on a four-corner model: buyers and suppliers connect through any Peppol-accredited service provider, regardless of which ERP either side runs.

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