Revenue Attribution by ICP Segment: Connecting Stripe Data to Enrichment

The MRR number that hides the question that matters

Every SaaS dashboard has an MRR chart. Almost none of them can answer "which customers is that money actually coming from." Finance can tell you total revenue grew 12% this quarter. They usually can't tell you whether that growth came from the accounts your product was built for, or from a wave of poor-fit signups who will churn the moment a renewal comes up.

That gap exists because billing systems and enrichment data live in separate worlds. Stripe knows who paid and how much. Your enrichment or CRM data knows what kind of company that customer is and how well they match your ICP. Nobody joins the two until a board deck forces someone to do it by hand in a spreadsheet, usually under deadline, usually once.

Revenue attribution by ICP segment just means keeping that join running all the time instead of rebuilding it under pressure once a quarter.

Why blended revenue numbers mislead growth teams

A single revenue total, or even a revenue-by-plan breakdown, averages away the thing you actually need to know: whether your ideal customers are the ones driving growth, or whether growth is coming from the long tail of accounts that converted but don't look anything like your best customers.

This matters for three different teams at once:

• Growth and marketing need to know which channels and campaigns bring in revenue from high-fit accounts, not just any accounts, so spend goes toward the signups that actually compound.
• Product needs to know whether the roadmap is serving the segment paying the bills, or whether a vocal minority of low-value accounts is steering feature requests.
• Finance and leadership need NRR and expansion numbers broken out by segment, because a healthy blended NRR can hide a core ICP segment that's flat while a low-fit segment inflates the average with one-time upsells.

Without ICP-segmented revenue, all three teams are arguing from the same blended chart and reaching different conclusions, because the chart genuinely supports more than one story.

What you need before you can attribute anything

Revenue attribution by segment isn't a BI project. It's three data points joined on the same key, kept current instead of rebuilt as a one-off export.

1. A customer ID that matches across systems. Usually the billing customer ID (Stripe customer ID) mapped to the account or company record in your product database. If signups aren't already linked to a company record, this is the step that blocks everything else.
2. An ICP score per account, generated at signup and refreshed as company data changes. A score that was accurate on day one and never updated again will misattribute revenue for any account that grew, pivoted, or was mis-scored from thin signup data.
3. Revenue events from billing, tagged with the plan, MRR/ARR value, and event type (new, expansion, contraction, churn), not just a running total.

With those three joined on company ID, a basic segmented revenue view is a query, not a quarter-long project. The hard part is rarely the math. It's that most teams have never linked billing customer IDs to enrichment data in the first place, so step one eats most of the effort.

A segmentation model that survives contact with finance

Finance teams are rightly skeptical of "soft" segments that can't be reproduced or audited. A model that holds up needs a small, stable number of tiers with a clear scoring source, not five fuzzy buckets that shift every time someone re-reads the ICP doc.

A workable starting split:

Tier	Definition	What to watch
Core ICP	Score above your top threshold, matches firmographic and usage profile of your best customers	NRR, expansion rate, LTV:CAC
Adjacent	Partial match (right company size or industry but missing a key signal like seniority, use case, or tech stack)	Conversion rate to Core, time-to-value
Off-ICP	Converted despite low fit, usually from broad top-of-funnel or a generic campaign	Gross churn, support cost, CAC payback

Attach this tier to every revenue event, not just to the account once at signup. An account's tier can shift as it grows into your ICP or drifts away from it, and a revenue report that uses a stale tier from twelve months ago will misattribute both the win and the risk.

Reading the report once it exists

A segmented revenue report earns its keep the first time it changes a decision, not the first time it renders. A few patterns worth checking monthly:

• New MRR by tier, as a share of total new MRR. If Core ICP's share is shrinking month over month, acquisition is drifting away from your best-fit customers even if total new MRR looks fine.
• Expansion MRR concentration. Expansion revenue should skew heavily toward Core ICP. If Adjacent or Off-ICP accounts are expanding at a similar rate, either your ICP model is wrong or those accounts are being under-scored.
• Churned MRR by tier, compared to that tier's share of total MRR. Off-ICP churn above its revenue share is expected and not alarming. Core ICP churn above its revenue share is the number that should trigger a root-cause review, the same way churn risk by ICP segment treats it.
• CAC payback by tier. Off-ICP accounts often look fine on acquisition cost until you factor in the support load and churn rate; segmented payback catches that before it shows up as a margin problem.

A worked example

A 40-person SaaS company reports $180K in new MRR for the quarter and calls it a strong number. Split by tier: Core ICP contributed $70K, Adjacent contributed $60K, and Off-ICP, mostly signups from a paid campaign that targeted job title but not company size, contributed $50K. Three months later, 60% of that Off-ICP cohort has churned, while Core ICP retained at 95%. The quarter looked identical in the blended view and the segmented view on day one. Only the segmented view would have flagged, before the churn happened, that a third of new revenue was coming from a tier with a historically short lifespan.

Where this breaks in practice

The join never gets built. Billing IDs and enrichment records stay in separate systems because nobody owns connecting them. This is usually a one-time engineering task (map Stripe customer ID to company ID at signup or first payment) rather than an ongoing one, which makes it an easy thing to keep deprioritizing until a board question forces it.

Scores go stale. An ICP score computed once at signup and never refreshed will misattribute every account that changes size, role mix, or use case afterward. ICP drift is the same failure mode here as it is in routing. The fix is a periodic re-score, not a one-time calculation.

Tiers multiply until nobody trusts them. Once a report exists, there's pressure to add more granularity: five tiers, then eight, then a different cut for every team that asks. Three tiers mapped to one scoring source is harder to argue with than eight tiers nobody can explain in a meeting.

Expansion and contraction get bundled into "net" too early. A net revenue number by tier hides whether a segment is growing because existing accounts expand or because new signups are backfilling churn. Keep new, expansion, contraction, and churn as separate line items per tier for at least the first few reporting cycles.

A monthly checklist

• Confirm every active billing customer ID is still linked to a company record (new integrations and manual signups are the usual gap).
• Re-score ICP fit for any account with a material change in headcount, plan, or usage since the last score.
• Pull new, expansion, contraction, and churned MRR for the month, tagged by tier at the time of the event.
• Compare each tier's revenue share to its share of total accounts. A tier punching above its account count is where to look first.
• Flag any Core ICP churn or contraction for a root-cause note before it's lost in the blended total.
• Share the segmented view alongside the blended total in the growth and finance review, not instead of it. Finance still needs the top-line number too.

Getting the join built without a data team

The slow part of this is almost never the reporting. It's that most teams haven't connected billing data to enrichment in the first place, so every attempt at a segmented view starts with a manual export-and-merge in a spreadsheet. That works once. It doesn't survive a second quarter.

Groful enriches signups and existing accounts with the company and role data needed to score ICP fit automatically, and keeps that score current as accounts change, which is the piece that makes segmented revenue reporting durable instead of a one-off exercise. If you're running this kind of attribution manually today, teammate discovery and ICP scoring are the two pieces worth automating first, since they feed both the routing decisions you're already making and the revenue report you're trying to build.

If you want to see what this looks like against your own account list, book a walkthrough or check pricing for the tier that fits your current signup volume.