A reference architecture for a common problem: the ERP runs internal operations well but was never designed to talk to online marketplaces, and staff are retyping orders between systems.
This is a reference architecture, not a client case study. No client names or figures from a specific project appear on this page.
The problem
A company with an ERP deployed years ago, running reliably for inventory, accounting and production. It now also sells on two or three marketplaces, its own website, and through retail stores.
Current state: every morning staff download orders from each channel and key them into the ERP. Stock levels update once a day, so the business oversells. When a customer asks about an order, someone opens three systems to find out.
Replacing the ERP is not the answer — it does its job well, and the replacement cost is out of proportion to the problem.
Proposed architecture: a middle layer
Do not modify the ERP, do not modify the marketplaces. Build a service in between that translates data both ways and keeps state synchronised.
Why a middle layer
- The ERP is untouched, so the running business is not put at risk
- Adding a channel means writing one connector, not changing everything else
- When a marketplace changes its API, only that connector needs work
- There is one place to look at logs when tracing a discrepancy
Decide the source of truth per data type
This is the single most important decision in the project. Settle it before the first line of code.
| Data | Source of truth | Direction |
|---|---|---|
| Product catalogue, pricing | ERP | ERP pushes out to channels |
| Available stock | ERP | ERP pushes out, high frequency |
| New orders | Sales channel | Channel pushes into ERP |
| Fulfilment status | ERP | ERP pushes back to the channel |
| Customer records | Depends on policy | Must be decided explicitly; this is where disputes arise |
The stock problem, which is the hard part
Allocating stock rigidly per channel wastes inventory: channel A sells out while channel B holds stock it cannot shift. Exposing the full quantity to every channel guarantees overselling.
A workable middle ground: hold a safety buffer that is never exposed to any channel, and share the remainder. When an order arrives, decrement stock in the middle layer immediately, before the ERP catches up, so two channels cannot sell the same unit in the window between syncs.
Stock should sync far more frequently than other data — every few minutes rather than every few hours.
Failure points
| Situation | Handling |
|---|---|
| Marketplace API rate limits | Queue and throttle; prioritise stock over other data |
| ERP down for maintenance | Middle layer holds orders in a queue and replays them |
| Order pushed twice | Each order carries a unique key; the ERP rejects duplicates |
| Marketplace changes its API without notice | Daily automated checks that alert on structural change |
| Drift accumulating over time | Full nightly reconciliation with a discrepancy report |
Always keep the manual path
However good the automation, there must be a screen where an operator can see stuck orders and push them through by hand. One day a marketplace will return data in an unexpected shape, and you need to handle it without calling a developer.
Delivery sequence
- One direction first. Pull orders from one marketplace into the ERP. Run it alongside manual entry for two weeks, reconciling order by order.
- Add stock sync. Start with low frequency and a large safety buffer, then tighten as confidence grows.
- Extend to remaining channels. One connector each, added incrementally.
- Push fulfilment status back. Reduces load on customer service.
- Dashboards and automated reconciliation. So operations does not need engineering involvement daily.
What you would need to provide
- ERP API documentation, or database access if there is no API
- Seller accounts on each marketplace with permission to create API keys
- A product code mapping between the ERP and each channel — usually the messiest part
- A decision on stock buffer policy: how much overselling risk is acceptable
Written from the team's hands-on experience delivering infrastructure and software. No sponsorship, no product placement.