E-commerce works when the back-office works. Yet nearly every project we inherit has the same disease: WooCommerce on one side, ERP on the other, and an Excel sheet shuttling between them by email. Here are the integration patterns we actually use, not the ones from sales decks.
The four flows that need integration
- Product catalogue: from ERP (Mexal, TeamSystem, Zucchetti, Danea, Mago) to WooCommerce.
- Stock levels: ERP to WooCommerce in real-time or near-real-time.
- Orders: WooCommerce to ERP, with full customer and billing data.
- Order status and tracking: ERP and couriers to WooCommerce and to the customer.
Pattern 1: dedicated Node.js middleware
For most of our projects the answer is a Node.js service (TypeScript + Prisma) acting as a hub: reads from ERP (via scheduled CSV exports, direct SQL queries or APIs), transforms and writes to WooCommerce via REST API. More upfront work, but the only way to handle complex catalogues, size/colour variants and multi-tier pricing.
Typical stack:
- Job scheduler (cron, BullMQ) for periodic sync.
- WooCommerce webhooks for real-time orders.
- Mapping table between ERP SKU and WooCommerce ID.
- Structured JSON logs and a monitoring dashboard.
- Exponential backoff retries and a DLQ for unrecoverable errors.
Pattern 2: off-the-shelf "all-in-one" plugins
There are plugins that claim to sync with ERP X or Y. They work — until they do not. Recurring issues we see:
- Mappings non-customisable past a point.
- Plugin updates breaking sync without warning.
- Vendor lock-in: if the publisher disappears or drops support, you are stuck.
We propose them only when the client is genuinely standard: one warehouse, one price list, one channel, tight budget.
Pattern 3: ERP already "headless"
Some modern ERPs expose decent REST APIs. In that case the middleware shrinks and can sometimes be replaced by an n8n or Make workflow. Works fine up to 50-100 orders/day; above that you need something sturdier.
Italian-specific traps
- E-invoicing (Fatturazione Elettronica): the ERP is the source of truth, WooCommerce is not. Invoices must originate from the ERP, never from the site.
- VAT on mixed goods: food, books and other items with different rates. Sync must carry the correct rate, not just the price.
- Duplicate barcodes and SKUs: exist in the ERP for historical reasons. Disambiguate before syncing, not after.
- Promotions: ERP thinks in tiered price lists and rules; WooCommerce thinks in coupons and categories. Translation is a project of its own.
The closing advice
Before you integrate, simplify. Three out of four projects we inherit have a catalogue that could be 30% smaller and a price list that could be halved. The best integration is the one you do not have to build.