Six reasons Stripe MRR is wrong in HubSpot, and the fix for each
Ask HubSpot what your Stripe™ MRR is, and you'll get a number — it just won't be reliable, because nothing in HubSpot recomputes it against Stripe after the moment someone typed it in or a sync last ran. That gap has a small number of specific, checkable causes, not one vague "the systems don't match." Below are six of them, each with a mechanism you can verify in your own portal in a few minutes, and a fix that doesn't require writing code.
The six reasons
1. There's no native MRR field synced from Stripe at all
HubSpot's own Stripe Data Sync only lands Subscriptions in Custom Objects, and that's gated to Enterprise. Below that tier, "MRR" in HubSpot is usually a manually entered Deal amount that nobody recomputes when the underlying subscription changes.
Fix: treat the Deal or property amount as a snapshot, not a live figure, and record clearly when it was last checked against Stripe. An honest staleness label beats a false sense of freshness.
2. Deal amount is stamped once and never revisited
Stripe subscription revenue changes constantly — upgrades, downgrades, proration — but a Deal amount typically gets set once, at creation or close, and stays there.
Fix: if the subscription is expected to change (most are), store the last-checked Stripe amount and date as separate properties from the original Deal amount, so the originally recorded value and what Stripe reports today can disagree visibly instead of silently.
3. Currency exchange rates lock at close, and never move again
In a multi-currency HubSpot account, the Exchange rate on a closed deal is set once, at close, and HubSpot's own documentation states plainly that it will not automatically update again — even as your account's live exchange rates keep updating. Revenue on a subscription billed in a currency other than your company currency keeps drifting from that frozen figure for as long as the deal sits in HubSpot's rollups.
Fix: for subscriptions with real currency exposure, recompute the company-currency figure from Stripe's own reported amount rather than trusting the frozen Exchange rate property — especially in any report spanning more than one billing cycle.
4. Trials get counted, or dropped, inconsistently
Stripe's subscription lifecycle has eight distinct states, including trialing, and a subscription moves automatically to active once the trial ends and the first payment succeeds. A HubSpot property set once, when the trial started, doesn't know when that conversion happens unless something updates it afterward.
Fix: don't count trialing subscriptions as MRR at all until you have a specific, separate signal — a webhook, or a daily check — that the status actually changed to active.
5. Discounts changed shape, and older field mappings don't know it
Stripe's Basil API version moved discounts off a single coupon or promotion_code field and onto a discounts array that can hold more than one stacked discount at once. An integration still reading the old single-coupon field undercounts the total discount applied, and overstates the net revenue a subscription is actually worth.
Fix: read and sum the discounts array, not the legacy fields — see our companion piece on what Stripe's Basil release changed for the full field list.
6. Canceled and past-due subscriptions don't tell HubSpot they've changed
Nothing native lets Stripe reach into HubSpot and update a Deal stage or amount when a subscription cancels or a payment fails. A Deal marked closed-won at a given amount keeps reporting that same amount in every MRR rollup indefinitely, whether or not Stripe is still collecting it.
Fix: the same property-plus-webhook pattern covered in our companion piece on reporting failed payments and past-due subscriptions catches this — a stripe_subscription_status property that actually gets updated when Stripe's status changes.
Where this breaks down
Every fix above depends on something running on schedule — a webhook handler, a scheduled export, a person — and nothing here tells you when that stops. The property just keeps showing its last value, indefinitely.
Manually recomputing currency or discount totals doesn't scale much past a handful of accounts. It's a reasonable one-off cleanup, not a process most teams sustain every month by hand.
None of these fixes reconcile with Stripe automatically. They make the number more likely to be right at the moment someone checks it — not continuously, and not without someone doing the checking.
The six reasons above compound rather than sitting neatly apart. A subscription can be mid-trial, priced in a foreign currency, and carrying a stacked discount at the same time, and a single manual fix aimed at only one cause can leave the other two untouched — which is why a spot-check that resolves one flagged deal is easy to mistake for the whole account being clean.
What Trueness does about it
Trueness's free Drift Report doesn't try to write a corrected MRR figure into your portal — it prices the specific gaps (past-due subscriptions, refunded-but-still-paid invoices, closed-won deals with no matching Stripe subscription) in dollars, checked against Stripe directly, every day, on every HubSpot tier. A single reconciled MRR figure sent back into HubSpot is on our roadmap and isn't built yet; today, the report gives finance a list of exactly what's wrong instead of one number nobody can audit.