Search "multi-company SaaS dashboard" and you'll find dozens of guides — almost all of them about building dashboardsfor your customers, not aboutthe companies you own. That's the multi-tenant playbook, and it solves a real problem. It just isn't yours. Portfolio operators need the opposite: one view of every company in the portfolio, with standardized metrics they didn't have to assemble by hand.
How do you build a dashboard for multiple SaaS companies?
The question itself is straightforward. The answers you find aren't — because the internet conflates two fundamentally different problems under the same words.
One problem is multi-tenancy: letting each of your customers see their own data inside your product. Stripe's embedded analytics, Retool multi-tenant templates, and most "white-label dashboard" vendors solve this. It's a product feature, not a portfolio tool.
The other problem — yours — is portfolio aggregation: pulling metrics from 5, 15, or 50 separate billing accounts into a single operating view. That tool barely exists, because the audience is small (holding companies, PE ops teams, venture studios) and the data normalization is hard.
The multi-tenant confusion — what Google shows vs what portfolio operators need
Seven of the top ten results for "multi-company SaaS dashboard" are tutorials on embedding analytics into a SaaS product for end users. They cover row-level security, tenant isolation, and white-label theming. Useful if you're building a product. Irrelevant if you're running a portfolio.
The remaining three results split between generic BI guides ("connect Looker to your data warehouse") and vendor pages that promise multi-company support but deliver separate workspaces you toggle between. Toggling isn't a portfolio view — it's the same single-company dashboard, repeated.
Portfolio operators don't need tenant isolation. They need the opposite: metric unification across entities they control, with rollups where rollups make sense and side-by-side comparisons where they don't.
What a portfolio metrics dashboard needs to show
Not every metric behaves the same way when you have multiple companies. Some aggregate naturally — you can sum them across the portfolio and the total means something. Others collapse into nonsense when summed and only make sense as comparisons. The architecture of your dashboard depends on knowing which is which.
Metrics that roll up — MRR, ARR, churn rate, NRR
MRR and ARR are additive. A holding company with three SaaS companies doing $120K, $85K, and $310K in MRR has $515K in portfolio MRR. That number is useful to a CFO, a board, or a lender. It answers "how big is the recurring revenue base across everything we own?"
Monthly Recurring Revenue
Predictable monthly revenue from active subscriptions, normalized from all billing intervals.
Annual Recurring Revenue
MRR multiplied by 12 — the annualized run rate of subscription revenue.
Churn dollars and expansion dollars also roll up. If Company A lost $8K in churned MRR while Company B expanded by $12K, the portfolio net is +$4K. Churn raterolls up only as a revenue-weighted average — a simple average of 3% and 7% doesn't account for one company being 4x the size of the other.
NRR follows the same logic. Portfolio-level NRR is the revenue-weighted composite: each company's retained revenue divided by total starting revenue. A $300K company retaining 112% and a $50K company retaining 85% produce a portfolio NRR of ~108%, not 98.5%.
Metrics that don't roll up — LTV:CAC, conversion rates — compare, don't sum
LTV:CAC is meaningless at the portfolio level. Company A sells $500/mo seats through inbound content at a $2K CAC. Company B sells $50K/yr enterprise contracts through outbound sales at a $45K CAC. Summing their LTVs and CACs produces a ratio that describes neither business.
The same applies to trial conversion rates, expansion rates, and payback periods. These metrics describe the unit economics of a specific business model — combining them across different models destroys the signal. The dashboard should show them side by side, not aggregated.
The practical split: any metric denominated in dollars rolls up. Any metric expressed as a ratio or percentage gets compared across companies in the same view but never summed.
Alerts and thresholds per company
A 4% monthly churn rate is a crisis for a $200 ACV self-serve product and normal for a consumer-adjacent tool with 30-day billing. Portfolio-level thresholds are useless — alerts need to fire per company, calibrated to that company's stage, ACV tier, and historical baseline.
The minimum useful alert set: MRR decline exceeding 5% month-over-month, churn rate spiking above the company's trailing-six-month average, NRR dropping below 100%, and failed payment rate exceeding 8%. Each threshold should be adjustable per entity without affecting the others.
Three approaches to multi-company dashboards
Every portfolio operations team ends up evaluating the same three options. They differ in setup cost, maintenance burden, and how well they handle the rollup-vs-comparison problem described above.
Spreadsheet aggregation — manual, brittle
The default. Each company exports a CSV or the ops team pulls numbers from Stripe manually. A master spreadsheet consolidates everything with VLOOKUP or IMPORTRANGE formulas. Setup takes a few hours; maintenance takes 4–8 hours per month per company.
The failure mode is silent. A company changes their plan structure, the export schema shifts by one column, and last month's revenue shows up as this month's. No alert fires because the number still looks plausible. You discover the error when a board member asks why Company C's MRR jumped 40% in a month it actually grew 4%.
At three companies, spreadsheet aggregation is tolerable. At seven, someone's full-time job is maintaining the sheet. At fifteen, the sheet is a liability.
BI tools — Looker, Metabase — flexible but requires data engineering
BI platforms solve the staleness problem (connect directly to databases) and the visualization problem (dashboards update automatically). They don't solve the definition problem. You still have to write the SQL that calculates MRR from raw Stripe events, and that SQL has to handle every edge case: annual contracts, mid-cycle upgrades, prorations, metered components, multi-currency normalization.
Setup time: 2–6 weeks per company, assuming a data engineer who knows the billing system's schema. Ongoing maintenance: Stripe changes its API or data model 3–4 times per year, and each change can break a query silently. The Metabase dashboard still renders — it just renders wrong numbers.
The data engineering cost scales linearly with the number of companies. Each new Stripe account needs its own ETL pipeline, its own schema mapping, and its own set of metric queries. A 10-company portfolio needs 10 pipelines maintained in parallel.
Purpose-built portfolio tools — direct billing integration
Purpose-built tools connect to each company's Stripe account via OAuth, normalize the billing data using standardized definitions, and present rollups and per-company views in a single interface. Setup is measured in minutes because the tool already knows how to parse Stripe's data model.
The trade-off is flexibility. A BI tool lets you query anything. A purpose-built tool gives you the 30–40 metrics that matter for SaaS portfolio management and calculates them the same way across every connected company. For most portfolio operators, that constraint is a feature — standardized definitions are the entire point.
| Feature | Spreadsheet | BI Tool | Purpose-Built |
|---|---|---|---|
| Setup time | Hours | Weeks | Minutes |
| Real-time data | |||
| Standardized definitions | |||
| Multi-company rollup | |||
| Peer benchmarks | |||
| Engineering required | |||
| Per-company alerts | |||
| Cost | Free | $$$ | $$ |
Standardizing definitions before building the dashboard
The dashboard is only as good as the metric definitions behind it. Two companies in the same portfolio can both report 5% monthly churn and mean completely different things: one includes downgrades in churn, the other doesn't. One counts a paused subscription as churned, the other counts it as active. Sum those numbers and you get a churn figure that describes neither company accurately.
The standardization problem has three layers. First, what counts as MRR: does a $12,000 annual contract contribute $1,000/mo from day one, or only after the first invoice settles? Second, how churn is calculated: logo churn, revenue churn, gross vs net, and whether reactivations offset churn in the month they occur or the month they originally churned. Third, how expansion is attributed: does a mid-cycle upgrade count in the month of the change or the month of the next full invoice?
Every one of these decisions changes the reported number by 2–8%. Across a portfolio, inconsistent definitions can swing the aggregate MRR by 10–15% depending on which companies use which convention. That margin of error is larger than most month-over-month growth rates, which means you can't distinguish real growth from definitional noise.
The fix isn't documentation — it's computation. Write the definition once, in code, and apply it to every company's billing data uniformly. The operator doesn't choose a churn methodology per company; the system enforces one methodology across the portfolio. Differences in reported numbers then reflect actual operational differences, not accounting choices.
How North Metric handles multi-company views
North Metric connects to each portfolio company's Stripe account individually via OAuth. Each connection pulls subscription, invoice, and payment data nightly, normalizes it using the same equation engine, and stores daily metric snapshots.
The portfolio view rolls up additive metrics — total MRR, total ARR, aggregate churn dollars, portfolio-level NRR — while showing ratio metrics side by side. A holding company with eight SaaS companies sees one number for "how much recurring revenue do we control" and eight rows for "which company has the best unit economics."
Definitions are locked at the platform level. MRR is calculated the same way whether the company bills monthly, annually, or on a usage-plus-base model. Churn uses revenue churn (not logo churn), counts downgrades, excludes pauses, and handles reactivations in the reactivation month. There's no per-company toggle for methodology because the entire value of a portfolio view is that the numbers are comparable.
Alerts fire per company against company-specific thresholds. A company running 2% monthly churn triggers at 3.5%; a company running 6% triggers at 8%. The alert means "this company deviated from its own baseline," not "this company crossed a universal line."
Benchmarks add context that internal data alone can't provide. Each company's metrics are scored against percentile benchmarks for its ACV tier and growth stage. A portfolio operator can see that Company A's 93% GRR is 70th percentile while Company B's 88% GRR is 45th percentile — information that raw numbers on their own don't convey.
The result is a dashboard that doesn't require a data engineer to build, a spreadsheet jockey to maintain, or a monthly meeting to update. Connect Stripe, wait for the first nightly snapshot, and the portfolio view populates itself with numbers you can trust because they were never touched by a human formula.