HubSpot Stripe integration.
Subscriptions that report to the pipeline. Subscription state lives in the billing platform and the CRM knows nothing about it. So renewals are worked from a spreadsheet, expansion is invisible until it shows up in the bank, and net revenue retention is a quarterly reconstruction.
Churn shows up in the bank, not the CRM.
The customer downgraded six weeks ago and the account manager found out when the finance report came round. Subscription state is the most important fact about a recurring revenue customer and it is usually the one fact the CRM does not hold.
They downgraded in March. Nobody told sales.
Billing — the blind spotMaking subscription state first class.
Subscriptions as records
Plan, seats, MRR, term dates and discount held against the company as a real object, not pasted into a note that goes stale the next time anything changes.
Plan changes as dated events
Upgrades, downgrades and cancellations recorded with dates, which is the only way net revenue retention survives a repackaging of your pricing.
Renewals as a pipeline
Renewal deals created from term dates far enough ahead that somebody can act, with usage and support signals attached as health indicators.
Failed payments reach a human
Involuntary churn is the cheapest churn to prevent. Dunning state surfaces as a task for the account owner instead of an email nobody reads.
Webhooks handled properly
Idempotent handlers, retries and a dead letter path, because a missed webhook is a customer whose record is wrong until somebody notices.
Reconciliation against the source
Scheduled comparison of subscription state in both systems, so drift is a report rather than a discovery.
Built to a contract, not to a connector.
Draw the boundary
Which system owns which field, in writing, before a line of code. Most broken integrations are two systems both believing they are the source of truth.
Model the join
The key that matches a record on one side to a record on the other, and the rule for what happens when it does not match — because it will not match.
Build and instrument
Sync built with retries, idempotency and a dead letter path, plus logging you can read without opening a console.
Reconcile
Counts compared on both sides on a schedule, with a report that names the drift rather than a green tick that hides it.
Hand over
A runbook covering the three failures that actually happen, so the next person does not have to reverse-engineer the design from the logs.
MRR gets recalculated in the CRM.
The temptation is to compute MRR in HubSpot with a formula. Then the billing platform changes proration behaviour and there are two numbers. The billing system owns the number; the CRM stores what it was told and says when it was told.
What people ask before they commit.
Does the native Stripe integration not do this?
It handles payments and basic subscription visibility well. What it does not do is model plan changes as dated events or drive a renewal pipeline, which is where the revenue work actually is.
Can we see MRR by segment in HubSpot?
Yes, once subscription state is on the company record. Then MRR by industry, by source, by owner or by plan is a standard report rather than an export and a pivot table.
What about usage-based billing?
Usage metering stays in the billing platform. We surface the aggregates that matter — consumption against commitment, overage trend — so the account team can act before the invoice surprises somebody.
How long does it take?
Three to six weeks for a full implementation including the renewal pipeline. Pure visibility is faster.
Does this work with Recurly, Paddle or Zuora?
Yes. The model is the same for any subscription platform with a decent API; only the field names move.
Where people go from here.
Renewals worked from the system.
Tell us what you are running
What the system does today, where it breaks, and when it has to work. An engineer reads it — you get an answer inside one business day, not a sequence.