The most common pain in 15-30 person companies with their own online store goes like this: twice a day a warehouse clerk exports stock from the ERP into a CSV, someone else uploads it into the store, and in between the store sells the last units of a product that physically left the shelf hours ago. The customer waits a week, gets a "sorry" email, charges back and never returns.
The problem isn't in the store and it isn't in the ERP. The problem is that both systems live in separate realities and update each other only when someone has time. In practice that means a 4-8 hour delay between a sale and a stock update — and most of the disasters happen inside that window.
Good news: in 2026 you don't need an enterprise ESB or a half-year project. You need three things: decide what your source of truth is, wire up three data streams, and leave yourself a fallback when things break.
Three streams that have to flow both ways
Any sensible store ↔ ERP sync boils down to three streams. The rest is decoration.
Stream 1: Stock levels — ERP to store. The source of truth is the ERP, because that's where units actually move down on warehouse releases, B2B sales and supplier returns. The store has to learn about every change within seconds, not hours.
Stream 2: Orders — store to ERP. When a customer clicks "buy", a document (a sales order, or directly a goods issue note) has to appear in the ERP so accounting can invoice and the warehouse has something to pack. Without it you end up with two parallel worlds: receipts in the store and invoices in the ERP that don't match at month end.
Stream 3: Product catalogue — ERP to store. A new product, a price change, a description edit — it all starts in the ERP and lands in the store. Why not the other way around? Because accounting, cash registers and B2B sales hang off the ERP. The online store is one channel, not the centre of the world.
Polling vs webhooks — and does it matter
A classic integration polls the store every 15 minutes for new orders and the ERP for stock changes. It works, but it has two flaws: latency and load. For 5 orders a day polling is fine. For 200 orders a day polling will either be inaccurate or it will hammer both systems.
Webhooks solve it: the store pushes "I have a new order", the ERP (or middleware sitting on top of it) pushes "SKU X stock changed". Data flies at the moment it changes. In practice most Polish ERPs (Comarch Optima, enova365, Subiekt GT) don't emit webhooks natively, so middleware takes that role — a small application sitting in between.
Such middleware is usually a few hundred lines of .NET or Node.js, hosted on a small VPS. It isn't a three-quarter project. It's a 4-8 week project, including testing and production rollout.
Concrete example: 15-person cosmetics maker
In one of our projects a 15-person natural cosmetics manufacturer sold in parallel through a Shoper store (B2C) and through Comarch Optima to wholesalers (B2B). The same SKU could be shown in the store as "12 in stock" while the wholesale team was just invoicing 20 units from the same warehouse.
The mechanics: twice a day a warehouse clerk exported stock into CSV, uploaded it into the Shoper backend, and in the meantime the world moved on. On average 14 orders a month ended with a "sorry, out of stock" email. Customers called angry, Google reviews slipped, customer service burned 6-8 hours a week on fire-fighting.
We deployed a .NET middleware that listens for Shoper webhooks (new order → reservation in Optima) and polls Optima every 60 seconds for stock changes (push to Shoper via API). Rollout: 5 weeks, cost under 30,000 PLN. After the first full month, cancellations due to "out of stock" dropped from 14 to 1 — and that one was a stocktake error, not an integration bug. The warehouse clerk reclaimed 8 hours a week that used to go on exports and apology emails.
Pitfalls that will catch you in the first quarter
Variants and sizes. The store often sees "men's shirt XL" as a single product, while the ERP treats it as a separate SKU. Without consistent variant mapping the stock sync will drift in week two and nobody will know where the bug is.
Returns. The customer returns a parcel. The store flips the order status to "returned", but nothing in the ERP automatically puts the stock back. You have to plan for this — either automated credit notes, or a deliberate decision that the warehouse does it manually (with a checklist).
Multi-warehouse. If you ship from three locations, the store has to show the sum of stock, but reservations must go to a specific warehouse. It isn't trivial — and it's the most common cause of "weird" bugs after the first month.
Promotional pricing. A promo in the store shouldn't write back to the ERP as a base price. You have to decide where the base price lives and where the promo rules live, and not mix the two layers.
Middleware downtime. An average VPS runs 99.9% of the time — that's about 8 hours of downtime a year. You need event queueing (RabbitMQ, Redis, anything) and a sensible "replay everything that flew by while the server was down" mechanism. Otherwise you just lose data on the day it crashes.
What to do this Monday
Before you even start talking to an integrator, do three things:
- Count how many orders were cancelled last month due to "out of stock". Multiply by your average margin and by 12. That's your annual loss from missing sync.
- Measure how many hours a week your team spends on manual exports and imports between store and ERP. Multiply by hourly rate and by 50. That's the second cost.
- Ask your ERP vendor (Comarch, Insert, Soneta) whether they ship a stock connector for your storefront and what exactly it covers. In most cases the "out of the box connector" covers 70-80% of needs and leaves 2-3 gaps to fill with middleware.
If after these three steps you see you're losing tens of thousands of zlotys a year and a full-time job's worth of CSV-shuffling — this is a project that pays back in one quarter. Most companies that come to us with this problem stall not because they don't see the point, but because they don't know which specific step to start with.
Store–ERP sync isn't an IT project. It's a way to stop losing customers for a stupid reason.