What moves between the store and the ERP
An ecommerce platform is built to sell. An ERP is built to buy, store, make and account. They overlap on products, customers and orders, and the integration exists to keep that overlap consistent. Six kinds of record usually travel.
| Record | Usual direction | Usual authority | The awkward part |
|---|---|---|---|
| Products and variants | ERP to store | ERP for codes and attributes | Marketing content often lives in the store, not the ERP |
| Prices | ERP to store | ERP | Promotions and customer-specific prices |
| Stock levels | ERP to store | ERP or warehouse system | Speed, reservations and several locations |
| Orders | Store to ERP | Store until accepted, then ERP | Discounts, taxes, bundles and gift cards |
| Fulfilment and tracking | ERP to store | ERP or warehouse | Partial shipments and split orders |
| Refunds and returns | Either | Depends on who decides | Keeping stock and money in step |
Keep stock accurate enough to sell from
Overselling is the failure customers notice. It happens when the store shows stock that the warehouse no longer has, and three things control it.
- 01
Speed of updates
Decide how quickly a change in the warehouse must reach the store. Fast-moving or scarce items may need updates within moments. Slow lines can wait for a scheduled batch. The ERP's ability to report changes often sets the limit.
- 02
What counts as available
Stock on the shelf is not the same as stock for sale. Subtract quantities reserved for open orders, held for quality checks or promised to other channels, and agree the formula with the warehouse.
- 03
A safety margin
For items where a mistake is costly, show slightly less than the system reports. A small buffer absorbs counting errors and the delay between the two systems.
- 04
Several locations
If stock sits in more than one warehouse or shop, decide which locations feed online availability and which one fulfils each order.
Whether you need live updates or scheduled ones is a business question as much as a technical one. Our comparison of real-time and scheduled data sync sets out the cost and benefit of each.
A worked example
A homeware retailer with two warehouses
This example is invented to show the decisions. A retailer sells online and to trade customers from two warehouses, and currently retypes web orders into its ERP every morning.
- AuthorityThe ERP owns item codes, prices and stock. The store owns descriptions and photographs. Orders belong to the store until the ERP confirms them.
- StockAvailable quantity is shelf stock minus open orders, summed across both warehouses, less a buffer of two units on fragile lines. Updates are sent within minutes of a change.
- OrdersA web order creates a sales order in the ERP with its discounts and delivery charge on separate lines. Bundles are exploded into their component items so that stock is reduced correctly.
- FailuresAn order with an unknown item code stops in a queue, and the ecommerce manager is emailed. In the first month, 14 orders stop this way, all caused by products created in the store before they existed in the ERP.
The fix for those failures is a rule, not code: products are created in the ERP first. Morning retyping ends, and overselling falls to the occasional case where a physical count was wrong.
Plan for the day it fails
Every integration fails sometimes. A system is down for maintenance, a product is missing a tax code, a network request times out. What separates a good integration from a poor one is what happens next.
Built to recover
- Failed records wait in a visible queue with the reason
- Temporary failures are retried automatically
- A retry cannot create the same order twice
- A named person is alerted when something is stuck
- Both systems are compared on a schedule to catch drift
Built to hide problems
- Errors are written to a log nobody reads
- A failed order simply never appears in the ERP
- Retrying creates duplicate orders
- Nobody is responsible for the integration after launch
Connector or custom integration
For common pairings of store platform and ERP, ready-made connectors exist, and they are the right first thing to evaluate. They are quicker and cheaper than custom work when your products, prices and processes are standard.
| Situation | Likely fit |
|---|---|
| Simple catalogue, one warehouse, standard pricing | A maintained connector |
| Variants, bundles or customer-specific prices | A connector with extensions, or custom |
| Several warehouses, stores or legal entities | Usually custom |
| An ERP with no documented interface | Custom, often using scheduled files |
| High order volumes with peaks | Custom, with queues designed for the peaks |
Test a connector against your awkward cases before committing: a bundle, a partial refund, a customer with special prices. Our comparison of a custom integration and an existing connector gives a fuller way to decide.
The integration checklist
Ecommerce to ERP integration checklist
0 of 10 checkedWhat to do next
Before speaking to anyone about building, fill in our integration discovery questionnaire. It collects the facts above on one page, and it works for any pair of systems.
If you would like us to look at it, we build these connections as part of system integration work. Send us the questionnaire and we will tell you what we would verify first.
Common questions
Do we need real-time stock updates?
Only where a delay would cause overselling or lost sales. Fast-moving and scarce items benefit from updates within moments. For slower lines, a scheduled update with a small safety margin is usually enough and costs less to build and run. The decision can differ by product, and the ERP's ability to report changes often determines what is possible.
Which system should hold product information?
Operational data, such as codes, costs, prices, weights and stock, belongs in the ERP. Presentation, such as descriptions, photographs and search wording, is usually better kept in the store or a product information tool, because marketing teams work there. The integration then creates a product in the store from ERP data and leaves the presentation fields alone.
What happens to orders if the ERP is offline?
In a well-built integration the store keeps taking orders, and they wait in a queue until the ERP returns, then flow in the correct sequence. Stock shown online may be slightly out of date during the outage, which is one reason for a safety margin. Ask whoever builds the integration to demonstrate this before launch.
Can a connector handle customer-specific prices?
Some can, within limits. Simple price lists by customer group are often supported. Contract prices by individual customer, quantity breaks and prices that depend on other conditions frequently exceed what a connector can express. Test with your most complicated customer before deciding, since B2B pricing is among the most common reasons a connector is replaced.
How long does an ecommerce ERP integration take to build?
It depends on the number of record types, the quality of the ERP's interface and how many awkward cases your catalogue contains, so an honest answer needs your details. The mapping and the decisions about authority often take as long as the development. A parallel run before going live should be part of any plan.
