Integrating a CRM with an ERP and a store means every piece of data has one place where it is born, and travels by itself everywhere it is needed. A customer signs up in the store - and appears in the CRM as an opportunity and in the ERP as a business account with a tax ID. A sales rep changes a credit limit in the ERP - and the store immediately stops accepting orders above it. Nobody copied anything, nobody forgot.
This is not a one-plugin, one-afternoon project, but it does not have to take a year either. Below: what actually needs connecting, in what order, what the work costs and where it most often goes wrong.
Why connect these three systems at all
Because without integration the same fact gets typed in three times, and on the third someone gets it wrong. The classic symptom: a customer calls the sales rep, who looks at the CRM and sees “in fulfilment”, the warehouse in the ERP sees “awaiting payment”, and in the store the status still reads “new”. Three truths, each partly right, none defensible in front of the customer.
The practical consequences of no integration, costliest first:
- Selling what you do not have - store stock lags behind the warehouse and the order has to be cancelled
- Hours spent retyping - someone enters store orders into the warehouse system by hand every day
- Late invoices - and invoices go through KSeF anyway (Poland’s mandatory e-invoicing system: largest taxpayers from February 2026, everyone else from April 2026), so messy customer data hurts twice
- A blind CRM - the rep cannot see what the customer actually bought, so every call is a shot in the dark
- Price lists out of sync - individual discounts live in the ERP while the store shows list prices
Who owns what - splitting the roles
Before you connect anything, settle one thing: which data is born where. That is a business decision, not a technical one, and it decides whether the project succeeds. The rule: one piece of data, one owner - every other system only reads it.
| Data | Owner (born here) | Who reads it |
|---|---|---|
| Product record, index, base price | ERP | store, CRM |
| Stock level | ERP or WMS | store |
| Individual price list and customer discount | ERP | store, CRM |
| Customer order | store | ERP, CRM |
| Contact details and conversation history | CRM | - |
| Opportunity, stage, rep’s notes | CRM | - |
| Sales document, invoice, KSeF | ERP or accounting software | CRM (view only) |
| Credit limit and balance | ERP | store (order block) |
If any row in that table has two owners, you have a recipe for conflict. The most common sin is editing prices in the store and the ERP at the same time “because it is faster”.
Three ways to connect, and when each fits
You pick the method based on order volume and how unusual your commercial rules are. There is no single winner.
| Method | Who it fits | Strengths | Limits |
|---|---|---|---|
| Ready-made connector (ERP vendor plugin, cloud integrator) | standard B2C store, simple products | fastest start, a subscription instead of a project | works the way the vendor intended - you cannot bend the rules |
| Middle layer (n8n, Make, Zapier, Baselinker as a hub) | multi-channel stores, a few hundred orders a month | cheap to start, easy to add another channel | the more exceptions, the more fragile it gets |
| Custom API integration | B2B, own price lists, credit limits, unusual processes | does exactly what you need, and scales | more expensive upfront, needs deliberate maintenance |
In practice it usually ends up mixed: a ready-made connector for accounting and e-invoicing, plus custom B2B logic where the standard does not reach. How the costs break down for a trading platform aimed at business customers I cover separately in what a B2B platform costs, and connecting WooCommerce itself to a warehouse and accounting system I cover in WooCommerce, ERP and e-invoicing.
Systems with an API - and those without one
The key technical question is whether your ERP exposes an API or only files. That decides both pace and price.
- Full REST API (newer systems, cloud ERPs, Odoo, some international products) - the most comfortable case, data moves both ways close to real time
- Local API or a vendor add-on (Subiekt GT/nexo, Comarch ERP XL and Optima, enova365 - the ERP systems most Polish SMBs run on) - works well, but usually needs a service layer on the server and some thought about what happens when the office machine is switched off
- File exchange only (CSV, XML, EDI) - workable, but the sync is cyclical rather than instant; with stock levels you then keep a safety buffer
- No data exit at all - happens with old bespoke systems; at that point you genuinely weigh replacing the ERP or bolting an access layer onto it
If you run on Polish warehouse systems, the details of hooking them up to a store are in B2B platform on Subiekt, Comarch and enova.
Rollout order - what comes after what
The biggest mistake is starting with everything at once. The order below works because each stage delivers a measurable result on its own, and you can stop at any of them.
- Data map - you write out the table above: what is born where, what flows where, how often. An hour of conversation that can save weeks of rework
- One unambiguous identifier - a product needs a single index (SKU) shared by every system, a customer a single key (tax ID or the ERP number). Without that there is nothing to join on
- Products and stock one way - the ERP feeds the store. The simplest stage, and it sharply cuts down selling goods you do not have
- Orders the other way - the store sends the order into the ERP with the full set of invoicing data
- Customer prices and discounts - only now, because this is the most company-specific part of the logic
- Documents and e-invoicing - the invoice is created in the ERP or accounting software and goes to KSeF from there; the store and CRM only show its number and status
- CRM last - it receives a finished picture: who, what, for how much, at what stage. Plugging the CRM in before the data is tidy gives you a pretty panel full of rubbish
Between steps 3 and 4 it is worth pausing longer and checking whether the sync is lying to you - how to do that I described in the piece on inventory sync.
What it costs
The honest answer: it depends on the number of connections and how many exceptions your commercial model carries. The ranges below cover my work; third-party tool pricing changes often, so verify it with the vendor before deciding.
| Scope | What it covers | Ballpark |
|---|---|---|
| One direction (e.g. stock from ERP to store) | mapping, build, tests on production data | lower end of the project range |
| Full two-way store - ERP integration | products, stock, orders, documents, error handling | fixed-bid project, usually 5,000-10,000 PLN net |
| B2B layer (price lists, limits, customer portal) | commercial logic beyond store defaults | quoted separately, after the data map |
| Maintenance and watch duty | monitoring, reacting to API changes, fixes | technical care at 1,000 / 2,000 / 3,500 PLN net per month |
On top of that come vendor-side costs: an API module licence in the ERP, a middleware subscription, sometimes stronger hosting. Usually the smaller part of the bill, but it has to be counted upfront so there is no surprise in month three.
Five traps that cost the most
- No shared index - two systems holding the same product under different symbols is not integration, it is a lottery. SKU housekeeping happens before, not during
- Sync with no queue and no retries - when the ERP is briefly unavailable, an order must wait in a queue and go through later, not vanish
- Silence on failure - an integration that does not shout when something did not go through is worse than none, because it gives false confidence. I always build a notification for failed data exchange
- Testing on the live system - the first full sync can overwrite prices across the whole store. You run it on a copy, after hours, with a database backup
- Too much automation at the start - first two directions that work flawlessly, then more. Elaborate scenarios in tools like n8n or Zapier I go through in the piece on WooCommerce automation
How we usually start
I start with a free diagnosis: I look at what systems you have, what they expose, and where in your process data is retyped by hand today. The output is a data map - one table with owners and directions - plus a recommendation for which stage to run first so you feel the difference soonest.
For larger work you get a fixed bid in writing before we start, split into stages so you can stop after any of them. I run the project as part of growing and optimizing existing systems - I do not replace what already works for you, I connect it into a whole.
FAQ
Does a small company need CRM and ERP integration? At a dozen or so orders a month, usually not - retyping takes less effort than maintaining the integration. The break-even shows up when someone in the company has a standing job called “copy the orders across”, or when stock errors start. Then the integration pays for itself in working time, not in extra sales.
Can Baselinker replace ERP integration? It can act as the hub for orders from many channels, and it does that well. What it will not replace is B2B commercial logic: individual price lists, credit limits, payment terms. A common setup is Baselinker as the sales hub plus a separate, direct store-to-ERP connection for the B2B side - I went into that at more length in the piece on automation with the Baselinker API.
How long does integrating a CRM with an ERP and a store take? One direction of data exchange is usually a matter of working days. A full two-way connection with documents and price lists is weeks, and most of the time goes not on coding but on tidying data and testing. I give a deadline after seeing the systems, not before.
What happens when one of the systems stops responding? A well-built integration expects it: the order goes into a queue, gets retried, and you get a notification that something failed. The store keeps working, the customer notices nothing. If your current integration simply loses data during an outage, that is the first thing to fix, before adding anything new.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Tell me what is happening and you will get a concrete quote with a date.