Composable Commerce and ERP Integration: Connecting Elastic Path to Your Back Office

The promise of composable commerce is flexibility: choose best-of-breed components for each capability in your ecommerce stack and orchestrate them to meet your specific business requirements. Elastic Path delivers on this promise for the commerce engine, providing product catalogue management, cart and checkout, promotions, and order management through a modern API-first architecture.

But commerce does not exist in isolation. Behind every online storefront sits a back-office ecosystem – ERP systems, warehouse management, financial accounting, procurement – that must remain synchronised with the commerce platform. For UK enterprises running SAP, Microsoft Dynamics 365, Oracle NetSuite, or similar ERP systems, the integration between Elastic Path and the back office is often the most technically demanding aspect of a composable commerce implementation.

At McKenna Consultants, we work as an Elastic Path implementation partner in the UK, helping organisations design and build the integration architecture that connects their composable commerce platform to their existing enterprise systems. In this article, we provide a technical guide to the key integration patterns, data flows, and pitfalls involved in connecting Elastic Path to your ERP.

Why ERP Integration Is the Critical Path

In a monolithic ecommerce platform, the commerce engine and back-office functions often share a database or use tightly coupled internal APIs. Data flows between order management, inventory, and finance are handled within the platform itself.

Composable commerce deliberately decouples these concerns. The commerce engine manages the customer-facing transaction, but it does not own inventory truth, financial ledger entries, or fulfilment logistics. These responsibilities belong to the ERP.

This means the integration layer between Elastic Path and the ERP is not an afterthought – it is a core architectural component. Without reliable, timely data synchronisation, you face:

• Inventory inaccuracy – Customers purchasing items that are out of stock because the commerce platform has stale inventory data.
• Order fulfilment delays – Orders that are captured in Elastic Path but not transmitted to the ERP for processing.
• Pricing discrepancies – Differences between the price displayed on the storefront and the price recorded in the financial system.
• Revenue recognition failures – Finance teams unable to reconcile commerce transactions with ledger entries.

Getting this integration right is essential, and it is where many composable commerce projects encounter their most significant challenges.

Integration Architecture Patterns

There are two primary architectural patterns for connecting Elastic Path to an ERP: event-driven integration and batch synchronisation. Most production implementations use a combination of both, applying the appropriate pattern to each data flow based on latency requirements and data volume.

Event-Driven Integration

In an event-driven architecture, changes in one system are published as events and consumed by the other system in near real-time. Elastic Path supports webhooks that fire when significant commerce events occur – order creation, payment capture, order fulfilment status changes.

The typical event-driven flow for order processing:

1. A customer completes checkout in Elastic Path.
2. Elastic Path fires an order.paid webhook to the integration layer.
3. The integration layer transforms the order data into the ERP’s expected format.
4. The integration layer creates a sales order in the ERP via its API.
5. The ERP processes the order through its fulfilment workflow.
6. The ERP publishes fulfilment status updates, which the integration layer relays back to Elastic Path.

Event-driven integration is the right choice for data flows where timeliness matters. Order transmission should happen within seconds of payment capture. Inventory adjustments after a sale should propagate quickly to prevent overselling.

Key considerations for event-driven integration:

• Idempotency. Webhooks can be delivered more than once. The integration layer must handle duplicate events gracefully, typically by using the event’s unique identifier to detect and skip duplicates.
• Ordering. Events may arrive out of order. The integration layer must be resilient to receiving a fulfilment update before the corresponding order creation event, or it must implement sequencing logic.
• Error handling and retry. If the ERP is temporarily unavailable, events must be queued and retried. A dead-letter queue pattern ensures that persistently failing events are captured for investigation rather than silently lost.

Batch Synchronisation

Batch synchronisation processes data in scheduled intervals – every five minutes, every hour, or once daily. This pattern is appropriate for data flows where near real-time latency is not required and where the data volume makes individual event processing impractical.

Common batch synchronisation flows include:

• Product catalogue sync. Product definitions, descriptions, images, and categorisation are mastered in the ERP or a PIM (Product Information Management) system and synchronised to Elastic Path on a schedule.
• Price list updates. Pricing, particularly complex B2B pricing with contract-specific rates, tiered discounts, and currency conversions, is often managed in the ERP and pushed to Elastic Path in batches.
• Inventory snapshots. While critical inventory adjustments (sales, returns) should be event-driven, a periodic full inventory reconciliation ensures that the commerce platform’s stock levels remain aligned with the ERP’s warehouse data.

Key considerations for batch synchronisation:

• Conflict resolution. When both systems can modify the same data (e.g., product descriptions edited in both Elastic Path and the PIM), you need clear rules for which system wins.
• Delta processing. Full data extracts are expensive. Implement change detection so that batch jobs only process records modified since the last run.
• Monitoring and alerting. Batch jobs that fail silently are dangerous. Implement monitoring that alerts operations teams when a sync job fails, processes zero records unexpectedly, or takes longer than its normal duration.

The Integration Middleware Layer

Both patterns benefit from an explicit integration middleware layer rather than direct point-to-point connections between Elastic Path and the ERP. This middleware layer serves several purposes:

• Data transformation. Elastic Path and the ERP will have different data models. The middleware maps between them, handling differences in field names, data types, enumerations, and structures.
• Orchestration. Some business processes require coordination across multiple API calls. Creating a sales order in SAP, for example, may require first checking credit limits, then creating the order header, then adding line items, then triggering ATP (available-to-promise) checks.
• Abstraction. The middleware shields each system from changes in the other. If the ERP is upgraded or replaced, only the middleware needs updating – the Elastic Path integration remains stable.

Common middleware choices for UK enterprise deployments include Azure Integration Services (Logic Apps, Service Bus, API Management), MuleSoft, and Boomi. The choice depends on existing enterprise architecture, team skills, and licensing considerations.

Key Data Flows in Detail

Order Management

The order flow is the most critical integration path. It encompasses order creation, payment reconciliation, fulfilment tracking, and returns processing.

Order creation flow:

When an order is placed in Elastic Path, the integration layer must create a corresponding sales order in the ERP. This involves mapping:

• Customer identity (matching the Elastic Path customer to an ERP customer account, or creating a new account for guest checkouts)
• Line items (mapping Elastic Path product SKUs to ERP item numbers)
• Pricing (unit prices, discounts applied, tax calculations)
• Shipping method and address
• Payment reference (for reconciliation with the payment gateway)

For B2B scenarios common in Elastic Path B2B ecommerce development, additional complexity arises from purchase order references, approval workflows, and account-level credit terms that must be validated against the ERP before order confirmation.

Fulfilment status flow:

Once the ERP processes the order through its warehouse and shipping workflows, fulfilment status must flow back to Elastic Path so that customers can track their orders. This typically involves mapping ERP despatch confirmations and carrier tracking numbers back to the Elastic Path order.

Returns and refunds:

Returns processing often requires bidirectional integration. The return may be initiated on the commerce platform (customer self-service) or in the ERP (warehouse receiving a returned item). Both systems need to be updated with the return status, and the payment gateway may need to process a refund.

Inventory Synchronisation

Inventory accuracy is arguably the single most impactful integration to get right. Displaying inaccurate stock levels erodes customer trust and creates operational overhead from cancelled orders.

The recommended approach combines:

• Event-driven decrements. When an order is placed, immediately decrement the available quantity in Elastic Path. This provides the fastest possible protection against overselling.
• Periodic reconciliation. Run a batch sync (typically hourly or more frequently) that reconciles Elastic Path inventory levels with the ERP’s warehouse management system. This corrects any drift caused by missed events, manual adjustments in the warehouse, or stock receipts from purchase orders.
• Safety stock buffers. For high-velocity products, maintain a safety stock threshold in Elastic Path that triggers an “out of stock” status before the ERP’s actual stock level reaches zero. This provides a buffer against the inherent latency in any integration.

For businesses with multiple warehouses or distribution centres, inventory synchronisation must account for location-based availability. Elastic Path’s inventory service supports multi-location stock, but the integration must aggregate or route appropriately based on the customer’s delivery location.

Pricing and Contract Management

Pricing integration varies significantly between B2C and B2B scenarios.

B2C pricing is relatively straightforward: price lists are maintained in the ERP or a pricing engine and synchronised to Elastic Path. Promotions and discounts may be managed in Elastic Path’s promotions engine, in which case the ERP receives the final transacted price rather than needing to know about individual promotions.

B2B pricing is considerably more complex. Enterprise customers often have negotiated contract prices, volume-based tiering, currency-specific rates, and approval-based discount authorities. These pricing structures are typically mastered in the ERP and must be available to the commerce platform at the point of browse and purchase.

The integration approach depends on the complexity:

• Pre-calculated price lists. For manageable numbers of customers and products, generate customer-specific price lists in the ERP and sync them to Elastic Path.
• Real-time price lookup. For highly dynamic or complex pricing (e.g., thousands of customers with unique contract terms), call the ERP’s pricing API at browse-time to retrieve the applicable price. This adds latency but ensures accuracy.
• Hybrid approach. Cache frequently accessed prices in Elastic Path with a short TTL, falling back to a real-time ERP lookup on cache miss. This balances performance with accuracy.

Common Pitfalls and How to Avoid Them

Pitfall 1: Underestimating Data Mapping Complexity

The conceptual mapping between Elastic Path and an ERP seems simple – an order is an order, a product is a product. In practice, the data models diverge significantly. ERP systems model business entities with decades of accumulated complexity: multiple organisational units, posting periods, tax jurisdictions, material types, and valuation classes.

Mitigation: Invest time upfront in detailed data mapping workshops. Document every field, every transformation rule, and every edge case. This mapping document becomes the specification for the integration layer and the reference for troubleshooting.

Pitfall 2: Ignoring Error Handling

The happy path is easy. It is the error scenarios that determine whether an integration is production-ready. What happens when the ERP rejects an order because the customer’s credit limit is exceeded? What happens when a product SKU in Elastic Path does not have a corresponding item number in the ERP?

Mitigation: Design explicit error handling for every integration flow. Define retry policies, dead-letter queues, and alerting thresholds. Implement a monitoring dashboard that provides visibility into integration health.

Pitfall 3: Building Point-to-Point Integrations

Connecting Elastic Path directly to the ERP without a middleware layer creates tight coupling that becomes increasingly brittle as the number of data flows grows. Adding a new data flow requires modifying both systems, and changes to one system’s API risk breaking existing integrations.

Mitigation: Always use an integration middleware layer. The upfront investment pays for itself in reduced maintenance, easier troubleshooting, and the ability to swap or upgrade individual systems without a full re-integration.

Pitfall 4: Not Testing with Production-Volume Data

Integrations that work flawlessly with ten test orders may fail spectacularly with ten thousand real orders during a promotional event. Batch synchronisation that completes in seconds with a hundred products may take hours with a catalogue of fifty thousand.

Mitigation: Performance test with realistic data volumes. Simulate peak-load scenarios (Black Friday, seasonal promotions) and verify that the integration layer can handle the throughput without falling behind.

Pitfall 5: Overlooking Master Data Governance

When product data, customer data, and pricing data exist in multiple systems, the question of “which system is the master?” must be answered definitively for every data entity. Ambiguity leads to conflicting data and manual reconciliation overhead.

Mitigation: Establish a clear master data governance policy before building integrations. For each data entity, designate a single system of record and ensure that all other systems consume data from that master.

Middleware Selection for UK Enterprises

For UK organisations evaluating middleware for their composable commerce ERP integration, the primary considerations are:

• Azure Integration Services – A natural choice for organisations already invested in the Microsoft ecosystem. Azure Logic Apps provide low-code integration workflows, Service Bus offers reliable messaging, and API Management provides governance for internal APIs. Strong fit for Microsoft Dynamics 365 integrations.
• MuleSoft – An enterprise integration platform with extensive pre-built connectors for SAP, Oracle, and Salesforce. Well-suited for organisations with complex multi-system landscapes and dedicated integration teams.
• Boomi – A cloud-native integration platform with a visual development environment. Good fit for mid-market organisations that need integration capability without maintaining on-premises middleware infrastructure.

The choice should align with existing enterprise architecture and team capabilities rather than being made in isolation for the commerce project.

Planning Your Integration

For organisations embarking on a composable commerce implementation with Elastic Path, our recommendation is to begin integration planning at the same time as commerce platform design – not after. The integration architecture influences decisions about data ownership, event schemas, API contracts, and operational workflows that are difficult to change retrospectively.

As an Elastic Path implementation partner in the UK, McKenna Consultants brings deep experience in composable commerce ERP integration across multiple ERP platforms and middleware technologies. Whether you are migrating from a monolithic platform or building a greenfield B2B commerce capability, we can help you design an integration architecture that is reliable, performant, and maintainable.

Conclusion

Integrating Elastic Path with your enterprise ERP is the linchpin of a successful composable commerce implementation. The flexibility and best-of-breed component selection that composable architecture provides is only valuable if the components work together reliably.

By applying the right integration patterns – event-driven for time-sensitive flows, batch for bulk data synchronisation, and a robust middleware layer to manage transformation and orchestration – organisations can achieve the real-time data accuracy that customers and operations teams expect.

The investment in thoughtful integration architecture, comprehensive error handling, and production-grade monitoring distinguishes composable commerce implementations that deliver long-term value from those that create ongoing operational headaches. With the right approach and experienced guidance, composable commerce ERP integration becomes a competitive advantage rather than a technical liability.