Why four teams report four different revenue numbers
A reconciliation problem may be definitional, technical, or both. Test the metric contract before buying another data platform.
Consider an illustrative quarter. Marketing reports $4.2M of sourced pipeline, sales reports $3.6M of qualified open pipeline, the BI dashboard shows $3.9M of opportunities created, and finance says none of those measures is recognized revenue. The numbers can all come from the same CRM and still answer different questions.
Data quality is one possible cause. Definition, timing, filters, currency treatment, and source authority are others. A warehouse may improve access and lineage, but it cannot decide which business question a metric should answer.
The numbers may each be correct within scope
Suppose marketing counts opportunities with a qualifying campaign touch in a 90-day lookback, sales counts opportunities above stage 2 with a close date in the period, BI counts open opportunities created in the period, and finance recognizes revenue under the applicable accounting policy. Each computation may be faithful to its own rule while being unsuitable as a substitute for the others.
The output to inspect is a metric contract: name, question, population, time basis, currency rule, owner, and authoritative fields. That contract can reveal a semantic mismatch. It does not rule out missing records, broken joins, or other data defects.
Why the warehouse does not fix it
A warehouse centralizes storage and can improve lineage. Meaning still comes from governed definitions. Loading several systems into one schema can preserve the original disagreement or add another definition in the modeling layer if no metric contract governs the result.
If reconciliation meetings continue after a migration, inspect both layers. The platform may have solved access while leaving metric semantics unresolved; it may also contain mapping, freshness, or transformation defects. The symptom does not identify one cause by itself.
Output: a scoped metric contract
- Name the metric precisely enough that two people implementing it independently produce the same number. "Pipeline" is not a name; "qualified open pipeline, stage 2+, close date in fiscal period, in reporting currency, from CRM opportunity" is.
- Assign one owner per definition, with the authority to decline changes.
- Designate a system of record per field, not per system. The CRM can own opportunity state while billing owns invoiced amount.
- Put definitional change under review, with a release note. A silent change breaks comparison across periods.
- Publish the definitions where the numbers are consumed, not in a wiki nobody opens.
The governance framing
In this model, RevOps governs the shared interfaces: definitions, boundaries, authority by field, and change control. Marketing, sales, customer success, finance, and data teams retain their domain ownership. The output is coordination with inspectable decision rights, not centralized control of every record.
A reconciliation meeting is evidence of unresolved variance, not a diagnosis. Record each variance as semantic, technical, timing-related, or unexplained; assign the relevant owner; and close it against the metric contract. Governance makes that work repeatable without pretending every discrepancy has the same source.
Terms used in this note
Write the stop rule before the pilot starts
A market-entry pilot with no decision rule written before exposure cannot end. It gets extended until it is the default motion, without anyone choosing that.
Your pricing is a list, not a logic
A price list says what things cost today. It cannot say what to charge the deal in front of you, which is why realised price drifts and nobody owns the drift.
You just inherited RevOps. Start with a charter.
Being told to "own revenue operations" is not a mandate. Until authority is written down, every decision you make is reversible by whoever objects loudest.