Whitepaper · RevOps & Integration · ~12 min read
When the CRM says one number and the ERP says a different number, the wrong answer is to argue about who is right. Both are right inside their own model of the world. The disagreement is the data showing you that there is no shared model, no canonical owner, and no reconciliation discipline. Fixing that is cheaper, faster, and more durable than any new platform decision.
This paper covers the integration audit framework we use to surface the four common categories of disagreement, name a canonical owner for every entity that matters, and build the reconciliation rhythm that makes the board's number the same number every department reports.
The disagreement is the diagnostic
Most RevOps and IT leaders have lived through the meeting where the CFO asks for the size of the pipeline, and three departments produce three different numbers. Sales says $X. Marketing says $X − 15%. Finance says $X − 30%. Each is convinced the others are wrong. The CFO loses confidence in all three.
The instinct in the meeting is to find the bug. Almost always, there is no bug. Each system is calculating exactly what it was configured to calculate, off the data it has, using the rules its team agreed to use. The numbers are different because the rules and the data are different. Each team is correctly answering a slightly different question.
That is the diagnostic. Treat the disagreement as a signal, not a defect. The signal is telling you which entities lack a canonical owner and which integration boundaries are leaking definitions rather than reconciling them.
The four common disagreement categories
Across every RevOps integration audit we have run, the disagreements cluster into four categories. Naming the category is the first step to fixing it.
1. Definition disagreement
The CRM and the ERP are reporting different numbers because they are computing different definitions of the same word.
- Pipeline. Does it include unqualified leads? Closed-lost reopened? Renewals? Multi-year contract value or first-year only?
- Customer. A customer is one Salesforce Account, one ERP customer record, one parent organization, one billing entity, or one contracting entity, and these rarely line up.
- Revenue. Booked, billed, recognized, collected. Each is a real number. Each is a different number.
This category is the easiest to fix and the most often missed. The fix is a written, versioned data dictionary that names each definition and assigns it to a single canonical system.
2. Timing disagreement
The systems are using the same definition but observing the world at different times.
- The CRM updates opportunity status in real time. The ERP only sees a customer once an order is invoiced.
- Marketing automation reports leads daily. The CRM reports them as the lead-to-opportunity conversion is recorded.
- Finance closes the books on the 5th. RevOps reports the pipeline as of last night.
The fix here is not to force every system onto the same clock, that is impossible and undesirable. The fix is to publish, alongside every reported number, the as-of timestamp and the definition. "Pipeline as of 11:59 ET on November 4, definition v3" is unambiguous. "Pipeline" is ambiguous.
3. Hierarchy disagreement
Different systems disagree about how entities roll up.
- The CRM rolls up Accounts under Parent Account. The ERP rolls customers under a different parent. Marketing automation has its own account hierarchy from a different data source.
- A renewal sits under the original account in the CRM and under a renewed contract entity in the ERP, and the two never reconcile.
- A multi-business-unit customer is one entity in finance, three in sales, and seven in marketing.
The fix here requires a master-data discipline: an Account Master that is the canonical hierarchy, owned by one team, replicated outward to every consuming system. Without it, every reconciliation conversation hits the hierarchy mismatch first and stalls.
4. Quality disagreement
The systems agree on the definition, the timing, and the hierarchy. They disagree because the data is different quality in each place.
- Sales enters incomplete account data; finance has clean account data because the order could not be invoiced without it.
- Marketing automation has every lead the website ever produced; the CRM only has the ones a sales rep accepted.
- One system is the sole source of truth for a field; the others have stale copies.
The fix here is a field-by-field source-of-truth audit and a clean-up cycle, paired with input controls that prevent the field from regressing.
The integration audit
The audit is structured around five named entities, the ones that drive every reported number, and a single template applied to each.
The five entities:
- Customer / Account, who.
- Opportunity / Order, what they are buying.
- Contact / Person, who at the customer is involved.
- Product / SKU, what is being sold.
- Revenue event, when value moved.
For each entity, the audit answers six questions:
- Definition. What does this entity mean, in one sentence, in business language?
- Canonical system. Which system is the source of truth?
- Replication. Which systems hold a copy, and how is the copy kept fresh?
- Hierarchy. What is the canonical parent-child structure, if any?
- Quality. What fields are required, and what input controls enforce them?
- Reconciliation. What is the rhythm and method for catching drift?
The audit produces a single document, the Entity Map, that becomes the operating reference for the integration program. Most organizations we audit have never had this document, and the absence of it is the actual root cause of the disagreements they have been trying to debug for years.
The reconciliation rhythm
Once the Entity Map exists, reconciliation moves from a quarterly fire drill to a routine practice. Three rhythms together do most of the work.
Daily. Automated reconciliation reports run overnight against the canonical entity. Any drift above a defined threshold creates a ticket for the canonical owner the next morning. This catches the small, recoverable drifts before they accumulate.
Weekly. A 30-minute integration standup with one named representative from each consuming system reviews the daily exceptions, decides on resolution, and updates the Entity Map if a new edge case has emerged. This keeps the map living rather than ceremonial.
Quarterly. A full audit against the Entity Map: every entity, every system, every replication, every threshold. Updates the map. Surfaces structural drift that the daily and weekly rhythms cannot catch. Reports out to the leadership team that depends on the integration.
This rhythm is sustainable. It does not require an integration team of ten. It does require named owners, agreed thresholds, and the discipline to actually run the standups when nothing is on fire.
What the audit does not require
It is worth saying out loud what an integration audit does not require, because the alternative, re-platforming, is what most organizations propose first.
The audit does not require a new CRM. It does not require a new ERP. It does not require an MDM tool, although one might be helpful at the largest scales. It does not require a data warehouse rebuild. It does not require an iPaaS, although one might simplify the replication pattern.
What the audit requires is a written Entity Map, a named owner per entity, an agreed reconciliation rhythm, and the executive air cover to hold the canonical owners accountable when their entity drifts. Most of the value comes from the discipline of the artifact, not from any new platform purchase.
The vast majority of the time, an integration audit reveals that the existing platforms are competent. The problem was never the platforms. The problem was the absence of a shared operating model across them.
What a leader can do this week
Three concrete moves:
-
Pick one entity that is causing the worst disagreement. Customer is usually the right starting point. Walk it through the six audit questions with one representative from each consuming team. The answers will reveal the disagreement category.
-
Publish a one-page definition of the entity, signed off by every team. This single artifact ends most of the recurring debate.
-
Schedule the first weekly integration standup. Even before the full Entity Map exists. The act of getting representatives from each system in a room weekly creates the venue for the work.
If the disagreement is large enough that a focused engagement is the right call, Integrations & Optimization, CRM Solutions, and ERP Solutions practices run integration audits as a defined three- to four-week engagement that produces the Entity Map and the reconciliation rhythm as deliverables.