Integrating WooCommerce with an ERP in B2B is not a matter of connecting two APIs and declaring the project complete. The real difficulty is deciding which system owns each data domain, which information needs real-time access, how account rules are represented and what happens when synchronisation fails halfway through an operation.
The right architecture does not try to make both systems know everything. It makes each system responsible for what it understands best and moves changes between them in an observable, recoverable way.
When WooCommerce fits a B2B scenario
WooCommerce can work very well when the business needs content flexibility, catalogue control, experience design and extensibility while the ERP already owns customers, pricing, orders or invoicing. Fit becomes weaker when WordPress is expected to duplicate extremely complex commercial logic that already exists elsewhere and changes continuously.
The question is not whether WooCommerce can technically implement a rule; almost anything can be developed. The question is where that rule should live so it remains governable three years later.
Start with a systems-of-record matrix
Before building integration, list the main domains: customer, user, address, catalogue, attributes, price, availability, order, invoice, credit, shipment and document. Define an owner and consumers for each.
In a typical WooCommerce ERP integration, ERP owns the account, commercial terms, final price, credit, order and invoice. WooCommerce may own session, editorial content, navigation, pre-confirmation cart and certain user preferences. PIM may own product enrichment.
Customers and accounts: a user is not a customer
WordPress naturally thinks in users; B2B thinks in accounts containing several users. The integration needs a layer linking individuals to an ERP customer entity. That relationship must support roles, locations, permissions and personnel changes.
Do not use email as the only permanent identifier when the business has complex accounts. Preserve ERP IDs and stable keys. A person can change email, a company can merge, and two contacts can share a domain without belonging to the same customer.
Pricing: calculate or synchronise
There are two broad patterns. One synchronises price lists and rules to WooCommerce and calculates locally. The other asks ERP or a pricing service during the experience. Local calculation is faster and more tolerant of outages; remote calculation reduces duplicated logic.
The decision depends on change frequency, complexity and how immediate accuracy must be. A contractual price changing quarterly can be synchronised. A quote driven by commodity inputs or complex rules may need remote calculation.
Either way, discrepancies need to be explainable: which price was shown, which data version produced it and which value ERP eventually received.
Stock and availability: the number is not always the promise
Physical ERP stock may not equal sellable quantity. Reservations, warehouses, batches, open orders and allocation rules matter. Design a buyer-facing concept of availability: units, estimated date, warehouse availability or a simpler state.
Critical SKUs can use real-time queries. Large catalogues often work better with frequent snapshots plus a final validation before order confirmation.
Catalogue: ERP is not always a PIM
Many ERPs contain SKU and administrative description but not the information required to sell: applications, benefits, compatibility, documents, images and taxonomy. Do not force ERP to become a PIM simply because it already exists.
Where PIM exists, WooCommerce should receive enriched product content from PIM and transactional data from ERP. Define merge rules so an administrative synchronisation cannot erase commercial content.
Orders: design a state machine
The most sensitive hand-off is the order. Decide when WooCommerce considers the transaction accepted: when the local order is created, when ERP confirms it or after credit validation. Each option affects UX and support.
A robust architecture uses correlation and idempotency identifiers. Retrying the same request must not create a second order. Store ERP response and integration state separately from the commercial status shown to the customer.
Webhooks, queues and batch processes
Webhooks are useful for fast change notification, but they should not be the only guarantee. They can be lost, duplicated or arrive out of order. Queues decouple systems and support retries. Batch processes can provide reconciliation.
A strong pattern combines events for speed with a periodic routine checking that both sides remain consistent. A webhook may update order status while a nightly reconciliation finds orders that missed an event.
Retry without duplicating effects
Every remote operation should assume timeouts will occur. If you do not know whether ERP received a request before the connection broke, repeating it without an idempotency key can duplicate orders. Design operations that are safe to retry.
Separate temporary errors such as timeouts from business errors such as blocked accounts or invalid products. Temporary errors can retry automatically; business errors need intervention or a user-facing message.
An exception queue is part of the product
B2B integrations should not hide failures in technical logs. Create an operational exception view: order waiting for ERP, price without response, unmapped customer, failed document. Assign ownership and a possible action.
The goal is not zero errors. It is fast detection and recovery without relying on customers to discover the problem first.
What observability should measure
- Latency by operation type.
- Failure and retry rate.
- Messages in a dead-letter queue.
- Differences found through reconciliation.
- Duplicate orders prevented by idempotency.
- Age of the last price and stock data.
- Errors by API or system version.
These measures should trigger alerts when thresholds are exceeded. Manually reading logs only after a customer calls is not observability.
Security and data
Never expose ERP credentials to the browser. Integration should run server-side or through middleware, with managed secrets and least privilege. Log sensitive actions without retaining more personal data than necessary.
If the portal exposes confidential commercial information, every query must be scoped to the account. A caching or authorisation error that mixes customer pricing is a serious incident.
How to test WooCommerce ERP integration
Use representative accounts and edge scenarios: a price change during a session, stock running out between cart and confirmation, slow ERP, partial order, unauthorised user, return, different currency and discontinued product. Test recovery after outages as well.
Contract tests between APIs help detect changes before production. If ERP upgrades version, the ecommerce team should know whether critical fields or behaviour have changed.
SEO and GEO remain part of the system
Integration supports transaction, but the public site still needs indexable, understandable content. Rich product data, application pages, documentation and clear relationships between families support search visibility and generative citations.
Do not allow an ERP dependency to make search engines receive blank pages whenever a backend is slow. Important public content should be served resiliently.
Frequently asked questions
Does everything need real-time integration?
No. Use real time where a decision depends on immediate information. For other data, frequent synchronisation plus reconciliation can be simpler and more reliable.
Direct integration or middleware?
Direct integration can work in simple environments. Middleware adds value when multiple systems, transformations, queues, observability or decoupled change are required.
Who should monitor the integration?
There needs to be clear operational ownership. Development can maintain technology, but business and operations need visibility into exceptions affecting orders and customers.
Use an anti-corruption layer between ERP and ecommerce
When ERP uses legacy structures or naming designed for back-office users, avoid copying them directly into the ecommerce domain. A transformation layer can convert codes, states and data models into stable concepts designed for digital channels. This prevents every ERP change from forcing changes throughout front-end logic.
The layer also improves testing and observability: it can validate contracts, reject incomplete messages and record transformations. In multi-channel architectures the same integration services can support ecommerce, distributor portals and applications without duplicating adapters.
Version APIs and control change
Define API versions and payload contracts. Adding an optional field is very different from renaming an identifier already used in production. Teams need advance notice of breaking changes and a test environment. Critical integrations deserve maintenance windows and rollback planning just like any other product component.
Reconcile orders and financial values
A 200 API response does not prove systems agree. Periodically compare orders, totals, tax, status and returns between platforms. Daily reconciliation can detect silent divergence that technical logs do not consider an error. This layer becomes particularly important when payments, credit or invoicing are automated.
Ownership: who decides when systems disagree?
Data discrepancies are not only technical problems. When WooCommerce and ERP show different pricing or status, there needs to be a business owner who defines the correct rule and a technical owner who implements the correction. Without that separation teams can spend hours asking which system is “wrong” without a policy defining which one should lead.
Maintain a runbook containing owners, escalation paths and example incidents. This shortens diagnosis time and allows new team members to operate the integration without relying on oral knowledge.