ERP, CRM and e-commerce integration architecture: a flow-by-flow design

This guide is for CTOs, IT managers and e-commerce leads whose store, ERP and CRM already run and now have to work as one. Our enterprise systems integration guide explains the general principles: record ownership, integration patterns and designing for failure. This page applies them to the commerce triangle, flow by flow, and ends with a topology choice and a rollout plan.

In this guide

• Three systems, five flows
• The reference architecture
• Designing the five flows
• B2B rules that change the design
• Topologies: alternatives and selection criteria
• AI in the integration layer
• A rollout plan
• Worked examples from Netbase delivery
• What delivery record exists, and what does not
• Limits of this guide
• Frequently asked questions
• Next step

Three systems, five flows

Most commerce landscapes have the same three systems at the centre. The store sells and takes payment. The ERP holds products, stock, prices, orders for fulfilment and the books. The CRM holds accounts, contacts, quotes and service history. Around them sit a payment provider, a warehouse or carrier, and often a product information system.

Almost all integration work in that triangle falls into five flows:

Write this table for your own landscape before choosing any tool. Where two systems both claim a row, the business decides the owner, not the integrator. The pillar guide covers why one owner per record matters; the rest of this page covers what each flow needs once the owner is fixed.

The reference architecture

A durable design has the same layers whatever product implements them.

• An adapter per system. Each store, ERP or CRM gets its own adapter that speaks that system's API and data model. Microsoft's Architecture Center describes this as an anti-corruption layer: a translation layer that keeps one system's semantics from leaking into another. When the ERP is replaced, only its adapter changes.
• One shared data model. Adapters translate to a canonical model of product, customer, order and invoice instead of to each other. The Enterprise Integration Patterns catalogue explains why: with a common format, each new system needs one translation pair rather than one per partner.
• An identifier cross-reference. A small store maps each record's key in every system: the store's order number, the ERP's sales order and the CRM's opportunity. Nothing is matched by name or e-mail.
• Durable events. A change is recorded in the same database transaction that makes it and then published, the transactional outbox pattern, so a crash cannot leave the ERP updated and the store uninformed.
• Orchestration for multi-step flows. Order-to-cash touches four systems; one component owns the sequence and its compensations, so the steps are not scattered across webhooks.
• Monitoring and reconciliation. Every flow has a dashboard, an alert and a daily comparison of counts and totals between owner and copies.

The failure rules for each layer, idempotent writes, retries with backoff and a dead-letter queue, are in the pillar guide and apply unchanged.

Designing the five flows

Catalog and prices. Push changes from the owner as events and keep a nightly full comparison, because a missed event on a price is worse than a late one. Publish a price with its validity dates, so the store never shows a price the ERP will not invoice.

Stock. Send availability, not raw stock: on hand minus reserved minus safety stock, per channel. Reserve stock when an order is created and release it on cancellation, so two channels cannot sell the last unit twice.

Customers and accounts. In B2B the CRM usually owns the account and its contacts, and the ERP owns credit terms. The store receives both, and a new web customer is created in the owner first, then copied, so one person never becomes three records.

Orders and status. The store owns an order until payment is authorised; from then on the ERP owns fulfilment, and status, shipment and tracking flow back. An order carries an idempotency key from the store, since RFC 9110 defines POST as not idempotent and a retried create must not become a second sales order.

Payments, invoices and refunds. The payment provider owns the transaction; the ERP owns the invoice and the credit note; the CRM shows both to the account team. Reconcile captured payments against invoices every day, and let refunds start only from the ERP or through its API.

B2B rules that change the design

Selling to businesses adds rules that a consumer store never meets, and each one decides where logic lives:

• Customer-specific price lists and contract prices stay in the ERP or CRM and are fetched per account, not copied as thousands of product variants.
• Credit limits and payment terms are checked against the ERP at checkout; an order over the limit waits for approval rather than failing.
• Quotes start in the CRM and convert into an order without re-keying, keeping the quote reference on the ERP order.
• Purchase orders and approvals from the buyer's side are stored with the order, so the invoice matches what the buyer's finance team expects.

Topologies: alternatives and selection criteria

Four criteria decide it: how standard your data and rules are, how many systems and flows you expect in two years, who must own and change the logic, and who will operate it at night. Many landscapes start with connectors and move to a hub when error handling and visibility run out; an integration hub is the owned version of that step. Multi-vendor stores add seller payouts and vendor catalogs, covered in marketplace platform architecture. If the store itself is about to change, settle that first with the custom e-commerce platform guide.

Worked examples from Netbase delivery

• Reward shop platform (client not named). For a Dubai-based loyalty company, Netbase connected a headless Magento 2 multi-store platform to the client's points middleware, ordering service and product catalogue. The client's systems own points and orders; webhooks carry changes and a scheduled sync is the failover. See the reward shop record.
• Cloud ERP for a US client (not named). As offshore development and managing partner since 2020, Netbase builds a multi-tenant cloud ERP whose first phase includes CRM and API integrations to the systems tenants already use. See the cloud ERP record.
• Cloodo Workspace. A Netbase Business Division whose workplace combines CRM, HRM, Cloud ERP and AI modules in one product, so records live in one system instead of being synchronised. See the Cloodo record.

Netbase has also connected client stores to their ERP through API sync of catalogs, inventory, orders and customers; those clients are not named.

What delivery record exists, and what does not

• What exists. The records above describe scope and design: which systems were connected, which system owns which data and how changes travel. Netbase's productized modules include a CRM and B2B sales engine, a workflow automation toolkit and Smart ERP Light, and its delivered platforms include WooCommerce, Magento 2, Laravel and headless commerce.
• What does not. None of these records publishes an integration's duration, message volume, error rate or business result, and none is offered here as proof of a figure. The ERP integration clients are not named.

Limits of this guide

• The flow table is a default for B2C and B2B commerce; marketplaces, subscriptions and manufacturing add flows of their own.
• The patterns are cited from their public descriptions; applying them does not make an integration correct without tests against real data.
• Security practices such as least-privilege keys, TLS in transit and AES at rest, and MFA for admin access reduce risk; they are not a guarantee.

Next step

Share your store, ERP and CRM, the flows that break most often and any deadlines, and we will book a solution review to map owners, flows and a topology. You can also see systems and API integration, ERP and CRM development or more Netbase insights.

Related services and solutions