Your ERP says there are four of an item in stock. Magento says eleven. A customer buys the eleventh, and three days later somebody on your team is writing an apology and processing a refund.
Most owners file that under IT. It is a revenue problem that happens to be technical, and on a connected store it is almost never one big break. It is a handful of small seams, each failing quietly and in its own way, and the business only sees the last one in the chain.
Here is where they actually fail, based on running this setup in production rather than on a diagram.
Catalog and attributes. The ERP owns product data, Magento owns how it renders. When an attribute changes shape on the ERP side, or a category tree is reorganised without anyone telling the store, products stop appearing in the right places. Nothing errors. The catalog just quietly gets thinner.
Stock. The one everyone knows about, and still the one that costs the most. Sync lag, partial imports and silent failures all produce the same symptom: numbers that were true an hour ago.
Order export. Orders that reach Magento but never land in the ERP are worse than orders that fail loudly, because the customer has already paid and nobody is looking for them.
Store and pickup data. For anyone running physical locations alongside the site, store addresses, pickup points and per-location availability are a separate feed with its own failure modes. Duplicated locations and stale availability turn self-pickup into a promise you cannot keep.
Checkout is not on that list, and deliberately so. It fails for its own reasons, and one of them is that it sits downstream of all four.
The clearest measurement of this does not come from ecommerce at all. It comes from physical retail, where the same problem has been studied properly.
ECR Retail Loss ran a three-year project with seven of Europe's largest retailers, published in July 2020, covering roughly a million SKUs across about a hundred stores using a test-and-control design. Two findings matter here. About 60% of the SKUs examined carried inventory record inaccuracies. And correcting those records lifted sales by roughly 4% to 8%.
Two caveats worth keeping, because they change how you should read it. The study measured stock counts in physical stores, not ERP-to-store synchronisation, and the data is five years old. What transfers is the principle rather than the percentage: inaccurate stock records are not an operational annoyance with a cost of zero. They suppress sales by a margin large enough to show up in the annual figures.
The study also found something counterintuitive. Errors in the positive direction, where real stock exceeds what the system believes, were as common as errors in the negative direction, and both hurt. If your ERP undercounts, you stop selling things you have.
IBM's explainer on the subject sets out the three standard approaches: point-to-point, an enterprise service bus, and integration platform as a service. The taxonomy is right. What it does not tell a store owner is which bill arrives when.
Point-to-point is a direct custom connection. Cheapest to build, and entirely reasonable when you have one ERP and one storefront. The cost is deferred: every new channel, marketplace or warehouse adds another line, and someone has to maintain all of them.
Middleware, or an ESB, puts a translation layer in the middle. It earns its keep once you have several systems that disagree about data formats, and it is usually the honest answer for a retailer with a legacy ERP that is not going anywhere.
iPaaS is the cloud version, with prebuilt connectors and less code to own. It scales well and suits SaaS-heavy stacks. The trap is assuming prebuilt means configured. A connector that maps ninety percent of your catalog correctly still leaves you reconciling the other ten by hand.
Our own view, from the projects we inherit rather than the ones we start: most mid-sized Magento stores do not have an architecture problem. They have an ownership problem. The integration was built once, by someone who has left, and nobody has looked at its error log since.
We keep this running for A-Shop, a Ukrainian omnichannel retailer where online sales, physical store availability and a 1C ERP all have to agree on a large, fast-changing catalog. We re-platformed them from end-of-life Magento 1 to Magento 2 in three months, which included re-implementing the ERP integration rather than porting it.
Where it stands now: 98% sync accuracy across stock, catalog and orders, and zero order-blocking checkout faults over the last twelve months.
That second number is the one worth explaining. It is not a claim that nothing ever goes wrong. It means the failures that remain surface somewhere other than the moment of purchase, which is a design decision about where you put your checks, not a matter of luck.
Ask for the integration's error log. Not a report, the actual log. If nobody can produce one, or it has been filling up unread, that is your finding and you have it in an afternoon.
Then pick the seam that is costing you most right now and instrument that one properly before touching anything else. Catalog drift and stock drift look identical from the customer's side and need completely different fixes.
Finally, be honest about which of the three integration approaches you are actually on. A lot of stores describe themselves as running middleware when what they have is six point-to-point connections and a naming convention.
If your product data is the part that keeps drifting, the upstream question may not be the integration at all, and a PIM is worth understanding before you spend money on connectors.
We spend most of our time inside Magento stores where the ERP connection was built years ago and has been quietly degrading since. If yours has reached the stage where people keep a spreadsheet to correct it, an audit of where the two systems actually disagree usually pays for itself before any code gets written. That is the work we do through system integrations and Magento development.
Let’s build something powerful together - with AI and strategy.
