Middleware between ERP and e-commerce / user-facing software
When a multinational group rolls out a new ERP and centralizes key processes, the specific needs of individual countries often slip out of sight.
Local business practices, legislation, pricing rules, and operational realities rarely fit neatly into a single rigid system. The result is frequent disruptions in digital sales during ERP migrations, reduced local autonomy, and a slow ability to adapt e-commerce to market specifics–precisely at a time when digital channels require agility and continuity. This case study shows how middleware between ERP and e-commerce can restore control to local subsidiaries, ensure uninterrupted operations, and enable rapid changes without touching the central ERP.
Why companies tackle this
When a multinational group rolls out a new ERP and centralizes processes, head office naturally focuses on the shared rule, not on the exceptions. Local needs of subsidiaries – different countries, distinct business practices, their own customer base – often slip out of sight. That brings three typical risks:
- Outages of digital sales/availability during ERP migrations/outages, as well as during the ERP production rollout itself,
- Loss of local autonomy (contract terms, tracked KPIs, local legal specifics, pricing, availability, delivery),
- Slow ability to adapt e-commerce (or other parts such as CMS or managerial accounting/reporting) to the specifics of individual markets.
Goal of the solution
The key is to decouple a specific application – typically the fast-changing e-commerce channel – from the rigid ERP, preserve local business rules, and ensure business continuity even during long outages. In other words: give head office the stability it needs, and the subsidiaries the freedom they need.
Architectural pattern
The solution is middleware that sits between the ERP and the local software. On the outside it provides stable API contracts; on the inside it offers local teams a toolkit they can use to manage rules, content and integrations on their own – without waiting for head office.
Key middleware capabilities
Our wholesale e-commerce example is transferable to any other industry. The resulting solution has these key capabilities.
Sales platform for partners (distributors / wholesalers)
Partners need their own space where they can set commercial terms for end customers without touching the central ERP. The middleware gives them concrete tools to do that:
- Price and margin overrides on top of the catalog (manage commercial terms without touching the ERP).
- Access management for partners’ end customers (who don’t fit the standard permission model), including account creation and delegated permission management.
- Product availability: ability to upload/integrate own stock levels (CSV/API) and control who can see them; fallback to central-warehouse availability.
- Delivery/dispatch: multiple partner branches, shipping rules, and order routing governed in the middleware.
- Assortment governance: optional restriction to an approved catalog (partners do not add “foreign” items).
Identity & Access as a service
- Onboarding of external accounts (partners, their customers), password resets, registration, roles/permission sets, audit.
- Parameterization of catalog behavior for different roles, notifications, last login.
Download center (invoices and documents)
- Expose invoices and internal documents directly in e-commerce.
- Automation (management commands, scripts)–e.g., moving files into the Download center.
CMS for e-commerce
- Banners, content blocks, promotions and top-sale products are edited directly, without touching the ERP – so marketing can work at its own pace.
Offline mode (business continuity)
A planned downtime or ERP outage must not mean a sales standstill. In such situations the middleware takes over and ideally the user doesn't even notice the difference.
- During an ERP outage/planned downtime: uninterrupted ordering; transactions are queued and re-synced once the ERP is back.
- Real-time availability may be temporarily hidden; users effectively don’t notice the outage.
Reference-data integrations
- Connect to reference-data providers (e.g., identification of goods/machines/vehicles via various identifiers).
- Smart search: detect the input type from free text and query the appropriate source; more accurate orders, fewer returns.
Modules (extensibility & entitlements)
- Optional e-commerce modules (e.g., advanced search, specific payment or shipping integrations).
- Entitlements: activate modules for specific markets/partners without impacting others.
Commercial data outside the ERP
- Lost sale reasons, abandoned carts, user behavior – valuable inputs for sales and marketing that ERPs typically don't capture at all.
Portability across countries and subsidiaries
This problem is not rare–it recurs in multinational groups where the central ERP doesn’t reflect local specifics. Portability is built on:
- Layer separation: ERP (stability) vs. e-commerce (fast change), with middleware in between.
- Configurability: pricing, availability, delivery rules, roles, and content manageable locally.
- Templates: reusable data schemas, API contracts, standard connectors, and runbooks.
- Extensibility: a module/entitlement model enables different features per market without code forks.
What’s fixed vs. variable
In this model some elements are fixed – usually defined by the parent company or the ERP itself – while others are variable: you decide on those yourself in the local market, or local legislation does. The split typically looks like this:
- Fixed: integration principles (APIs, messaging/queues, idempotence), data contracts (catalog, pricing, orders, identities), observability and audit.
- Variable: local taxes/VAT, languages and currencies, carriers and SLAs, pricing rules, module extensions, reference-data sources.
Implementation playbook for a new subsidiary
Connecting a new subsidiary isn't improvisation – we follow a proven sequence of steps. Each has a clear output and feeds into the next, so the client always knows what's being handled now and what comes next:
- Discovery & fit-gap: roles and flows (B2B partner, their customer), pricing, logistics, compliance.
- Data contracts: catalog, pricing, availability, orders, invoices, identities; define the offline data set.
- Adapter layer to the ERP: connectors, message bus, retries, idempotence, audit trail.
- E-commerce: modular rollout, CMS, promotions, permissioning and catalog behavior.
- IAM: registration/SSO (if needed), password management, roles, audit.
- Reference data: integrate local/industry providers, validation and fallbacks.
- Modules: select modules for specific markets/partners.
- Offline scenarios: DR plans, testing long outages, re-sync metrics.
- Go-live & hypercare: monitoring, notifications, runbooks, training local admins.
What we need from the client to start
To design middleware that fits your environment, we need a few essential inputs from you at the start. Without them we can't properly set up the data contracts or the business logic:
- Source of truth for prices and discounts, definition of partners and segments.
- Logistics and delivery rules (carriers, cut-offs, SLAs), payment methods.
- Requirements for language, currencies, VAT and local compliance.
- Target KPIs and expected NFRs (non-functional requirements).
Summary