Which system owns which data, why stock must flow event-based, why SKU mapping stretches projects, and why reconciliation is the only real proof.
ERP integration means automatically synchronising product, stock, order, account and invoice data between your e-commerce site, your marketplaces and your accounting or resource planning software. This article covers which data should flow in which direction, the mapping problem, error handling, and the correct order to run the project.
The request usually arrives as: "We enter the same data in three places." A correct diagnosis, but incomplete. The real problem is not repeated data entry but that the data in those three places disagrees — and nobody knows which is right.
First decision: which system owns the truth
| Data | Typical owner | Why |
|---|---|---|
| Product records and attributes | ERP or PIM | Defined once, distributed to every channel |
| Stock | ERP / warehouse | The system that knows physical reality |
| Price | ERP (with channel rules) | Cost and margin live there; channel differences apply as rules |
| Orders | Sales channel | The order is born there |
| Accounts and invoices | ERP | The source of the accounting record |
When this table is not written down, every system tries to update every field and conflicts begin: a price changed by hand on a marketplace is reverted at the next sync; stock corrected in the ERP is overwritten by a stale value from the site.
Direction and frequency
| Flow | Direction | Frequency |
|---|---|---|
| Products and attributes | ERP → channels | On change or daily |
| Stock | ERP → channels | Immediate (event-based) |
| Price | ERP → channels | On change |
| Orders | Channels → ERP | Immediate or every few minutes |
| Order status / shipping | ERP → channels | On change |
| Invoices | ERP → channel / customer | On order confirmation |
Stock is the special case: delay turns directly into overselling and lowers your marketplace seller score. It should therefore be event-based rather than polled — detail in our article on multi-channel stock synchronisation.
Mapping: the part that takes the most time
- SKU inconsistency.
URN-001in the ERP,urn001on the site, a barcode on the marketplace. Without a common key there is no integration. The project's first task is choosing a single mapping key. - Variant structure. If every colour-size combination is a separate stock record in the ERP but a variant under one product on the site, mapping the two requires rules.
- Category tree. ERP categories follow accounting logic while channel categories follow search logic; they rarely correspond one to one.
If these three are not settled before development starts, the project turns into a queue of decisions waiting to be made.
Error handling and retries
- Retry logic. Transient failures should be retried with increasing intervals.
- Duplicate protection. An idempotency key should prevent the same order being written to the ERP twice.
- Queueing. Operations must not be lost while the target system is unreachable.
- Alerting. Silent stoppage is the dangerous scenario; you should be told when the integration stops.
- Reconciliation. Compare order and stock counts on both sides daily. A gap means the integration "looks like" it is working and is not.
Reconciliation is the most skipped step and the most useful safety net. The only thing that proves an integration works is the numbers matching on both sides.
Direct integration or a middle layer
| Direct (point to point) | Middle layer | |
|---|---|---|
| Suits | 1–2 channels, simple data | 3+ channels, rule-driven flows |
| Setup time | Short | Longer |
| Adding a channel | New development each time | Write one new connector |
| Error visibility | Scattered | Monitored in one place |
A practical rule: direct integration is enough up to two channels. At the third, the number of connections — and therefore the maintenance load — starts climbing fast, and a middle layer becomes both cheaper and more manageable.
Project order
- Write the data ownership table. Where each piece of data is born and who updates it.
- Choose the mapping key and clean the data. Skip this and the project stalls later.
- Start with a single flow. Usually stock or orders — the highest impact soonest.
- Build error scenarios and alerts. Do not move to the next flow before the happy path is solid.
- Set up the reconciliation report. A daily comparison.
- Add the remaining flows. Price, products, invoices, shipping status.
Common mistakes
- Starting without defining data ownership. Conflicting updates become inevitable.
- Switching on every flow at once. When something breaks, you cannot tell which flow caused it.
- Developing before cleaning mapping data. The project stalls in the most expensive way possible.
- No alerting or reconciliation. You learn the integration stopped from a cancelled order.
- Hard-coding per-channel rules. Rules should be configurable, so every change does not require development.
Conclusion
ERP integration is a data management project more than a software one. The technical part is predictable; what decides the outcome is settling where each piece of data is born and taking error scenarios seriously. With both done, integration turns adding a channel from a cost into routine work.
For the invoicing and shipping side, see shipping and e-invoicing integration; for the build-or-buy decision, see off-the-shelf or custom software.
At Commerslab we build the data flow between ERP, e-commerce and marketplaces, delivered with a reconciliation and alerting layer. See our system integrations service or get in touch about your current setup.
