Key takeaways
- Decide which system owns each data type, and never let two systems own the same field.
- Design for failure: retries, idempotency and a queue for errors.
- Reconcile on a schedule so drift is caught in hours, not at month-end.
- Monitor the integration like a production system, with alerts and an owner.
Where sync problems show up
A customer buys the last unit of a product that the warehouse sold an hour ago. A promotional price appears in the store but the invoice uses the old one. An order sits in the store as paid while the ERP never received it. Each of these is a small event, but together they generate refunds, support tickets and finance corrections. They all come from the same place: the integration between the e-commerce platform and the ERP was built to move data, not to keep it consistent.
Give every data type one owner
The first design decision is which system is the source of truth for each kind of data. Conflicts arise when two systems can both change the same field.
- Products and pricing: usually the ERP or a product information system, with the store consuming it.
- Stock levels: the ERP or warehouse system, since it sees receipts, transfers and adjustments.
- Orders and payments: created in the store, then handed to the ERP for fulfillment and accounting.
- Customer accounts: choose one master and map the identifiers between systems.
Write this down in a simple table and share it with both teams. Exceptions, such as a store-only promotional price, should be explicit and documented instead of discovered later.
Design for failure, because failure will come
Networks time out, APIs return errors and vendors have maintenance windows. An integration that assumes every call succeeds will eventually lose or duplicate data. Build in a few basic protections.
- Idempotency: sending the same order twice must not create two orders. Use a stable unique key for each order and each update.
- Retries with backoff: transient errors should retry automatically, with a limit.
- A dead-letter queue: messages that keep failing go to a place where a person can inspect and reprocess them.
- Ordering rules: if updates can arrive out of order, use timestamps or version numbers so an older update never overwrites a newer one.
Handle stock with a buffer and clear rules
Real-time stock across systems is hard, and small delays are normal. Many teams add a safety buffer on fast-moving items, or reserve stock when an item enters a cart or when an order is placed, and release it if payment fails. Decide how to treat items in transit, returns awaiting inspection and stock held for other channels. Whatever the rule, make it explicit so the store and the warehouse agree on what available means.
Reconcile on a schedule
Even a well-designed sync drifts. Run automated comparisons between the two systems and report the differences.
- Compare stock by item and location, and flag differences above a tolerance you choose.
- Compare prices for active items and any active promotions.
- Match orders in the store to orders in the ERP by status, and list any missing or stuck ones.
- Compare paid amounts in the store with what finance sees from the payment provider.
Daily is a good starting rhythm. The goal is to catch drift in hours, while the cause is still fresh, instead of finding it when finance closes the month.
Treat the integration as a product
Give the integration an owner, documentation, alerts and a runbook for common failures. Log every message with its identifiers so support can trace an order end to end. Test changes in a staging environment with realistic data, and review the integration before every peak trading period. When either platform is upgraded, retest the interface, since small changes in fields or limits can quietly break it.
