Every store that syncs inventory and pricing from another system eventually has the same conversation. Somebody sold something that was not in stock, or a customer paid last month’s price, and the question is whether the sync is broken.
The sync is almost never broken. Broken syncs are obvious and get fixed within a day. What actually happens is drift — small, quiet divergences that accumulate in the gaps between systems that were each working exactly as designed.
Drift is a timing problem before it is a data problem
The ERP is right at the moment it exports. The store is right at the moment it imports. In between there is a window, and everything that happens in that window is invisible to one side or the other.
If the sync runs nightly, the store spends up to twenty-four hours confidently displaying yesterday’s truth. That is fine for a slow-moving catalogue and disastrous for anything with a fast seller, because the fast seller is precisely the item that empties inside the window.
The useful question is therefore not “how often does it sync?” but “how much can change between syncs, and for which products?” The answer is rarely uniform, and treating the whole catalogue with one frequency is what creates the visible failures.
Sync the fast movers differently
A tiered schedule solves most of it. The top few per cent of products by velocity get frequent updates — hourly, or event-driven if the source can push. Everything else stays on the overnight run.
This is much cheaper than it sounds, because the fast movers are a short list and the API cost scales with rows rather than schedules. It also means the nightly job stays a single predictable batch rather than becoming a continuous trickle that is hard to reason about when something goes wrong.
The tier list is not permanent. It gets rebuilt from actual sales data every quarter, because the products that move fast in November are not the ones that move fast in May.
Decide who owns each field
Most drift I have traced came down to two systems both believing they owned the same field.
Somebody edits a price in the store admin because it is faster than raising a request. The next sync overwrites it. They edit it again. Now there is a weekly ritual of re-applying an edit that a machine removes overnight, and nobody has written any of this down.
- Stock quantity belongs to the system that physically counts things. That is the warehouse, never the store.
- Cost and list price belong to the ERP.
- Promotional price, product copy, images, and categories belong to the store — and the sync must be built to leave them alone.
- Anything genuinely shared needs a written rule about which side wins, because at some point the two will disagree.
That ownership map is a one-page document and it prevents more incidents than any amount of monitoring.
Make failure loud
A sync that fails silently is worse than one that does not run, because the store keeps serving stale data with total confidence.
Three things belong in every job. A record of what ran and when, so “did it sync?” has an answer. A count of rows changed, because a run that updates zero rows on a Tuesday is a failure wearing a success message. And a threshold alert — if a run tries to change more than some large fraction of the catalogue, it should stop and ask, because that pattern is what a truncated export file looks like.
The threshold check is the one that saves you. A malformed feed that sets four thousand products to zero stock will otherwise apply cleanly and take the store offline in a way that looks like a business problem rather than a data one.
Reconcile on a schedule, not after a complaint
Monthly, I pull stock and price for the whole catalogue from both systems and compare them. Not a sample — everything.
The output is a list of mismatches, and the list is never empty. What matters is the shape of it: a handful of scattered rows is normal noise, while a cluster in one category or one supplier is a rule that is wrong. Finding that pattern in a reconciliation report costs an hour. Finding it because a customer ordered something that does not exist costs considerably more, and it costs it in trust.
What this is really about
Sync is usually treated as plumbing — connect it once, forget it. But it is the mechanism by which the store tells customers the truth about what it has and what it costs, and truth decays without maintenance.
Tier the schedule, write down who owns each field, make failure noisy, and reconcile before anyone complains. None of that is technically difficult. It is just work that nobody assigns until after the first incident.
