HubSpot agencies working with SaaS clients may eventually hit the same wall: the client uses Stripe for billing and HubSpot as their CRM, and those two systems don't share a language. Stripe knows everything about their subscriptions. HubSpot knows nothing. And the client wants their revenue data to live somewhere their sales, CS, and RevOps teams can actually use it.

This post covers:

• The three questions to answer before touching any integration

• What data actually belongs in HubSpot

• How to choose a data model based on HubSpot tier and complexity

• The edge cases that break most implementations

• A comparison of integration options

• A reusable checklist for client onboarding

Start with Three Questions

Before recommending any integration approach, get clear answers to three questions:

1. What does the client actually want to do with this data in HubSpot?

Some clients want MRR visible on the company record so their CSMs can see it during QBRs. Others want HubSpot workflows to trigger when a subscription upgrades or churns. Others want board dashboards with revenue trends over time. A few want all of the above.

The use case determines the data model. MRR-on-the-record is a property update. Event-based workflows require subscription change history. Board-ready reporting requires historical data with period-over-period snapshots. These are architecturally different requirements, and conflating them leads to builds that technically work but don't serve anyone well.

2. How complex is the client's Stripe setup?

A SaaS company with one flat-rate plan, no trials, and no usage-based components is a simpler problem. A company with multiple products, tiered pricing, annual plans paid upfront, metered usage add-ons, and a history of manual subscription edits is not.

The complexity of the Stripe setup is the biggest predictor of implementation scope and ongoing maintenance burden. Walk through their Stripe configuration before scoping. Ask specifically about: multiple subscription line items per customer, usage-based or metered billing, free trials, annual vs. monthly mixing, proration handling, and any custom discount or coupon logic.

3. Who owns the data after handoff?

Stripe-to-HubSpot integrations break in specific ways over time: new products get added, pricing changes, Stripe configurations get edited, and the field mapping that worked six months ago no longer reflects reality. Somebody needs to own that ongoing maintenance. If it's the client, they need to understand how the integration works well enough to troubleshoot it. If it's the agency on retainer, that scope needs to be explicit.

What Data Should Live in HubSpot

Not everything in Stripe belongs in HubSpot. The goal is to bring across the data that changes how teams work, not to replicate Stripe inside a CRM.

Subscription status. Active, trialing, past due, canceled; every CSM and salesperson should be able to see this without opening Stripe. Map Stripe's statuses (trialing, active, past due, unpaid, canceled, incomplete, expired) to a custom property in HubSpot and teams can filter and segment by subscription health without any spreadsheets.

MRR per account. Current MRR at the company or contact level is the single most-requested property. It shows up in QBR prep, upsell conversations, and CS prioritization. Store it as a number property on the company record so it can be used in reports and list segmentation.

Subscription events as a timeline. Knowing an account is currently active at $500/month is useful. Knowing they started at $150, upgraded to $300, added a seat at $500, and had a failed payment last quarter is far more useful. Event history — new subscriptions, upgrades, downgrades, cancellations, churn — belongs on the HubSpot timeline so teams have context during conversations.

Renewal dates. Essential for CS workflow automation and pipeline forecasting, especially for annual contracts.

The Data Model Decision

Once you know what data you're bringing over, you need to decide where in HubSpot it lives.

The deals-based model is the default instinct. Create a deal for each subscription, sync revenue to the deal amount. It's familiar, but HubSpot deals are designed for one-time close events, not recurring subscription lifecycles. Deals don't handle MRR changes over time, don't model subscription upgrades gracefully, and are built for pipeline forecasting rather than subscription metrics. You can make it work, but you'll be fighting the data model.

Writing directly to Company or Contact records is the simplest option and works on any HubSpot tier. You create custom properties for MRR, status, renewal date, plan name, and write Stripe data directly to those fields. The tradeoff: you end up with a lot of properties on these objects, and the model gets cluttered over time, especially if you need to track multiple subscriptions per account or preserve event history. For clients with straightforward setups and no plans to get complex, it's a practical starting point.

Custom objects fit recurring revenue more cleanly: a Subscription object with its own properties, associated with the company record, keeping subscription data separate from deals and contacts. The catch is that custom objects require HubSpot Enterprise. For most small B2B SaaS companies on Starter or Pro, that's a non-starter. Don't architect an implementation that depends on a tier upgrade the client hasn't committed to.

App objects are how marketplace integrations like ClearSync store subscription data. They use structured records managed by the app, associated with companies and contacts, with no HubSpot Enterprise requirement. If you're evaluating a purpose-built tool, ask how it stores data and whether that storage has any tier dependencies. This is often the cleanest option for clients who aren't on Enterprise.

Edge Cases to Resolve Before You Pick a Tool

These are worth working through with the client before you commit to an approach, because some tools handle them and others don't.

Multiple subscription line items per customer. Base plan plus add-ons or seat pricing means multiple line items per subscription. How is MRR calculated? Is it the sum of all active lines, base plan only, or different logic per product? This needs a decision before you design the property model.

Prorations, discounts, and coupons. Prorations apply when subscriptions change mid-cycle; coupons and discounts adjust price permanently or temporarily. If the integration is doing MRR math, these must be handled correctly. A permanent coupon changes real MRR. A mid-month upgrade changes the invoice amount in ways that don't reflect the new monthly run rate. When this math is wrong, the MRR number in HubSpot won't match Stripe, and trust in the whole system goes with it.

Refunds. What happens to the MRR record in HubSpot when Stripe issues a refund? This gets overlooked constantly and tends to produce negative MRR entries or orphaned records in integrations that don't handle it explicitly.

Usage-based or metered billing. Metered billing finalizes at the end of each billing period, so MRR for a metered account is always an estimate until the invoice closes. Set client expectations upfront: HubSpot will show estimated or trailing MRR, not real-time usage data.

Annual plans paid upfront. A customer paying $6,000 annually is a $500/month subscription. Stripe records it as a single charge; the MRR calculation requires dividing it across twelve months. Most integration tools don't handle this automatically.

Historical backfill. Most clients want history, not just current state. How far back? Different tools handle this very differently, some don't support it at all. Scope it separately from ongoing sync.

Currency. Multi-currency billing requires a normalization decision: report in USD at today's rate, at the rate when the subscription started, or in original currency? No wrong answer, but it needs to be explicit.

Evaluating Integration Options

HubSpot's native Stripe Data Sync connects through the HubSpot Marketplace and syncs customer and payment data from Stripe to HubSpot. It's quick to set up, and works well for clients who just need to know which contacts are Stripe customers and how much they've paid over time. It's not made for SaaS businesses because it doesn't calculate MRR, doesn't track subscription change events, and has no support for complex billing. We have a full blog post on how this app works here.

Zapier or Make are more flexible but have real limitations. Neither is built to do MRR math or model subscription change events over time. You're pushing individual field values, not building a subscription record with history. You also can't import a client's full Stripe history, so you start from the connection date forward. When edge cases hit, the math breaks, it's typically the agency who debugs it, and the client loses confidence in the numbers. Fine for a genuinely simple setup with a few fields going forward. Not appropriate for clients with real subscription complexity.

Custom Stripe webhook-to-HubSpot builds give complete control and are appropriate for clients with requirements no off-the-shelf tool can meet. Also expensive to build and maintain. This is only the right choice when the client has internal engineering resources or the agency has explicit long-term technical ownership.

Purpose-built tools like ClearSync handle the logic the other options leave to you: MRR calculation methodology, subscription event tracking, proration and edge case handling, historical backfill, and app object storage that doesn't require HubSpot Enterprise. For agencies whose SaaS clients have real subscription operations and want data they can trust, this tier of tooling is worth evaluating.

The framework: match the tool to the complexity of the client's Stripe setup and what they actually need to do in HubSpot. Don't default to whatever's fastest to set up.

A Reusable Checklist for Stripe-to-HubSpot Integration Discovery

Discovery

• List specific use cases: what does the team want to do with subscription data in HubSpot?

• Walk through Stripe setup: products, pricing models, trial logic, discount/coupon use

• Identify multi-currency, usage-based, or annual-upfront scenarios

• Confirm who owns post-launch maintenance

Data model

• Confirm the client's HubSpot tier (Enterprise required for custom objects)

• Define where subscription data lives: Deals, Company/Contact properties, custom objects, or app objects

• Decide on MRR methodology for things like billing intervals, prorations, coupons, discounts, refunds, taxes, and currency.

• Decide if your customer wants a full historical backfill of Stripe data in HubSpot. Likely they do want to see all their Stripe customers and history in concert with their CRM data.

Integration selection

• Evaluate options against requirements: HubSpot's native Stripe sync app, Zapier/Make, purpose-built (like ClearSync), or custom

Pre-launch

• Test against real scenarios: new, upgrade, downgrade, churn, failed payment, coupon applied, etc

• Confirm MRR values match the client's expectations

• Train the client team on where to find data and how to interpret it

The Bigger Picture

The agencies that do this well treat the Stripe-to-HubSpot setup as a revenue operations problem, not just an integration project. The value is downstream: a CSM who sees an expansion opportunity before the QBR call, a RevOps team that can pull accurate MRR without leaving HubSpot, a founder who can walk into a board meeting with numbers they're confident in.

The clients who end up happy are almost always the ones whose agencies treated discovery as a real deliverable.

ClearSync is a HubSpot integration purpose-built for syncing Stripe subscription revenue data into HubSpot for RevOps and Finance teams. If you're a HubSpot agency evaluating integration options for SaaS clients, learn more or start a free 14 day trial.