What Actually Breaks When Two Systems Sync Customer Data

Connecting two systems always sounds simple. Your store has customers, your accounting package has customers, and both should agree. Then the sync goes live and somebody gets invoiced twice, an address change disappears overnight, and a customer who unsubscribed keeps receiving email.

None of this is exotic. The same handful of problems show up on almost every integration project, and they are all predictable. Here is what actually breaks when two systems share customer data, and what a reliable setup does differently.

The Root Problem: Two Systems, Two Definitions

Your store thinks a customer is an email address with orders attached. Your accounting system thinks a customer is a billing entity with a tax status. Your email platform thinks a customer is a subscriber with a consent record. These are three different things wearing the same name.

Most integration failures trace back to that mismatch. The software is doing exactly what it was told. It was told to treat three different ideas as one.

What Actually Breaks

Duplicate Records

The same person buys as [email protected] on Tuesday and [email protected] on Friday, or their name arrives as Sarah Jones once and SARAH JONES the next time. Without a rule for what makes two records the same person, you get two customers, split order history, and reporting that quietly undercounts your repeat business.

Duplicates are worse than they look, because the damage compounds. Once the second record exists, half the updates go to one and half to the other, and neither is complete.

Fields That Do Not Exist on Both Sides

One system stores a single name field, the other splits first and last. One allows a second address line, the other does not. One has a purchase order number your invoices depend on, and the other has nowhere to put it.

Something has to give, and if nobody decides what, the integration decides for you. Usually it truncates the data or drops it silently, and you find out when a delivery goes to an incomplete address.

Updates That Overwrite Each Other

A customer updates their address on your store. Someone on your team updates the same customer in the accounting system an hour later, working from an old email. The sync runs, and whichever change arrived last wins.

This is the most common cause of the complaint that an integration keeps undoing work. Nothing is broken in the software. There are simply two sources of truth for one field, and no rule about which should win.

Deletes, Merges, and Unsubscribes

Delete a duplicate in one system and the sync may recreate it from the other within the hour. Merge two records and the merged history may not carry across. Mark someone as unsubscribed in your email platform and an eager sync may reinstate them from a store record that still says otherwise, which is a compliance problem rather than an inconvenience.

Deletions need explicit handling, because most integrations are built around creating and updating, and treat an absent record as nothing to do rather than as something to remove.

Dates That Shift by a Day

One system stores dates in your local time, another stores everything in a single global standard, and a third stores a plain date with no time attached. Convert between them carelessly and an order placed late in the evening lands on the previous day, or the next one.

It looks trivial until it lands on a month boundary. Then a sale falls into the wrong month, your reporting disagrees with your accounts, and someone spends a day proving which number is correct.

Tax and Rounding That Do Not Agree

Stores often calculate tax per line item, while accounting systems calculate it on the invoice total. Both are defensible, and they produce answers that differ by a cent or two. Multiply that across a month and the two systems no longer reconcile, which is exactly the situation your accountant will want explained.

Decide which system is authoritative for tax before you connect anything, and make the other one follow rather than recalculate.

The Sync That Quietly Stops

This is the expensive one. A credential expires, a service has an outage, or an update changes an interface, and the sync stops. Nothing announces it. Orders keep arriving and the other system keeps looking normal, just increasingly out of date.

Most teams discover this weeks later through a downstream symptom: a customer chasing an invoice that was never raised, or a report that looks wrong. By then there is a backlog to reconcile by hand.

Volume Limits and Half-Finished Runs

Most services cap how many requests you can make in a period. A quiet week never hits the limit. A busy week or a first full import does, and the run stops midway. Half the records are updated, half are not, and unless the process is built to resume safely, running it again can duplicate the work it already did.

Recurring Orders Make Everything Harder

Subscriptions and standing orders deserve their own warning, because renewals are often created by a different part of the system than checkout, and can store their details in a different shape.

Automation that was written and tested against normal orders can skip renewals entirely, without any error. Everything looks healthy, and one category of orders is quietly missing from the process. We wrote about a version of that problem in a fulfillment case study, where renewal orders stored their shipping details differently from one-time orders and were passed over for months.

Why It Usually Gets Built the Fragile Way

Almost nobody sets out to build a brittle integration. It happens because the first version is a favor. Someone needs orders in the accounting system, a connection is set up in an afternoon, it works, and everybody moves on.

That first version has no logging, because nothing had gone wrong yet. It has no matching rule, because the ten test customers were all distinct. It has no alerting, because the person who built it was watching it that week. Then the business grows, the volume goes up, staff change, and the quiet assumptions underneath it start to matter.

This is worth knowing because it changes the question you ask a developer. Not can you connect these two systems, which is almost always yes, but what happens to this connection when nobody is watching it for six months.

What a Reliable Sync Looks Like

The patterns that hold up are unglamorous.

One system owns each field. Decide which system is authoritative for addresses, which for billing details, which for consent, and write it down. One direction where possible: two-way sync doubles the ways things can conflict, and half the time nobody actually needed it.

A real matching rule. Decide what makes two records the same person, apply it consistently, and handle the cases it cannot decide by flagging them for a human rather than guessing.

Failures that are loud. Every sync should log what it did and alert someone when it stops. The goal is that you hear about a problem from your own system, not from a customer.

Safe repeats. Running the same job twice should not create a second copy of anything. That single property prevents most cleanup work after an outage.

A record of what happened. When something looks wrong three weeks later, you need to see what was sent, when, and what came back. Without that, diagnosis becomes guesswork, and the usual outcome is rebuilding something that only needed a small fix.

How to Test It Before You Trust It

The most common testing mistake is checking that a record arrives. That proves the connection works on a good day, which was never the question. The question is what happens on a bad one.

Test with your real mess, not with tidy sample data. Use the customer who has two email addresses, the order that was refunded, the address with an apartment number, the name with an apostrophe, the subscription that was paused and resumed. Those records already exist in your system, and they are the ones that break things.

Then test the failures on purpose. Turn off the connection halfway through a run and see what state you are left in. Send the same record twice and confirm you do not end up with two. Let a credential expire and check that somebody actually hears about it. An integration that has never been tested against failure has not been tested.

Questions to Answer Before Connecting Anything

Which system is the source of truth for each piece of customer data? What makes two records the same person? What happens when a record is deleted in one system? Who is told when the sync stops, and how? What happens on your busiest day, when volume is ten times normal?

If a vendor or developer cannot answer those five questions, the integration is not designed yet. That is not a reason to avoid connecting your systems. Manual re-entry has a failure rate too, and it is higher than most teams think. It is a reason to treat an integration as a piece of software that needs design and testing, not a switch you flip.

It also pays to check what you already have. Many stores run several overlapping tools that each solve part of the problem, which is worth reviewing before adding another. If you want a view of how your systems currently fit together, that is part of what our integrations work covers, and it is often where a site audit starts.

Frequently Asked Questions