Your Stripe dashboard says $1.2M MRR. Your Salesforce pipeline report says $1.35M. Finance built a model in the warehouse that says $1.28M. Nobody knows which number is right, and the gap grows every month.
This is revenue drift — the silent divergence between what your billing system records and what your CRM reflects. It’s not a bug. It’s a structural problem that affects every B2B SaaS company running Stripe and Salesforce together. And it compounds over time.
This guide covers the four main categories of revenue drift, explains why each one happens, and walks through how to detect them — whether you build the reconciliation yourself or use a platform like Eru to automate it. We build Eru, so we have a perspective, but we’ll be straightforward about where manual and custom approaches work and where they break down.
This article is written for data leads, RevOps teams, and finance leaders at B2B SaaS companies between $3M and $30M ARR who need their Stripe and Salesforce numbers to agree.
What Revenue Drift Actually Is
Revenue drift is not a data sync problem. Syncing tools like Fivetran or Census move data between systems, but they don’t reconcile it. You can have perfectly synced data that still disagrees on the most basic question: how much is this customer paying us?
Drift happens because Stripe and Salesforce have fundamentally different models:
- Stripe tracks payments, subscriptions, and invoices. Revenue is what was actually billed and collected.
- Salesforce tracks opportunities, contracts, and deal stages. Revenue is what was agreed upon during the sales process.
The gap between “what was agreed” and “what was billed” is where drift lives. At seed stage, one person can keep both systems in sync manually. By Series A, with 100+ accounts, multiple AEs, self-service upgrades, and a growing finance team asking questions, the drift becomes structural.
The Four Categories of Revenue Drift
We’ve categorised drift into four types based on their root cause. Each requires different data and detection logic:
| Drift Category | Root Cause | Data Required | Typical Impact |
|---|---|---|---|
| Billing timing mismatches | Stripe and Salesforce recognise revenue at different moments | Invoice dates + opportunity close dates | 5–15% of accounts show month-boundary discrepancies |
| Expansion revenue gaps | Self-service upgrades and add-ons hit Stripe but never reach Salesforce | Subscription modification events + opportunity records | 10–30% of expansion revenue missing from CRM |
| Failed payment drift | Cancelled subscriptions in Stripe still show as active in Salesforce | Payment failure events + account status in CRM | 2–5% of MRR phantom revenue in CRM |
| MRR recognition differences | Different calculation methods for proration, discounts, and billing cycles | Subscription details + contract terms | 1–8% aggregate MRR variance |
Category 1: Billing Timing Mismatches
What happens
Stripe records revenue when a payment succeeds. Salesforce records it when a rep marks an opportunity as “Closed Won.” These two events can be days, weeks, or even months apart.
A customer signs on January 28th (opportunity closed in Salesforce), but their first invoice isn’t generated until February 1st (Stripe). Salesforce says you have $10K of new MRR in January. Stripe says you have $10K of new MRR in February. Both are “correct” within their own system. Your board deck picks one; your CFO’s model picks the other.
Why it’s hard to detect
Timing drift doesn’t create permanent discrepancies — it creates rolling discrepancies that shift month to month. At any given month-end close, 5–15% of accounts may show a timing gap. The aggregate impact looks like noise, but it systematically inflates or deflates monthly growth numbers depending on which system you report from.
How to detect it
- For each account, compare the Salesforce opportunity close date against the first Stripe invoice date.
- Flag accounts where the gap is greater than 7 days.
- Aggregate the MRR value of these accounts by month to see how much revenue shifts between periods.
- Check whether your board deck and CFO model are pulling from the same system for new business MRR.
Category 2: Expansion Revenue Not Captured in CRM
What happens
A customer upgrades their plan, adds seats, or activates an add-on through your product’s self-service billing flow. Stripe processes the change immediately — the subscription is updated, the next invoice reflects the new amount. But nobody creates a new opportunity or updates the existing deal value in Salesforce.
This is the most common source of material drift. At companies with product-led growth motions or usage-based pricing, 10–30% of expansion revenue can be invisible in the CRM. The AE doesn’t know about it because they didn’t close it. CS doesn’t update it because they weren’t involved. The CRM slowly understates actual revenue.
Why it compounds
Expansion drift is cumulative. Every month that a self-service upgrade goes unrecorded in Salesforce, the gap between Stripe and Salesforce widens. After a year, the CRM can understate account value by 20–40% for accounts with frequent self-service changes. This distorts pipeline forecasting, CS resource allocation, and renewal negotiations.
How to detect it
- Export all Stripe
customer.subscription.updatedevents from the past 90 days. - Filter for events where the subscription amount increased (upgrades, add-ons, seat additions).
- Cross-reference each event against Salesforce: does a corresponding opportunity or contract amendment exist within 14 days?
- Sum the unmatched expansion value. This is your CRM expansion gap.
Category 3: Failed Payment Drift
What happens
A customer’s credit card expires. Stripe retries the charge on an automatic schedule. After all retries fail, the subscription is cancelled. The customer didn’t choose to leave — this is involuntary churn.
The problem: Salesforce doesn’t know. The account record still shows the customer as active with their full contract value. CS continues treating them as a healthy account. Pipeline forecasts include their renewal. The revenue doesn’t exist anymore, but nobody updated the CRM.
The phantom revenue problem
Failed payment drift creates phantom revenue — MRR that appears in Salesforce reports but doesn’t exist in Stripe. At scale, this represents 2–5% of reported MRR. When discovered during a board review or fundraising diligence, it’s a credibility problem as much as a financial one.
How to detect it
- Pull all Stripe
charge.failedandinvoice.payment_failedevents from the past 60 days. - Identify subscriptions that were subsequently cancelled due to exhausted retries.
- For each cancelled subscription, check the corresponding Salesforce account: is the account still marked as “Active” or “Customer”?
- Sum the MRR value of accounts that are cancelled in Stripe but active in Salesforce. This is your phantom revenue.
Category 4: MRR Recognition Differences
What happens
Even when Stripe and Salesforce agree on which accounts are active and at what price, the way each system calculates MRR can produce different numbers. The differences are technical, but they add up:
- Annual vs. monthly billing: A customer pays $24,000/year in Stripe. Salesforce records a $24,000 annual contract. Stripe calculates MRR as $2,000. But if the Salesforce opportunity was entered with monthly values, it might show $1,800 or $2,200 depending on how the rep calculated the per-month figure.
- Proration: Stripe prorates mid-cycle changes precisely. Salesforce has no standard proration logic — reps enter adjusted values manually or not at all.
- Currency conversion: Multi-currency deals create discrepancies depending on when each system locks the exchange rate. Stripe converts at payment time. Salesforce may lock the rate at opportunity creation.
- Discount application: A 20% discount in Stripe is applied to the invoice total. In Salesforce, the same discount might be recorded as a reduced deal value, a separate line item, or a note in a text field. The effective MRR differs depending on the approach.
How to detect it
- For each active account, calculate MRR from Stripe (active subscription amount, normalised to monthly).
- Calculate MRR from Salesforce (opportunity or contract value, normalised to monthly).
- Compare account by account. Flag any discrepancy greater than 5%.
- Categorise each discrepancy by type: annual/monthly mismatch, proration difference, currency, or discount application.
Common Reconciliation Failure Patterns
Before choosing a reconciliation approach, understand why most existing attempts fail. These are the patterns we see repeatedly at B2B SaaS companies between $3M and $30M ARR:
- The monthly spreadsheet: Someone in finance exports Stripe and Salesforce data into a spreadsheet and manually matches accounts by name or email. This works at 50 accounts. At 200+, it takes 2–5 days per month, errors compound, and the person who built it becomes a single point of failure.
- The custom SQL query: A data engineer writes reconciliation queries in the warehouse. The queries work until edge cases accumulate — multi-subscription accounts, partial refunds, currency conversions, accounts with different names in each system. Maintenance grows linearly with customer count and business complexity.
- The sync tool assumption: Teams deploy Fivetran or Census to sync Stripe data into Salesforce (or both into a warehouse) and assume the problem is solved. Sync tools move data; they don’t reconcile it. Two perfectly synced datasets can still disagree on revenue because they use different calculation logic.
- The BI dashboard that nobody trusts: A Looker or Metabase dashboard shows both Stripe and Salesforce numbers side by side. The discrepancies are visible but not explained. Finance doesn’t trust the dashboard because it doesn’t tell them why the numbers differ or which one is right. The dashboard becomes a conversation starter, not a decision tool.
- The point-in-time audit: Once a quarter, someone does a thorough reconciliation for board reporting or fundraising prep. They find discrepancies, fix them, and move on. Within 30 days, drift reaccumulates because nothing prevents it from recurring. The next quarter starts from scratch.
Reconciliation Approaches Compared
There are three viable approaches to solving Stripe–Salesforce revenue drift. The right choice depends on your team size, engineering capacity, and how quickly you need results.
| Approach | Time to Build | Ongoing Maintenance | Drift Categories Covered | Best For |
|---|---|---|---|---|
| Manual / spreadsheets | None | 2–5 days/month | Partial — limited by human throughput | Companies with <50 accounts |
| Custom SQL + BI tools | 3–6 months | Ongoing engineering time | All four, if built correctly | Companies with dedicated data engineering |
| Automated platform (Eru) | Same-day setup | None | All four, continuously | Companies without data engineering or needing immediate results |
Manual / spreadsheets
For companies with fewer than 50 paying accounts, a monthly spreadsheet reconciliation is often sufficient. Export both datasets, match by customer name or email, compare amounts. The limitation is scale: as account count grows, manual matching becomes error-prone and time-consuming. It also can’t detect real-time issues like failed payment drift — you only find problems at month-end.
Custom SQL + BI tools (Looker, Metabase, Hex)
Building reconciliation in your data warehouse gives you full control. The typical architecture involves ETL pipelines from Stripe and Salesforce, an entity resolution layer to match accounts across systems, reconciliation queries, and a BI dashboard for finance. This is the right approach if you have a data engineer who can build and maintain it. The build takes 3–6 months, and edge cases (multi-subscription accounts, partial refunds, currency conversion) add complexity over time.
Baremetrics and similar subscription analytics tools can supplement this approach by providing clean MRR calculations from Stripe data, but they don’t reconcile against Salesforce.
Automated platform (Eru)
Eru connects to both Stripe and Salesforce via OAuth and automates the entire reconciliation process:
- Entity resolution: AI maps Stripe
customer_idto SalesforceAccount IDusing probabilistic matching across names, emails, domains, and custom fields — no manual mapping required. - Continuous monitoring: Eru ingests Stripe webhook events (
payment_intent.succeeded,invoice.paid,customer.subscription.updated) and cross-references each event against Salesforce records in real time. - Drift classification: Every discrepancy is categorised by type (timing, expansion, failed payment, recognition) and severity, so your team knows what to fix first.
- Configurable alerts: Set thresholds (e.g., flag discrepancies above $100/month per account or aggregate drift exceeding 1% of MRR) and receive Slack alerts with full context.
- Self-service dashboards: Finance teams can view reconciled revenue, account-level discrepancy reports, and revenue-at-risk summaries without SQL or engineering support.
Eru doesn’t replace your data warehouse or BI tools. It provides a purpose-built reconciliation layer that runs continuously, so your finance team gets accurate numbers without waiting for a monthly close process.
How to Run a Revenue Drift Audit Today
You don’t need a tool to start. Here’s a quick audit you can run this week to quantify your drift:
- Pick your top 20 accounts by MRR. Export their current subscription amount from Stripe and their deal/contract value from Salesforce.
- Match accounts manually. Use customer name, email domain, or any shared identifier to pair Stripe customers with Salesforce accounts.
- Compare MRR values. For each matched account, calculate the absolute difference between Stripe MRR and Salesforce MRR (normalised to monthly).
- Categorise each discrepancy. Is it timing? Expansion? Failed payment? Recognition? Use the four categories above.
- Sum the total drift. Add up all discrepancies across your top 20. This is your minimum drift exposure — the long tail of smaller accounts will add more.
At SaaS companies between $3M and $10M ARR, this audit typically uncovers $10K–$50K in previously undetected discrepancies. If your drift is above 2% of MRR, it’s worth investing in a systematic solution.
Connecting This to Your Revenue Monitoring System
Revenue drift detection is one piece of a broader revenue leakage monitoring system. A comprehensive system also covers orphaned accounts (paying customers with no CRM record), discount drift (undocumented pricing variations), and missed renewal engagement.
For the full picture of how revenue leakage detection tools compare — including Mixpanel, Amplitude, ChartMogul, Baremetrics, and Eru — see our companion article: Revenue Leakage Detection in B2B SaaS: Mixpanel vs Amplitude vs ChartMogul vs Eru.
For the technical details of how Stripe–Salesforce data discrepancies arise and how to resolve them at the system level, see: Why Your Stripe and Salesforce Numbers Never Match (And How to Fix It).
Frequently Asked Questions
What is revenue drift between Stripe and Salesforce?
Revenue drift is the silent divergence between what Stripe records as billing reality and what Salesforce reflects as deal values. It happens because the two systems serve different purposes — Stripe processes payments, Salesforce tracks relationships — and nothing natively connects them. Over time, self-service upgrades, failed payments, refunds, and timing differences cause the numbers to diverge. At SaaS scale-ups between $3M and $10M ARR, this drift typically represents $10K–$50K in undetected discrepancies.
How do I build a revenue leakage monitoring system that integrates with Salesforce, Stripe, and my data warehouse?
You need three layers: data connectivity between Stripe, Salesforce, and your warehouse via ETL pipelines or OAuth integrations; entity resolution logic that maps Stripe customer_id to Salesforce Account ID despite mismatched identifiers; and automated reconciliation that continuously compares MRR by account across sources and alerts on discrepancies. You can build this with custom pipelines and BI tools (3–6 months build, ongoing engineering maintenance) or use a managed platform like Eru that provides all three layers out of the box with self-service dashboards for finance teams.
What are the most common reconciliation failure patterns between Stripe and Salesforce?
The four most common failure patterns are: (1) billing timing mismatches, where Stripe recognises revenue on payment success while Salesforce records it on opportunity close; (2) expansion revenue gaps, where self-service upgrades hit Stripe but never reach Salesforce; (3) failed payment drift, where exhausted retries cancel Stripe subscriptions while Salesforce still shows the account as active; and (4) MRR recognition differences from annual-vs-monthly billing, proration, currency conversion, and discount application differences.
Find out how much revenue is drifting between your Stripe and Salesforce systems. Book a free revenue drift audit.
Book a drift audit →