Every serious B2B WooCommerce project eventually hits the ERP question: orders in WooCommerce, stock and customers in an ERP (SAP Business One, Dynamics 365, Odoo, NetSuite, or a legacy system). The integration quotes we see range from $2,000 to $60,000 for what sounds like the same job. The difference is scope discipline. Here is how the three patterns actually differ.
Pattern 1: The plugin that almost fits
For mainstream ERPs there are connector plugins: order export, stock sync, customer sync on a schedule. Cost: license plus 1–3 days of configuration. They work well when your ERP is on the supported list and your workflows are vanilla. They break when you need custom fields, multi-warehouse stock logic, or approval workflows that the connector never anticipated. Budget honestly: many “plugin integrations” end at pattern 2 within a year.
Pattern 2: Middleware (iPaaS or a queue service)
A message queue or integration platform between WooCommerce and the ERP. WooCommerce pushes “order created” events; the middleware transforms and delivers; the ERP acknowledges. Cost: $8,000–25,000 to build, plus monthly platform fees. This is the right pattern when order volume makes reliability matter — retries, monitoring, and idempotency are built into the pattern rather than hand-rolled.
Pattern 3: Direct custom API integration
WooCommerce talks to the ERP’s API directly, with custom code handling auth, retries, and field mapping. Cost: $15,000–60,000 depending on the ERP’s API maturity. Choose it when the ERP API is solid and the middleware would just pass data through untouched. The hidden cost is ERP upgrades: every ERP version bump re-tests the integration. Budget annual maintenance at 15–20% of build cost.
Scope phase one like a skeptic
The $20k mistake is integrating everything at once. Phase one should be one direction: orders out (WooCommerce → ERP) and stock levels in (ERP → WooCommerce). That alone eliminates the daily re-keying that motivated the project. Customers, invoices, and shipping statuses come in phase two once the first pipeline has run for a month in production.
What always gets underestimated
- Field mapping. “Just map the fields” hides decisions: what is a customer when one company has three buyer emails? Who wins on conflicting addresses?
- Test data. You need sandbox ERP access and realistic orders. Client IT teams are the usual bottleneck — book their time before the developers’
- Failure behavior. When the ERP is down at 3pm on a Friday, what does the store do? Design the fallback (accept orders, queue them) rather than discover it.
Sequencing with the rest of the build
Do not start ERP work until the store itself is stable — a slow, half-broken storefront makes every integration bug harder to see. If performance is already shaky, fix that first: our caching guide and the slow-theme guide cover the foundations. A free audit gives you the baseline numbers before integration money is committed.
Yes — via dedicated connector plugins for common versions, middleware patterns for reliability, or custom API code. The right pattern depends on order volume and how much your workflows deviate from the connector's assumptions. A plugin setup takes days. Middleware projects run 6–12 weeks including testing against a sandbox ERP. Direct integrations depend heavily on the ERP's API quality. Orders out and stock in. That pairing removes the daily manual re-keying and prevents overselling — customer and invoice sync can wait for phase two. Design it deliberately: WooCommerce should accept orders and queue them for delivery when the ERP recovers, with monitoring to alert you. Never couple checkout availability to ERP uptime.Can WooCommerce connect to SAP or Dynamics?
How long does an ERP integration take?
What should sync first: orders or stock?
What happens to orders when the ERP is down?
