Your CFO asks for this quarter’s revenue number. Finance pulls from Stripe: $4.2M ARR. RevOps pulls from Salesforce: $4.5M ARR. The warehouse model says $4.35M. Three systems, three answers, and nobody can explain the $300K gap before the board meeting next week.
This is billing drift — the structural divergence between what your billing system charges and what your CRM reports. It affects every B2B SaaS company running Stripe and Salesforce together, and it compounds silently until someone asks the wrong question at the wrong time.
This guide walks through the complete reconciliation workflow: how to ingest billing data from Stripe, map it to Salesforce opportunity records, detect drift as it occurs, set up early warning signals, and produce reconciled revenue numbers that survive investor scrutiny. We build Eru, which automates this process, but we’ll cover the full approach — including what you can build yourself and where custom solutions typically break down.
Why Stripe and Salesforce Drift Apart
Stripe and Salesforce are not designed to agree. They serve fundamentally different functions:
- Stripe is a payment processor. It records what was actually billed, when invoices were issued, which payments succeeded or failed, and the current state of every subscription. Revenue in Stripe is transactional reality.
- Salesforce is a CRM. It records what was agreed during the sales process — deal values, contract terms, close dates, and account relationships. Revenue in Salesforce is commercial intent.
The gap between transactional reality and commercial intent is where billing drift lives. At $1M–$3M ARR, one person can keep both systems in sync manually. By $5M ARR, with self-service upgrades, multi-year contracts, usage-based pricing, and a growing finance team, the drift becomes structural and cumulative.
At B2B SaaS companies between $5M and $30M ARR, billing drift typically represents 2–8% of reported ARR. That’s $100K–$2.4M in revenue that one system claims exists and the other doesn’t.
The Reconciliation Workflow: Step by Step
Effective Stripe–Salesforce reconciliation requires a structured workflow with six components. Each step builds on the previous one. Skipping steps is how most custom reconciliation projects fail — they get the data but can’t explain the discrepancies.
Step 1: Ingest Billing Data from Stripe
The foundation of reconciliation is complete, real-time access to Stripe billing events. You need to capture:
- Subscription lifecycle events:
customer.subscription.created,customer.subscription.updated,customer.subscription.deleted - Payment events:
payment_intent.succeeded,invoice.paid,invoice.payment_failed,charge.failed,charge.refunded - Customer events:
customer.created,customer.updated,customer.deleted - Invoice metadata: line items, discounts, proration credits, tax amounts, and currency
The most common mistake at this stage is using batch data exports instead of real-time webhook ingestion. Batch exports create a lag — typically 4–24 hours — during which Stripe has processed events that your reconciliation system hasn’t seen. For accurate drift detection, you need event-level ingestion.
How Eru handles this: Eru connects to Stripe via OAuth, registers for all relevant webhook events, and ingests them in real time. Every event is stored with its original timestamp, creating an immutable audit trail that can be reprocessed if reconciliation logic changes.
Step 2: Map Stripe Customers to Salesforce Accounts
This is where most reconciliation projects stall. Stripe and Salesforce don’t share a native identifier. A Stripe customer_id (e.g., cus_R4xYz8AbCd) has no automatic relationship to a Salesforce Account ID (e.g., 001Dn00000Abc12). You need an entity resolution layer.
Entity resolution approaches, from simplest to most robust:
- Manual mapping table: Someone maintains a spreadsheet or custom object that maps Stripe customer IDs to Salesforce Account IDs. Works at <50 accounts. Breaks with staff turnover, self-service signups, and account merges.
- Email-based matching: Match the Stripe customer email to the Salesforce Contact or Account email. Works for ~70% of accounts. Fails when billing emails differ from sales contacts, or when multiple contacts share a domain.
- Domain-based matching: Extract the domain from Stripe customer email and match to the Salesforce Account website field. Better coverage than email matching for B2B, but requires clean domain data in Salesforce.
- Probabilistic matching: Combine name, email, domain, billing address, and custom metadata fields to produce a match confidence score. This handles edge cases — name variations, email differences, subsidiaries — that deterministic matching misses.
How Eru handles this: Eru uses AI-powered probabilistic matching across all available fields — names, emails, domains, billing addresses, and any custom metadata stored in Stripe or Salesforce. Match confidence scores are visible to users, and unmatched entities are surfaced for manual review. Once a match is confirmed, it persists and adapts as account data changes.
Step 3: Normalise Revenue Across Both Systems
Even with perfect entity matching, you can’t compare Stripe and Salesforce revenue directly. The two systems calculate MRR differently:
| Factor | Stripe Calculation | Salesforce Calculation | Impact |
|---|---|---|---|
| Annual billing | Subscription amount ÷ billing interval | Opportunity amount (entered manually by rep) | Reps may enter monthly, annual, or total contract value |
| Proration | Calculated precisely on mid-cycle changes | No standard proration logic | Mid-cycle upgrades create immediate MRR mismatches |
| Discounts | Applied to invoice line items | May be recorded as reduced deal value, separate line item, or text note | Effective MRR differs depending on how discounts are represented |
| Multi-currency | Converts at payment time | May lock rate at opportunity creation | Exchange rate timing creates persistent variance |
| Tax | Included or excluded per Stripe Tax config | Typically excluded from deal value | Tax-inclusive Stripe amounts are higher than Salesforce values |
Normalisation means applying identical calculation logic to both sources: divide annual contracts by 12, strip tax from Stripe amounts if Salesforce records exclude tax, use a consistent exchange rate source, and handle proration credits uniformly. Without normalisation, you’ll flag false positives — discrepancies that are actually calculation methodology differences, not real drift.
Step 4: Run Drift Detection on Matched Accounts
With matched, normalised data, you can run account-level drift detection. For each matched pair, compare Stripe MRR against Salesforce MRR and classify any discrepancy:
| Drift Category | Detection Logic | Typical Prevalence |
|---|---|---|
| Billing timing mismatch | Stripe invoice date and Salesforce opportunity close date differ by >7 days for the same revenue event | 5–15% of accounts at any month boundary |
| Expansion revenue gap | Stripe customer.subscription.updated event with increased amount has no matching Salesforce opportunity within 14 days |
10–30% of expansion revenue missing from CRM |
| Failed payment drift | Stripe subscription cancelled due to exhausted payment retries while Salesforce account status remains “Active” or “Customer” | 2–5% of MRR as phantom revenue |
| MRR recognition difference | Stripe and Salesforce MRR differ by >5% after normalisation, due to residual calculation methodology differences | 1–8% aggregate MRR variance |
Classification matters because each drift category has a different resolution path. Timing mismatches resolve themselves the following month. Expansion gaps require a CRM update process. Failed payment drift needs a CS intervention workflow. Recognition differences need a definitional alignment between finance and sales.
Step 5: Configure Alerting Thresholds
Not every discrepancy warrants an alert. Effective alerting requires two layers:
- Per-account thresholds: Flag individual accounts where the discrepancy exceeds a dollar amount (e.g., $100/month) or a percentage (e.g., 5% of account MRR). These catch specific accounts that need attention.
- Aggregate thresholds: Alert when total drift across all accounts exceeds a percentage of company MRR (e.g., 1%). These catch systemic problems — a broken integration, a policy change, or a product update that affects billing.
Alerts should include full context: the account name, Stripe amount, Salesforce amount, discrepancy amount and percentage, drift category, and a suggested next step. An alert that says “Account XYZ has a $500 discrepancy” is less useful than one that says “Account XYZ: Stripe shows $2,500/mo after a self-service upgrade on Feb 15. Salesforce still shows $2,000/mo. Likely expansion revenue gap — update the opportunity or create a new one.”
How Eru handles this: Eru provides configurable per-account and aggregate thresholds with Slack alert delivery. Each alert includes the full context — drift category, amounts, dates, and a direct link to the Salesforce account — so the RevOps team can resolve it without querying either system manually.
Step 6: Monitor Early Warning Signals
The best reconciliation catches discrepancies before they become confirmed drift. Early warning signals are leading indicators that predict future mismatches:
- Unmatched subscription modifications: A Stripe
customer.subscription.updatedevent fires, increasing the subscription amount. If no corresponding Salesforce update appears within 48 hours, this is a likely expansion revenue gap forming. The longer it goes unmatched, the more likely it never gets recorded. - Payment retry sequences: When Stripe begins retrying a failed charge, the account is entering a risk window. If all retries fail, the subscription will cancel in Stripe while Salesforce continues showing the account as active. Alerting during the retry window — not after cancellation — gives CS time to intervene.
- Self-service velocity spikes: A sudden increase in Stripe subscription creations or modifications that doesn’t correlate with Salesforce opportunity activity indicates your product-led growth is outpacing CRM hygiene. This predicts aggregate drift accumulation over the coming weeks.
- Entity resolution failures: New Stripe customers that can’t be matched to any Salesforce account represent orphaned revenue. This money is being collected but is invisible to your CRM, pipeline reporting, CS team, and any Salesforce-based health scoring.
- Month-boundary timing concentration: If more than 10% of accounts show a revenue recognition date difference greater than 7 days between Stripe and Salesforce, your monthly growth numbers will vary by 5–15% depending on which system you report from. This timing pattern predicts board deck inconsistencies.
How Eru handles this: Eru tracks all five early warning signals continuously. Payment retry alerts are sent to CS within minutes of the first failure, giving them up to 7 days of the standard retry window to recover the account. Unmatched subscription events are flagged within 48 hours. Entity resolution failures are surfaced immediately for manual matching.
Early Warning Signals for Billing Discrepancies
Beyond the reconciliation workflow itself, SaaS teams need to watch for broader signals that billing drift is accelerating. These are the patterns that distinguish companies with controlled, manageable drift from companies heading toward a board-level surprise:
| Signal | What It Means | Action |
|---|---|---|
| Drift trend increasing month-over-month | Reconciliation is falling behind the rate of new discrepancies. Something structural changed. | Audit recent product changes, pricing updates, or team process shifts |
| Expansion drift > new business drift | Self-service or product-led revenue is outgrowing CRM processes | Implement automated Stripe → Salesforce update for subscription modifications |
| Phantom revenue exceeds 3% of MRR | Failed payment recovery process has gaps. Salesforce is materially overstating ARR. | Implement payment failure → CRM status sync as a P1 integration |
| Entity match rate below 90% | >10% of paying customers can’t be mapped between systems. Revenue is invisible to CRM-based reporting. | Clean up Salesforce account data and establish identity resolution for new customers |
| Finance and RevOps report different ARR | Each team is pulling from a different system without reconciliation | Establish a single reconciled ARR source and deprecate conflicting reports |
Connecting Billing Reconciliation to Customer Health
Billing discrepancies are not just a finance problem — they’re a customer health signal. When Stripe and Salesforce disagree on an account, the root cause often reveals something about the customer relationship:
- Failed payment drift means a customer is at risk of involuntary churn. If your health scoring only looks at product usage and support tickets, it will miss customers whose subscriptions are actively being cancelled by Stripe.
- Expansion not in CRM means the customer’s value has increased but your CS team doesn’t know. They may be under-investing in an account that has grown substantially via self-service.
- Orphaned Stripe customers are paying you money but have no CRM record, no CSM, and no renewal process. These are the accounts most likely to churn silently because nobody is managing the relationship.
Reconciliation data should feed into health scoring. An account with a billing discrepancy should have its health score adjusted — positively for unexpected expansion, negatively for failed payments or orphaned status.
Reconciliation for Due Diligence and Board Reporting
Billing drift becomes a critical problem during fundraising. Investors will stress-test your revenue numbers from multiple angles:
- ARR consistency check: Does your pitch deck ARR match your Stripe data? Does it match Salesforce? If all three show different numbers, credibility drops immediately.
- Churn and retention verification: Investors calculate their own NRR from your data. If your Salesforce has phantom revenue from failed-payment drift, your reported churn will be understated and your NRR overstated.
- Cohort analysis audit: Cohort data built on unreconciled revenue will show different expansion and contraction rates depending on the source. Investors who notice this will question all your growth metrics.
- Revenue quality assessment: Reconciled revenue demonstrates operational maturity. If you can show an automated reconciliation process with a continuous audit trail, it signals that your revenue numbers are trustworthy at scale — not just cleaned up for the fundraise.
The typical pre-fundraise reconciliation is a point-in-time exercise: someone spends 2–4 weeks manually matching accounts and fixing discrepancies. The problem is that drift reaccumulates within 30 days. Continuous reconciliation means you’re always audit-ready, which shortens diligence timelines and reduces valuation risk.
What Eru Provides vs. What You Can Build Yourself
You don’t need Eru to reconcile Stripe and Salesforce. But it’s worth understanding where custom solutions typically struggle and where a managed platform provides leverage.
| Capability | Build Yourself | Eru |
|---|---|---|
| Stripe data ingestion | Webhook endpoint + event storage. 1–2 weeks to build, requires maintenance. | OAuth connection, automatic event ingestion, audit trail. |
| Entity resolution | Email/domain matching covers ~70% of accounts. Edge cases (subsidiaries, name changes, merges) require custom logic. | AI-powered probabilistic matching across all available fields. Handles edge cases automatically. |
| Revenue normalisation | SQL queries in your warehouse. Must handle proration, discounts, currency, tax. Takes 2–4 weeks, breaks with Stripe pricing model changes. | Normalisation logic maintained by Eru, updated as Stripe evolves. |
| Drift detection | SQL comparison queries. Can detect that numbers differ but typically can’t classify why. | Automatic classification into four drift categories with root cause context. |
| Alerting | Custom Slack/email integration. Requires thresholds, context formatting, and alert routing. | Configurable thresholds, contextual Slack alerts, direct links to source records. |
| Early warning signals | Requires real-time event correlation. Most custom builds only detect confirmed drift, not leading indicators. | Five early warning signals monitored continuously with proactive alerts. |
| Finance dashboards | BI tool setup (Looker, Metabase). Requires data modelling and ongoing maintenance. | Self-service dashboards for finance teams, no SQL required. |
For companies with a dedicated data engineering team and 3–6 months to build, a custom solution can work. For companies that need results immediately or don’t have engineering capacity to dedicate to reconciliation infrastructure, Eru provides the full workflow on day one.
How to Start a Reconciliation Audit Today
You can assess your billing drift exposure this week without any tools:
- Export your top 25 accounts by MRR from both Stripe and Salesforce.
- Match them manually using customer name, email, or any shared identifier.
- Compare MRR values for each matched account. Normalise annual contracts to monthly.
- Categorise each discrepancy: Is it a timing issue? Missing expansion? Failed payment? Calculation difference?
- Sum the total drift. If it exceeds 2% of your MRR, you have a material reconciliation problem.
- Note any unmatched accounts. Stripe customers you can’t find in Salesforce are orphaned revenue — real money with no CRM representation.
At SaaS companies between $5M and $30M ARR, this audit typically reveals $50K–$200K in discrepancies across the top 25 accounts alone. The long tail of smaller accounts adds more.
Frequently Asked Questions
How does Eru handle Stripe to Salesforce revenue reconciliation?
Eru connects to Stripe and Salesforce via OAuth and runs continuous, automated reconciliation. It uses AI-powered entity resolution to map Stripe customer IDs to Salesforce Account IDs, ingests Stripe webhook events in real time, and cross-references each event against Salesforce records. Every discrepancy is automatically classified by type — billing timing mismatch, expansion revenue gap, failed payment drift, or MRR recognition difference — so your team knows what to fix and why. Finance teams get self-service dashboards without needing SQL or engineering support.
Can Eru give early warning signals for Stripe–Salesforce discrepancies?
Yes. Eru monitors five leading indicators: unmatched subscription modifications (expansion events without CRM updates within 48 hours), payment retry sequences (accounts at risk of involuntary churn), self-service velocity spikes (product-led growth outpacing CRM hygiene), entity resolution failures (orphaned revenue invisible to the CRM), and month-boundary timing patterns (revenue recognition shifts between periods). These signals alert your team before discrepancies become confirmed drift.
How does billing reconciliation help with fundraising due diligence?
Investors stress-test your revenue numbers from multiple systems. If Stripe, Salesforce, and your board deck show different ARR figures, credibility drops immediately. Continuous reconciliation means your revenue figures are audit-ready at any point — not just after a pre-fundraise cleanup. Eru provides a reconciliation audit trail showing every entity match, discrepancy classification, and resolution, which demonstrates operational maturity to diligence teams and shortens the verification process.
What is the typical billing drift for B2B SaaS companies?
At B2B SaaS companies between $5M and $30M ARR, billing drift between Stripe and Salesforce typically represents 2–8% of reported ARR. The four main sources are: billing timing mismatches (5–15% of accounts at any month boundary), expansion revenue gaps (10–30% of self-service expansion missing from CRM), failed payment drift (2–5% phantom MRR in Salesforce), and MRR recognition differences (1–8% aggregate variance from different calculation methods).
Find out how much billing drift is hiding between your Stripe and Salesforce data. Book a free reconciliation audit.
Book a reconciliation audit →