Still retyping product data? How article sync between webshop and ERP actually works

The manual routine

Every product a merchant sells lives in at least two places. The webshop — Shopify, WooCommerce, Magento, Centra — needs it to sell it. The ERP or business system — Fortnox, Visma, Business Central, Specter — needs it to book it, purchase it, and count it.

Without an integration, ‘lives in two places’ means ‘gets typed twice.’ A new product is created wherever the work starts — often the business system, where purchasing happens — and then re-entered in the webshop: name, SKU, price, description. For a shop launching a handful of products a year, it’s a chore. For one launching collections, seasonal ranges, or a growing assortment, it’s a recurring data-entry job with a deadline attached to every launch.

The real cost is drift

The retyping seems like the small problem. The expensive one is what happens after: two catalogs, maintained by hand, slowly stop agreeing.

A price gets updated in the ERP but not in the shop — and the shop sells at the old price until someone notices. A SKU gets a typo on one side — and from that day, stock counts and order rows for that product match nothing. A description gets improved in the webshop — and the change lives only there, invisible to whoever maintains the master data.

None of these failures announces itself. Drift is silent by nature: each mismatch sits quietly until it surfaces as a wrong price on an order, a stock level that can’t be right, or an hour of detective work at inventory time. The research cited earlier in this series — Politecnico di Milano’s study of SMBs running disconnected systems — put the error rate of manual data entry at 3–5%. On a catalog of a thousand articles, that’s not a rounding error; that’s dozens of products quietly wrong.

One catalog needs one owner

Before any sync, there’s a decision: which system owns the product truth?

There is no universal answer. For some merchants the ERP is the master — products are born in purchasing, and the webshop is a sales channel that follows. For others the webshop is where products are created, enriched, and priced, and the business system follows for bookkeeping and stock. Both models are legitimate; what breaks things is not choosing — two systems where anyone might edit anything is how drift becomes policy.

This is why direction is a first-class setting in article sync, not a rebuild. The same flow runs ERP-to-webshop for one merchant and webshop-to-ERP for the next — a toggle, per flow, decided during onboarding.

What article sync actually does

With an integration platform between the systems, the product catalog becomes a synchronized flow:

1. A product is created or updated in the master system. Whichever side owns the truth — the event is the same: something about an article changed.

2. The change is picked up automatically. Depending on the systems involved, by event or on a schedule — most webshops push, most business systems are polled.

3. The article is created or updated in the other system, matched on SKU. The SKU is the key that ties the two catalogs together — which is also why SKU discipline matters: the sync is exactly as reliable as the identifiers it matches on.

4. One catalog, kept in agreement. New products appear where they need to; changes propagate instead of waiting for someone to remember them.

Where it gets harder

The honest caveats, as usual in this series:

New products don’t have to go live automatically. A business system’s article register usually contains more than the webshop should show — components, internal articles, discontinued items. That’s why synced products can be configured to arrive in the webshop as drafts or disabled, for someone to review and publish. The sync moves the data; the merchandising decision stays human.

SKU hygiene is a precondition. Duplicate SKUs, or identifiers with characters one system doesn’t accept, are the classic reasons an article fails to match or sync. An integration surfaces these as errors — which, in practice, often makes it the tool that finds catalog problems that were already there.

Rich content has limits. Names, prices, and identifiers sync cleanly. Heavily formatted descriptions, images, and channel-specific content vary more between platforms — what transfers depends on the pairing, and webshop-side enrichment often remains webshop work.

What this means in practice

Product data is the definition of information that should be entered once and propagated — it’s structured, it’s rule-bound, and every manual copy of it is a future mismatch. The catalog doesn’t get easier to maintain as it grows; it gets synchronized or it drifts.

If new products in your company still mean typing the same fields into two systems — or if you’ve ever found a price that didn’t match between the shop and the books — the question is the one this series keeps asking: