It's the most reliable way to lose a room. Marketing reports 4,180 new leads for the quarter; sales ops pulls the CRM and finds 3,510. Nobody can explain the gap, so the meeting spends twenty minutes debating whose number is real — and every report either team brings afterward carries an asterisk.
Here's the uncomfortable truth: both numbers are usually "right." They're just answers to different questions, produced by two systems that were never wired to agree. The gap isn't a reporting problem. It's an architecture problem wearing a reporting costume.
These are the usual suspects, roughly in the order we find them.
1. The sync doesn't cover what you think it covers
Almost no MAP-CRM sync moves everything. There's a sync filter somewhere — only records with an email address, only records matching certain criteria, only records created after the integration went live, only records in certain business units. Whoever configured it made reasonable choices; those choices are now invisible policy.
So "people in the MAP" and "leads in the CRM" are different populations by design. If nobody can state the sync scope from memory, that's finding number one: the definition of who crosses the bridge is undocumented.
2. Sync errors fail silently
The sync that covers the right records can still fail record by record: a picklist value the CRM doesn't accept, a validation rule that blocks the write, a required field the MAP doesn't have, permission changes after a security review. Most platforms retry a few times, log the failure somewhere nobody looks, and move on.
The result is a slow leak. A few records per day fail to cross; nobody notices for a quarter; the gap is now four figures. Sync error queues are the least glamorous report in the stack and the first one we open in an audit — because a sync that's "mostly working" is indistinguishable from a healthy one until you count.
3. Duplicates are counted differently
The MAP typically deduplicates on email address; the CRM lives on leads and contacts, where the same human can legitimately exist twice — or five times, once per business unit that imported them. One system counts people; the other counts records. A 10–15% divergence from duplicates alone is normal in an unmanaged database, and it compounds: dupes also split engagement history, so scoring and attribution disagree too.
Ask both teams "what's the unique key?" and watch the answers differ. That difference is part of the gap.
4. "Lead" doesn't mean the same thing in both systems
In the MAP, a "new lead" might mean any new known person. In the CRM, it might mean a lead record that passed routing rules, wasn't converted, wasn't disqualified, and sits above a threshold. Marketing counts creation; sales counts survival.
This is the definitional layer of the gap, and it's the one that makes the meeting argument unwinnable — because the two numbers aren't measuring the same event. Until lifecycle stages are defined once, in writing, and enforced identically in both systems, the counts describe different funnels that happen to share a database.
5. Deletions, merges, and archiving are asymmetric
Records get merged in the CRM without the MAP being told. Contacts get deleted on one side and live on as ghosts on the other. A data retention job cleans one database on a schedule the other system doesn't share. Every one of these operations changes one count and not the other, and none of them appear in any report as "we changed the denominator."
6. The reports themselves aren't twins
Even with perfect data, the two reports being compared were usually built by different people with different filters: one uses created date, the other uses a lifecycle timestamp; one includes partner-sourced records, the other excludes them; one snapshots monthly, the other queries live. Before debugging the stack, put the two report definitions side by side. Sometimes the gap is two WHERE clauses nobody compared.
How to actually reconcile
The fix isn't a heroic one-time cleanup — it's a short reconciliation exercise followed by structural repairs:
Pick one metric and trace it end to end. Take "new marketable people this month," define it precisely, and build it in both systems with matching filters. Every place the numbers diverge points at one of the six causes above. This takes a day and produces the actual defect list.
Fix the plumbing before the definitions. Clear the sync error backlog, document the sync scope, and stand up a duplicate management process. There's no point aligning definitions on top of a leaking pipe.
Then fix the definitions once. A one-page lifecycle document — what each stage means, which system is the source of truth for each field, what timestamps mark each transition — signed by marketing and sales ops. Enforced in automation, not in memory.
Then monitor the seam. Counts drift back apart because syncs keep failing quietly and new tools keep writing to both sides. A simple weekly check — same metric, both systems, alert on divergence beyond a threshold — turns the next gap from a quarterly ambush into a Tuesday fix.
The real cost of leaving it
Teams live with mismatched numbers for years because no single quarter makes it urgent. But the gap taxes everything downstream: attribution nobody trusts, routing that loses hand-raisers in the seam between systems, board slides with hedged footnotes, and a standing reason for marketing and sales to discount each other's data. The most expensive part isn't the missing records — it's every decision made slower because two teams can't share a denominator.
Reconciling the CRM–MAP seam — sync health, dedupe, lifecycle definitions, and the monitoring that keeps them aligned — is core marketing operations work. Not sure how big your gap is? A stack audit will put a number on it, and the findings are yours either way.