Why Stripe or Chargebee Data Doesn't Match HubSpot

The architecture problem: the integration you've got connected isn't syncing what you assume it's syncing. HubSpot's native Stripe connector, for example, moves contact, product, and payment data. It does not calculate MRR. If you've been looking at a "MRR" field in HubSpot that's populated through the native sync, that field is either empty, manually maintained, or quietly wrong, because nothing in that connector is doing the math.

The definitional problem: Stripe and Chargebee record revenue events (invoices, charges, prorations) as they happen at the billing-system level. HubSpot, left to its own devices, has no native concept of "monthly recurring revenue" unless something calculates it.

A subscription upgrade mid-cycle, for example, generates a prorated invoice in Stripe that reflects a one-time catch-up charge, not the new ongoing MRR figure. If a workflow or property in HubSpot is naively pulling "invoice amount" as if it were "current MRR," it will be right on renewal months and wrong every month there's a plan change, discount, or partial-period charge.

Both problems compound each other. Fix only the architecture (get the right fields syncing) and you'll still have numbers that drift every time someone upgrades mid-cycle. Fix only the definitions (build the right MRR formula) on top of a broken sync and you're calculating an accurate metric from incomplete or duplicated source data. You need to solve both, and most teams only realize there's a second problem after they've already spent time solving the first.

This is worth walking through carefully, because the fix depends entirely on which setup you're running, and a lot of teams aren't sure.

HubSpot's native Stripe Data Sync app

This is the free, marketplace-installed connector most teams reach for first. It handles bidirectional syncing for a small set of objects, primarily contacts, products, and payment/invoice records, with default field mappings you can extend if you're on Operations Hub Starter or above.

Two things catch people off guard: syncing Stripe subscriptions as their own object requires HubSpot Enterprise, because that's a custom object under the hood, and the connector does not perform any MRR transformation. It passes through exactly what Stripe sends, invoice totals, payment statuses, customer fields, nothing more.

Stripe as a payment processor inside HubSpot's Revenue Hub

This is a different setup entirely, and it's easy to conflate with the Data Sync app because both involve Stripe. Here, HubSpot is the system of record for quotes, invoices, and subscriptions, and Stripe only handles the actual payment processing (card, ACH, and similar rails) behind the scenes.

If your billing has historically lived in Stripe as its own system of record and you're also using this Revenue Hub payment flow, you can end up with two partially overlapping subscription records for the same customer, one native to HubSpot's commerce tools, one pulled in through the Data Sync app, with no automatic reconciliation between them.

Chargebee's legacy HubSpot integration versus its Quote-to-Cash (Q2C) integration

These are architecturally different, not just versioned differently, and the difference explains a specific complaint we see often: teams that migrated from legacy to Q2C and suddenly can't find subscription details on Contact records anymore.

The legacy integration synced Chargebee customers primarily to HubSpot contacts. Q2C syncs to companies and deals as the primary objects, with contact-level visibility handled differently (Source: HubSpot Community thread on Chargebee Contacts and Deals sync).

If your sales team works from Contacts and your onboarding team works from Deals, migrating integration versions without telling anyone will make it look like data went missing when it actually just moved objects.

Where records silently fail to sync at all.

Both Stripe and Chargebee allow duplicate email addresses across separate customer records. HubSpot does not, contacts must have unique emails.

When a Chargebee customer's email already maps to a different HubSpot contact, Chargebee's own documentation flags this explicitly as an "already mapped" error that blocks that specific record from syncing, silently, unless someone's watching the sync health dashboard (Source: Chargebee HubSpot Troubleshooting docs). This is one of the more common reasons a handful of customers are simply missing or stale in HubSpot while everyone assumes the sync is working, because it mostly is, just not for those records.

Once you know which integration you're actually running, the fix is a sequence of decisions, not a single setting.

1. Audit what's currently connected, not what you think is connected.
   
   Check both HubSpot's App Marketplace connections and, if relevant, Chargebee or Stripe's own integration settings page. It's common to find more than one integration path active at once, a leftover Zapier automation alongside a native connector, both writing to the same fields.
   
   
   
2. Pick one system as the source of truth for each object type.
   
   Contacts, subscriptions, and revenue metrics don't all need the same master. A common, workable split: billing system owns subscription status and pricing, HubSpot owns lifecycle stage and CRM-specific fields, and nothing gets to override the other system's owned fields.
   
   
   Chargebee's integration settings let you configure this explicitly, whether Chargebee always overrides matching HubSpot fields or only fills in empty ones, and getting this setting wrong is a frequent, quiet cause of fields flipping back to stale values after someone manually corrects them in HubSpot.
   
   
   
3. Decide your contact matching key before you scale the sync, not after.
   
   
   Email is the default and it's fragile, given that billing systems allow duplicates and CRMs don't. If your billing platform supports a stable external customer ID, map on that instead and treat email as a secondary field, not the join key.
   
   
   
4. Decide where MRR actually gets calculated, and build it once.
   
   
   This is usually the step teams skip. Either build the calculation logic yourself using HubSpot workflows and calculated properties (current subscription rate, not invoice total, adjusted for proration and discounts), or bring in a dedicated revenue-sync layer built specifically for this transformation.
   
   Worth being direct about the tradeoff here: building it yourself is free but requires someone who understands both systems' data models well enough to handle every edge case, including proration, mid-cycle changes, and multi-currency.
   
   
   Vendor tools that specialize in this (ClearSync, Baremetrics, and similar are examples we've seen referenced) exist specifically because that logic is more involved than it looks from the outside; that's their pitch, and it's not wrong, though it's also commercial commentary, so weigh it against your own team's capacity before assuming you need a third tool in the stack.
   
   
   
5. Set a reconciliation cadence, not a one-time fix.
   
   
   Even a correctly configured sync drifts. A monthly (at minimum) spot-check comparing HubSpot's MRR figure against the billing system's own dashboard for a sample of accounts catches drift before it reaches a board deck.
   

Getting the sync architecture right solves maybe half the actual mismatch. The other half is that Stripe, Chargebee, and HubSpot don't agree on what counts as revenue in several genuinely common scenarios, and most integration guides don't walk through these because they're focused on getting the connection working, not on what happens after.

Prorations. A customer upgrades mid-billing-cycle. Stripe generates an invoice for the prorated difference, a one-time catch-up charge that has nothing to do with the customer's new ongoing monthly rate. If your HubSpot property is pulling "latest invoice amount" as a stand-in for MRR, that customer will show an inflated (or deflated, on a downgrade) MRR figure for exactly one billing cycle, then silently correct itself the following month.

This makes the error hard to catch through casual spot-checking, since it looks like noise rather than a systematic bug.

Discounts and coupons. A percentage-off coupon lowers the invoiced amount without changing the subscription's underlying list price. Depending on whether your MRR calculation is pulling from the invoice total or the subscription's base rate, you'll get two different, both defensible, numbers. Neither is wrong exactly, but they answer different questions (what did we bill versus what's the account worth at list price), and mixing the two within the same report produces numbers that don't add up cleanly.

Multi-currency. If you sell in more than one currency, both Chargebee's documentation and general Stripe integration guidance flag that currency lists need to match between the billing platform and HubSpot, or syncs fail outright rather than silently converting. Beyond the sync mechanics, there's a reporting decision buried here too: at what exchange rate and on what date do you convert a EUR subscription into a USD MRR figure for a consolidated dashboard. If that logic isn't defined and applied consistently, your MRR total will shift slightly every time exchange rates move, even with zero actual subscription changes.

Free trials. Trial accounts often exist in the billing system before any money changes hands, and depending on your sync configuration, they may or may not create HubSpot records, and if they do, they may be counted in customer totals in one system and excluded in the other.

Usage-based and metered components. These are typically billed in arrears, after the usage period closes, which means the "current month" revenue figure in your billing system and the "current month" figure in HubSpot can legitimately represent different periods depending on when each system's data refreshes relative to your billing cycle close. This isn't a bug so much as a timing mismatch that needs to be understood and accounted for in how you label the reporting period.

Refunds and credits. Issued after the fact, in the billing system, and not always propagated backward into whatever revenue figure HubSpot already recorded for that period. If your sync is one-directional or only fires on new events, a refund can leave HubSpot showing revenue that, as far as the customer's actual account, no longer exists.

None of these are exotic edge cases. Any SaaS company running annual and monthly plans side by side, offering any kind of discount, or supporting plan changes mid-cycle, will hit several of these in a normal month.

If you're past prevention and need to fix numbers that are already wrong in HubSpot, the order of operations matters.

Start by establishing which system has the correct historical record. This is almost always the billing platform, Stripe or Chargebee, not HubSpot, since HubSpot was never the source of truth for billing events to begin with. Resist the temptation to fix HubSpot fields one at a time as errors get reported; that treats symptoms and the same records will drift again.

Instead, pull a clean historical export from the billing system covering the period you need to correct, and use it to backfill HubSpot properties in bulk rather than record by record. This is also the point where a lot of teams discover that HubSpot's Commerce Hub tooling doesn't automatically import existing Stripe transaction history when you first connect it, so a genuine historical backfill often needs to run through the API or an import tool rather than relying on the connector to catch up on its own.

Once the backfill is done, re-run the architecture decisions above (source of truth, matching key, calculation ownership) before considering the fix complete. A one-time backfill on top of an unfixed sync just resets the clock until the same drift reappears.

Where we usually get involved isn't the backfill itself, it's the diagnosis before it: figuring out which of the two problems (or both) is actually driving the specific numbers that are wrong, since that changes whether the fix is a settings change, a workflow build, or a genuine third-party sync layer. Teams often assume they need the third option when a correctly configured native setup would have covered it.

Why does HubSpot show a different MRR than my Stripe dashboard?

Almost always one of two reasons: HubSpot's MRR field is pulling raw invoice totals rather than calculated subscription rates, so prorations and discounts distort it, or the two systems are counting different customer sets (trials, canceled-but-not-expired accounts) as part of the total. Check which invoices are driving the discrepancy before assuming it's a sync failure.

Does the native HubSpot-Stripe integration calculate MRR automatically?

No. The native Stripe Data Sync app syncs contact, product, and payment/invoice data, but it does not transform that into MRR, churn, or expansion metrics. If you see an MRR figure in HubSpot, something else, a manual property, a workflow, or a third-party tool, is calculating it.

Why are Chargebee subscriptions creating duplicate contacts in HubSpot?

Usually a mismatched matching key. Chargebee allows duplicate email addresses across customer records; HubSpot doesn't allow duplicate contact emails. When there's no stable external ID being used as the match, the sync either creates a second contact or throws an "already mapped" error and skips the record entirely, depending on your configured sync rules.

Should I use Zapier or a dedicated sync tool for Stripe-HubSpot billing data?

Depends on what you need. Zapier works fine for simple, event-triggered automations (create a contact when someone subscribes, alert on a failed payment) but it moves raw individual events, not calculated recurring-revenue metrics. If you need ongoing, accurate MRR and ARR reporting in HubSpot, Zapier alone won't get you there without significant custom logic on top of it.

Can I migrate historical Stripe transaction data into HubSpot?

Not automatically through the standard connection flow in most cases. Migrating active subscriptions natively tends to work cleanly only for flat-rate billing; usage-based, metered, or heavily discounted structures usually need a manual or API-based migration. Plan for this as a separate project step, not something the integration handles on connect.

If your numbers don't match, resist fixing the first thing you find. Check whether it's the sync moving incomplete data, the calculation logic misreading what did arrive, or both, before you touch a single field.

Most of these mismatches trace back to a handful of specific, well-documented gaps (proration handling, duplicate email matching, which integration version you're actually running) rather than a mysterious bug, and once you know which one you're looking at, the fix is usually a configuration decision, not a rebuild.