Customers sometimes see differences between RevSure's reported numbers and what they see in their source systems (Salesforce, HubSpot, Adobe, etc.). Most of these differences are not bugs — they come from timing, definitions, configuration, or process changes. This FAQ lists the common, legitimate reasons.
1. Data Sync & Timing
Sync timing / data freshness: Records created, reopened, or updated between when a source report was pulled and when RevSure last synced will show up as differences — this is a timing gap, not a logic error.
Historical records retained after source deletion: If a record is later removed from the source system (e.g. to stay under a data cap), RevSure may keep its historical engagement data, so current vs. historical counts can diverge.
Contractual data limits truncating records: Some plans enforce record caps (e.g. a lead/contact limit). Records beyond the cap aren't synced, so any related activity won't appear in RevSure — an intentional scope limit, not a defect.
2. Reporting & Definition Differences
No agreed source of truth: Different reports pulled from the same source system (e.g. built on unique email vs. contact ID vs. another identifier) can disagree with each other structurally — RevSure can't "match" a report that doesn't even match the customer's own other reports.
Different funnel stage/definition being measured: An apparent gap can simply mean two reports are anchored to different stages (e.g. deal creation vs. late-stage pipeline). Once definitions are aligned, the numbers typically reconcile.
Fiscal year / period misalignment: A fiscal year that doesn't match the calendar year can cause quarter or period labels to look mismatched, even though the underlying data is correct.
Attribution/rollup logic differences by design: RevSure may report the literal first touch, while a source system's report uses OR-logic across several fields (e.g. campaign name, first touch campaign, primary source) — same data, different aggregation approach.
Source-system-specific attribution rules: Some platforms apply override rules (e.g. treating a later touch as more relevant than the literal first event of the day). RevSure may report the strict first event instead — a difference in tie-breaking logic, not missing data.
Amount/value field ambiguity: Disagreement over which underlying field a formula should trust (e.g. which "amount" field represents new business) can make totals look off even when both platforms are reading the data correctly.
3. Funnel Configuration Changes
Timestamp field source changes: Switching which field anchors a funnel stage (e.g. a date-only field vs. a full timestamp field) can change stage ordering for some records, since date-only fields default to midnight.
Stage mapping/anchoring choices, applied retroactively: Changing which source-system stages map to a RevSure funnel stage changes historical totals once applied — a deliberate redefinition, not an error.
Opportunity Stage Key remapping tables: Funnel configs map multiple raw source-system stage labels into one RevSure stage key. Editing these mapping tables reshuffles which records land in which funnel stage.
Exclusion/inclusion rule changes: Deciding to include or exclude a channel or source from certain views changes funnel counts by design once toggled.
Filter definitions differing from a source report: If a source-system report applies filters at a different object level (e.g. on a lead record vs. a related campaign membership) than RevSure's config does, totals will diverge structurally, not due to a logic error.
4. CRM / System Migrations
CRM instance refresh or migration: When moving to a new CRM instance, field-level mappings must be rebuilt from scratch. Until the new mapping is fully confirmed, funnel stages and date fields can be temporarily out of sync with the old instance's numbers.
Missing date fields not carried into a new mapping: During migrations, funnel-dependent date fields sometimes aren't carried over into the new instance at all, requiring a mapping fix — a configuration gap, not a defect.
Lead-to-Contact conversion duplication in engagement datasets: When a lead converts to a contact, RevSure consolidates them under one ID, but the underlying engagement dataset may intentionally show the same activity under both the old and new IDs — inflating raw engagement counts by design.
5. Customer GTM Process & Lifecycle Changes
GTM process or lifecycle changes not communicated: If a customer changes their internal lead/opportunity lifecycle (a new stage added, qualification criteria redefined, a stage renamed or retired) without notifying RevSure, the funnel config keeps using the old definition until it's updated.
New stages with no historical backfill: Any newly added funnel stage naturally has no history, so early comparisons across time periods can look flat or static until enough real data accumulates — a cold-start effect, not missing data.
Change in GTM motion overall: Bigger shifts — org restructures, new segment/territory models, a new ICP — change how records get bucketed and compared. Until segment and field configs are rebuilt to match, historical comparisons look "off" simply because the lens changed.
Funnel date-logic updates to match an evolving process: RevSure may update which date field anchors a stage (e.g. moving primary logic from a creation date to a qualification date) to better reflect how a customer's process actually works now. This retroactively changes historical totals — a correction to better reflect current process, not an error.
6. Tooling & Capture Gaps (Outside RevSure)
Tag management / website tracking drift: Issues in a website's tag management setup (e.g. a missing form script or outdated trigger) can silently break form-submission capture for a period. Once identified, this is a website configuration gap, not a RevSure logic bug — but it explains a stretch of "missing" activity.
Configuration/taxonomy mismatch between connector and manual sheet: Manually maintained tracking sheets or dashboards can drift from how connections or taxonomy are actually configured in RevSure, producing apparent discrepancies that are really just misaligned reference data.
7. Upstream Data Quality
Duplicate records upstream, later reconciled: Source systems can contain duplicate records. Once RevSure's engineering team dedupes them, historical comparisons made before vs. after the fix may look inconsistent — even though nothing was ever broken in RevSure's logic.
When investigating a reported discrepancy, first check: (1) sync timing, (2) whether the two reports share a common definition/source of truth, (3) recent funnel config or CRM mapping changes, and (4) any known customer-side process or GTM changes — before assuming it's a product bug.