Customer Data Integration: What Happens When Records Disagree?

To match customers across sales, service, communications and finance, use verified links between records or matching rules tested on your actual data. When records disagree, use the approved source for each field, preserve distinct facts such as billing and service addresses, and send uncertain identities or disputed claims for review. Keep source references and correction history so the next sync does not undo an approved decision.

Sales has one customer address. The service team has another. Accounting has a different company name. Your email platform says the customer unsubscribed, but the CRM still says they're subscribed.

You connect the systems. Now which version gets copied everywhere?

That question belongs at the beginning of an integration project. Without an answer, automation can spread a bad record faster than your team can fix it.

Customer data integration connects customer information across your systems so teams can use it reliably. That requires rules for identifying the customer, choosing the right value for each field, preserving meaningful differences and carrying corrections to the places that need them.

The practical test is simple: when two systems disagree, can your business explain what happens next?

What does customer data integration connect?

Customer data integration connects an organization or person to the relevant sales accounts, service locations, communications and billing records. A shared customer view should preserve these relationships so each team can find the information it needs.

Consider a company that manages several commercial properties.

A salesperson creates an account in the CRM after speaking with the facilities manager. Operations creates a customer and several service locations when the contract starts. The billing team creates an account under the legal name on the agreement. Your communications platform stores the people who receive reminders and marketing emails.

Each team has recorded something useful. Each also means something slightly different by “customer.”

Sales

• What it needs to know: Who is buying, what they need and who owns the relationship
• A distinction worth preserving: A prospect, an active account and a former customer have different meanings

Service

• What it needs to know: Where work happens and who can approve or coordinate it
• A distinction worth preserving: One company can have several locations and different contacts at each

Communications

• What it needs to know: Who receives which messages, through which channel
• A distinction worth preserving: A working email address does not establish permission for every message

Finance

• What it needs to know: Which entity owes money, where invoices go and what has been paid
• A distinction worth preserving: The billing entity may differ from the property name or day-to-day contact

Trying to compress all of this into one name, one address and one email creates conflicts that do not need to exist.

A useful shared customer view connects the company, its contacts, its locations and its billing accounts. It keeps those relationships visible without pretending they are all the same record.

How do you know two records belong to the same customer?

Match customer records using verified links between source accounts or a tested combination of identifiers for the same entity type. A similar name, shared phone number or company domain alone should trigger a candidate match for review, not an automatic merge. This process is called identity matching or identity resolution.

Start by deciding which kind of entity you are matching. Two contacts working for the same company are related. They are not duplicates. Two subsidiaries with the same parent company may need separate billing accounts.

Then decide which evidence is strong enough for each action.

An established link between a CRM account and an accounting account is stronger evidence than a similar company name. An exact phone number can help, but a shared office number does not identify one person. A matching address may identify a building with many tenants.

I would start with these rules and test them against the business's actual records:

A previously verified link between records, within the correct business account and entity type

• Recommended action: Reuse the link unless new evidence contradicts it

Several consistent identifiers, no meaningful conflict and a rule validated on representative records

• Recommended action: Allow an automatic link for the approved use case

A similar name, shared domain, shared phone or address alone

• Recommended action: Suggest candidates for review

Two plausible matches, conflicting verified identities or a prior decision that the records are separate

• Recommended action: Hold the link and route it for review

No reliable candidate

• Recommended action: Keep the record unlinked or create a provisional identity under a defined rule

“Unlinked” is an acceptable outcome. The integration should not invent certainty because a workflow wants an answer.

This matters when one identifier connects many people. Twilio's Segment documentation describes how a shared device can cause unrelated profiles to merge without protective identity rules. The business equivalent could be a shared office phone or a generic inbox.[1]

For billing, account access and private communications, I would favor avoiding incorrect matches over eliminating every duplicate immediately. The cost of leaving two records separate can be much lower than attaching one customer's invoices to another customer's account.

Which customer fields should you merge, preserve or send for review?

Consider two customer records for Harbor Facilities. Sales uses one to manage the relationship. Service and finance use the other to coordinate work and collect payment.

Customer name

• Sales record: Harbor Facilities
• Service and billing record: Harbor Facilities Management LLC

Source reference

• Sales record: CRM account C-1042
• Service and billing record: Service account S-882; finance account F-209

Contact

• Sales record: Maya Chen, facilities manager
• Service and billing record: Luis Ortega, accounts payable

Email

• Sales record: maya@harbor.example
• Service and billing record: ap@harbor.example

Address

• Sales record: 85 River Street, service property
• Service and billing record: 240 King Street, billing office

Payment terms

• Sales record: Net 30, entered by sales
• Service and billing record: Net 45, approved by finance

Open balance

• Sales record: $0, from an older import
• Service and billing record: $18,400, from current accounting data

Maya's marketing email preference

• Sales record: Subscribed, imported July 1
• Service and billing record: Unsubscribed July 18, recorded by the email platform

Record last updated

• Sales record: August 20
• Service and billing record: August 14

The similar names do not establish that these accounts are the same customer. First, a reviewer checks the agreement and account setup records and confirms that all three source references belong to the same organization. If that cannot be established, the accounts stay separate.

Once the identity is confirmed, here is how I would resolve the fields.

Should you merge or link duplicate customer accounts?

For confirmed duplicates across applications, link the source accounts to one internal customer identity and retain each application's reference. In the Harbor Facilities example, CRM account C-1042, service account S-882 and finance account F-209 would all point to the same organization. Those references let future updates reach the correct accounts.

This does not require deleting the original accounts. Connecting them can provide a shared customer view while each application continues to do its job.

Should different customer contacts and addresses be preserved?

Preserve customer contacts and addresses when they serve different roles. A billing address and a service address can both be correct, just as a facilities manager and an accounts payable contact can both belong to one customer.

Use the verified legal name for billing. Preserve “Harbor Facilities” as a display name or alias.

Keep Maya as the facilities contact and Luis as the billing contact. Keep both email addresses with their roles.

Keep 85 River Street as a service location and 240 King Street as the billing address.

None of these differences needs a winner. They represent different facts.

Which values should win when sales and finance disagree?

Use finance's approved Net 45 terms for billing. Preserve the sales entry as history and flag the disagreement for the account owner if it affects a commitment made to the customer.

Display the accounting system's $18,400 open balance with its retrieval time. Do not average it with the CRM value or add the two together. Both values claim to describe the same balance, and the older imported value is stale.

The sales record's August 20 update does not make every field in that record more accurate. Someone may have changed a note that day while leaving the old balance untouched.

What if one system says subscribed and another says unsubscribed?

When a trusted unsubscribe follows an older subscription record for the same person or address, channel, brand and purpose, preserve the unsubscribe under the applicable policy. An older import should not restore permission. In the Harbor Facilities example, Maya's marketing email stays suppressed.

That decision applies to the relevant person or address, channel, brand and purpose. It does not establish Luis's preferences or decide whether a particular service notice can be sent.

A later, verified subscription request could change the result for that same scope. A routine sync is not such a request.

Which customer data conflicts require human review?

If finance's legal name conflicts with a newly signed agreement, do not quietly replace it. Send the conflict to the team responsible for verifying the contracting entity.

If a second Harbor company shares the same inbox, do not merge it into this account without establishing the relationship.

The outcome is one connected customer view with several preserved facts, a few selected values and a clear route for unresolved decisions.

Which system should be the source of truth for customer data?

Assign the source of truth by field and verification process. A practical starting point is the CRM for account ownership, accounting for balances and approved payment terms, service operations for location details, and a documented preference policy for communications. Each authority needs a route for reviewing and correcting mistakes.

“The CRM is our source of truth” leaves too much unanswered.

Write down ownership at the field level. Include the people responsible for exceptions.

Account owner and sales stage

• Example authority: Sales operations in the CRM
• How another system should handle a disagreement: Propose a change through the sales process

Legal billing identity and approved terms

• Example authority: Finance's verified account setup
• How another system should handle a disagreement: Hold conflicting changes for finance review

Open balance and payment status

• Example authority: Accounting records
• How another system should handle a disagreement: Refresh the value; show its freshness

Service address and access instructions

• Example authority: Service operations
• How another system should handle a disagreement: Verify the location and update affected future work

Contact details and roles

• Example authority: The approved contact-verification process
• How another system should handle a disagreement: Retain context and verify competing claims

Communication preferences

• Example authority: Documented preference policy using trusted events
• How another system should handle a disagreement: Apply the rule for the exact scope; preserve the evidence

Assign ownership to the team with the process and evidence to verify each field.

Ownership also needs a correction process. A field can be wrong in its designated source. Other teams should be able to challenge it without silently overwriting it.

For each important field, define who can change it, what counts as evidence, where the change should travel and what happens if two valid updates conflict.

How should customer integrations handle consent and communication preferences?

A single marketing_allowed checkbox cannot describe every communication decision.

At minimum, preserve who or which address the preference concerns, the channel, the purpose, the relevant brand or business, when it was recorded, where it came from and the evidence supporting it. Keep withdrawals and any later verified changes in the history.

Do not treat a blank field as permission. Do not transfer a person's subscription to a coworker because their accounts were merged. Do not assume permission for one channel covers another.

In its UK GDPR guidance, the Information Commissioner's Office explains that consent records should show who consented, when, how and what they were told, along with withdrawals.[2]

The integration's job is to preserve enough context to apply the business's approved communication policy. It should not create new permission by combining records.

What should happen when a customer match is ambiguous?

When customer records have multiple plausible matches or conflicting verified identities, hold the proposed link and send it for review. Keep the records separate until there is enough evidence to approve the match. Unaffected work can continue on existing, verified records.

A review queue needs more than a list of possible duplicates.

A reviewer should see the candidate records, the evidence for the match, the conflicting fields and what approving the decision would change. Attaching a note and changing an invoice recipient are different levels of consequence.

Give the reviewer explicit choices:

• Link the records as the same entity.
• Keep them separate and record why.
• Mark them as related entities, such as a parent and subsidiary.
• Request more evidence.

Store the decision so the next import does not reopen the same question without new evidence. Record who decided, when and which records were affected.

Meanwhile, let unaffected work continue. An unresolved identity may prevent account consolidation without preventing a service team from working on an existing, verified job.

How do you keep customer data corrections from being overwritten?

Record where each approved correction came from, apply the field ownership rules, and track delivery to every destination that needs the change. Repeated or stale updates should not overwrite the approved value. Failed deliveries need a visible retry or review process.

Suppose finance verifies a new billing address.

The integration updates the approved customer profile and sends the address to the systems that need it. The service locations remain separate. Historical invoices follow the accounting system's correction process rather than being silently rewritten.

Then an old export arrives with the previous billing address.

If the integration treats the last message received as the newest truth, yesterday's mistake comes back.

Delivery order is not a safe substitute for authority or freshness. Stripe, for example, documents that webhook events can arrive out of order and can be delivered more than once.[3]

For a correction to hold, the integration needs to retain its source and decision history, recognize repeated updates, and prevent stale copies from replacing approved values. It also needs to show which destinations accepted the correction and which still need attention.

A successful update in one system is not proof that the correction reached all of them.

Mistaken matches need a recovery process too. Preserve enough history to separate the records, restore their relationships and identify downstream changes that require repair. Deleting one record immediately after a merge makes that much harder.

What should you ask a customer data integration provider?

Ask the provider to demonstrate the messy cases using representative records from your business:

1. Two customers share a phone number. What prevents a false match?
2. One company has several locations and billing accounts. Which stay separate?
3. Sales and finance disagree on payment terms. Who decides?
4. A customer unsubscribes, then an older file is imported. What happens?
5. A correction reaches three systems and fails in the fourth. Who sees that failure?
6. Someone approves the wrong merge. How is it reversed, and what needs repair?

An existing connector may handle the workflow if it supports the matching, ownership and exception rules you need. Custom logic becomes relevant when those decisions exceed the connector's capabilities. The choice should follow the rules your business requires.

Start with one complete journey, such as a signed customer becoming a service account and then receiving an invoice. Measure incorrect matches, unresolved reviews, repeated duplicates and corrections that failed to reach their destinations.

That gives you a concrete way to judge whether the integration works: the right people receive the right information, and your team can explain and correct the exceptions.

How can Cass & York help with customer data integration?

Cass & York designs and builds software for complex workflows, disconnected systems and processes that have outgrown spreadsheets and manual work.

If your teams keep correcting the same customer information, bring that workflow to a call. We can trace where the records originate, identify who should own each field and define how conflicts should be handled before deciding what to connect or build.

Book a Workflow Call with Cass & York

Sources

1. Twilio Segment: Identity Resolution Settings. Shared identifiers and safeguards against incorrect profile merges.
2. Information Commissioner's Office: How should we obtain, record and manage consent?. UK guidance on recording and managing consent.
3. Stripe: Receive Stripe events in your webhook endpoint. Event ordering and duplicate deliveries.