Your CRM and Ross are describing two different customers

Sales lives in the CRM — Salesforce, usually, though it might be HubSpot or Microsoft Dynamics. Ross is the system of record for orders, credit, and what the customer actually owes. Both are describing the same customer, and they don't agree. Sales promises a delivery date operations can't hit. Someone quotes a price that expired last quarter. A rep tells a customer their account is in good standing while Ross is quietly sitting on a credit hold. And the customer — this is the part that stings — usually notices the seam before you do.

The instinct is to treat this as a data problem: the CRM is missing some fields, let's copy them over. It's worse than that. A CRM that isn't synced to Ross doesn't just lack data — it becomes a confident second source of truth about your customers. Two systems, both sure they're right, disagreeing in public. Fixing it is less about copying fields and more about deciding who gets to be right about what.

What actually needs to sync

Not everything, and that's the first useful realization. A CRM and an ERP are good at different things and should stay that way — the goal isn't to merge them into one bloated system that's mediocre at both. The goal is that where they overlap, they agree.

The overlap is a short, specific list. Accounts and contacts, so sales and operations are talking about the same entity. Orders, so the CRM knows what was actually placed and Ross knows what was actually promised. Credit and terms, flowing from Ross. And order status, flowing back to sales so they're not guessing. Get those synced and the two systems stop contradicting each other; try to sync everything and you'll build a fragile mess that fights itself forever.

Ross owns the money truth

Here's the rule that resolves most of the arguments before they start: Ross owns the money.

Credit holds, payment terms, balances, order history — these belong to the system of record, and the CRM should defer to it, not improvise. A CRM that lets a rep see and quote credit status is helpful; a CRM that maintains its own idea of credit status is a liability with a friendly dashboard. The most expensive version of this problem is a salesperson confidently telling a customer something about their account that Ross would flatly contradict, because now you've turned an internal data gap into a broken promise. Point the money truth in one direction — out of Ross — and a whole category of embarrassment disappears.

Direction and ownership is the actual hard part

Notice that the difficult questions here aren't technical. They're about ownership. Which system owns the customer's address? Who wins when the CRM and Ross disagree about a contact? If a rep updates terms in the CRM, does that flow to Ross, or does Ross overrule it?

This is where these projects genuinely live or die, and it's why the ones that get handed to a pure integration engineer so often thrash. Deciding which system is authoritative for each field is a business decision dressed as a technical one, and if you skip it, the integration will make the decision for you — badly, at runtime, by whichever update happened last. Settle ownership up front, field by field where it matters, and the build becomes almost boring. Skip it, and you've automated the argument instead of ending it.

The stale-data trap

Even with ownership settled, there's a failure mode worth naming: staleness. A CRM quoting last quarter's pricing. A rep working from a credit status that was true on Tuesday and isn't now. Sync isn't a one-time copy — it's a living connection, and the value evaporates the moment the copy is old enough to be wrong. The customer-facing cost of stale data is a promise made in good faith on bad information, which is somehow worse than being wrong on purpose. So the sync has to be timely enough that sales is acting on today's reality, not a snapshot from whenever the last batch ran.

Start with the workflow, not the field map

The temptation with a CRM-to-Ross project is to open both schemas and start drawing lines between fields. Resist it. Start instead with the workflow: what does a rep do, what do they need to see and change, what does operations need to trust, and what breaks if a piece of information is late or wrong? The field map falls out of the workflow, not the other way around — the same discipline that makes every Ross integration stick, and the same one that gets skipped when the project is scoped by someone counting fields instead of watching people work.

The bottom line

If your CRM and Ross disagree about your customers, you don't have a syncing gap — you have two competing sources of truth and a customer caught in the middle. Sync the overlap, let Ross own the money, settle ownership before you build, and keep the data fresh enough to trust. Do that and sales, operations, and finance finally tell the customer the same story. Which, ideally, is a true one.

Tired of sales and Ross contradicting each other in front of customers? That's an ownership problem with a technical fix, and I do both halves. Let's talk →. Related: Ross ↔ TMS.