Noch immer Kundenduplikate bereinigen? Wie Kundenintegration zwischen Webshop und ERP funktioniert

Every order carries a customer. Without a connection between the webshop and the ERP, that customer gets re-entered slightly differently, until Anna Svensson, A. Svensson, and Anna Svensson AB sit in the register as three different people. This article covers why customer registers drift into duplicates, what duplicates cost, and what happens when customer sync takes over.

How one customer becomes three records

The pattern needs no bad intent - only two systems and a keyboard. A customer orders in the webshop, and their details need to exist in the ERP for the invoice. Whoever transfers them types what they see: sometimes the full name, sometimes an initial, sometimes the company name from the billing address. The webshop lets the same person check out with a new email or a mistyped postcode.

Do this for a few hundred orders and the register fills with near-duplicates: same person, three spellings; same company, with and without the AB; same household, two email addresses. Each record looks legitimate on its own. Together they're a register that no longer answers the basic question - who are our customers?

What duplicates cost

Duplicates read as a cosmetic problem, which is why they survive. The costs are structural:

• Order history splits. A returning customer's purchases scatter across their copies. Nobody sees the full relationship - not support looking up an order, not sales sizing a customer, not the loyalty logic deciding who's a regular.

• Invoices attach to the wrong version. Payments and open balances spread across records. The customer who has not paid has - on their other copy. Reminder letters go out to people who owe nothing.

• Reports quietly lie. Every report that groups by customer counts one person three times. Customer counts inflate, average order values deflate, and repeat-purchase rates - the metric SMB ecommerce lives on - read lower than reality.

• And the classic ending: someone eventually gets assigned the cleanup project, merging records by hand, months of drift at a time. The project fixes the register; it doesn't fix the process that filled it.

What customer sync does

With an integration platform between the webshop and the ERP, the customer on an incoming order stops being a data-entry task:

1. The order arrives with its customer data - billing and shipping addresses, contact details, exactly as the webshop captured them.

2. The register is checked before anything is created. The incoming customer is matched against existing records in the ERP.

3. Matched to the existing customer - created only if genuinely new. A returning customer's order attaches to the record that already holds their history. A first-time customer gets one clean record, created once.

4. One customer, one record, whole history. Orders, invoices, and balances accumulate where they belong, and reports group by people instead of by spellings.

Whether incoming customers match to existing records or always create new ones is a configuration choice, not custom development. The point isn't that one policy fits everyone; it's that the register follows a policy instead of a keyboard.

Where it gets harder

The honest caveats:

• Matching is only as good as the data. A customer who genuinely uses two email addresses may still legitimately exist twice - sync prevents the duplicates that manual re-entry creates, not every ambiguity in real-world identity.

• Existing duplicates don't merge themselves. Sync stops the register from getting worse from day one; the historical cleanup, if the drift has been running for years, remains a one-time project. Doing it before connecting the systems is the right order of operations.

• B2B adds a layer. Company customers carry organization numbers, multiple contacts, and separate billing entities - usually an advantage, since an org number is a far better matching key than a spelled name, but worth configuring deliberately.

What this means in practice

A customer register is the one dataset in an ecommerce business that only degrades under manual maintenance - every hand-typed transfer is a new chance for the same person to become a new record. Matching at the moment of order sync is the cheapest possible intervention: it happens once, automatically, at the exact point where duplicates are born.

If your register already has an Anna Svensson problem - or if you'd rather never find out - the question is the one this series keeps asking:

Check if your webshop and ERP are already connected: junipeer.io/integrations