How to build a SaaS revenue dashboard: metrics, data sources, and structure

A good SaaS revenue dashboard answers three questions in under thirty seconds: how much recurring revenue do we have, how fast is it changing, and where is the change coming from. Anything else is supporting detail.

This guide walks through building that dashboard from scratch: which metrics to include, where the underlying data comes from, how to lay it out, and the mistakes that make revenue dashboards untrustworthy. It fits SaaS companies between roughly $50K and $50M in ARR that want a single source of truth for revenue without buying a heavyweight finance platform.

What a SaaS revenue dashboard should actually do

A revenue dashboard has a narrower job than people often assume. It gives the leadership team and operators an accurate, current view of recurring revenue and the levers that move it, and leaves the finance close, forecasting, and customer success work to other tools.

That means three layers:

1. Top-line health. Current MRR or ARR, growth rate, and net new ARR for the period.
2. Composition. Where new ARR is coming from (new business, expansion, contraction, churn) and how that mix is shifting.
3. Segments. Revenue by plan, customer cohort, segment, or channel, with enough detail to explain why the top line is moving.

If your dashboard answers those three things clearly, it is doing its job. Pipeline coverage, support tickets, NPS, and product usage belong on adjacent dashboards.

The metrics that belong on a SaaS revenue dashboard

Pick a small core set and resist the temptation to add more. The following metrics cover most SaaS businesses and map directly to investor and board reporting.

Recurring revenue: MRR and ARR

MRR (monthly recurring revenue) and ARR (annual recurring revenue) are the same number expressed at different cadences. ARR is MRR multiplied by twelve.

Defining what counts takes more thought. A clean definition includes only normalized recurring subscription revenue from active paying customers, and typically excludes:

• Usage-based overages that are not contractually committed
• One-time setup fees, professional services, and implementation revenue
• Free trials and unpaid pilots
• Discounts that are clearly time-bound (apply the post-discount rate, or annualize correctly)

Pick the definition once, write it down, and apply it consistently. People stop trusting a revenue dashboard fastest when two views of MRR don’t reconcile, often because someone counted a pilot or a one-time fee in one place but not another.

Net new ARR and the growth waterfall

Net new ARR for a period is the most useful single number for understanding momentum. It breaks down into four components, known as the “growth waterfall”:

• New business ARR: ARR from customers who were not paying customers at the start of the period.
• Expansion ARR: additional ARR from existing customers (seat upgrades, plan upgrades, additional products).
• Contraction ARR: reductions in ARR from customers who downgraded but did not churn.
• Churned ARR: ARR lost from customers who fully cancelled or were involuntarily churned.

Net new ARR = New + Expansion − Contraction − Churned. Shown as a stacked bar over time, this breakdown is often the most-referenced visual on a SaaS revenue dashboard because it explains why ARR is moving.

Retention metrics: GRR and NRR

Gross revenue retention (GRR) measures what percentage of starting ARR you retained from existing customers, ignoring expansion. Net revenue retention (NRR) measures the same thing but counts expansion.

• GRR = (Starting ARR − Churned ARR − Contraction ARR) / Starting ARR
• NRR = (Starting ARR + Expansion ARR − Churned ARR − Contraction ARR) / Starting ARR

Both should be calculated on a trailing-twelve-month basis to smooth out monthly noise. NRR above 100% means expansion from existing customers more than offsets churn and contraction, so the existing base grows even without new sales.

Customer counts and ARPA

Logo growth complements ARR growth. Track:

• Active customers: paying accounts at the end of the period.
• New logos: paying accounts added in the period.
• Churned logos: paying accounts that fully cancelled.
• ARPA (average revenue per account) = total ARR / active customers.

ARPA is useful because the same ARR growth can come from many small customers or a few large ones, and the implications for sales motion, support cost, and concentration risk differ.

Optional but useful

Depending on your business, also consider:

• CAC payback: months of gross margin needed to recover acquisition cost. More relevant if you have meaningful sales and marketing spend.
• Quick ratio: (New ARR + Expansion ARR) / (Churned ARR + Contraction ARR). A simple efficiency signal, and a ratio above 4 is generally considered healthy.
• Bookings vs. ARR: bookings include new contracts not yet live. Useful if your contract lengths vary meaningfully.
• Billings or cash collected: actual cash, distinct from accrued recurring revenue. Important if your subscription terms vary (monthly, annual prepaid, multi-year).

CAC, LTV, and unit economics typically belong on a separate growth or finance dashboard, since mixing them in dilutes the revenue narrative.

Where the data actually comes from

Teams tend to underestimate this part. A SaaS revenue dashboard typically pulls from three or four systems, and most of the work goes into reconciling them.

Stripe (or your billing system)

For most SaaS companies, the billing system (Stripe, Chargebee, Recurly, Maxio, Paddle) is the system of record for what was charged. It is the cleanest source for cash collected and for recurring charges, but that does not automatically make it a clean source for MRR.

Stripe in particular requires care. A few specific gotchas:

• A subscription’s plan.amount is not always equal to its effective monthly revenue. Annual plans, custom prices, and quantity-based pricing all complicate the math.
• Refunds, disputes, and credit notes need to be subtracted from cash collected, but should usually not reduce MRR retroactively unless they reflect a true cancellation.
• Trials, paused subscriptions, and unpaid invoices need explicit rules. For example, does an unpaid past-due account still count as MRR for thirty days, or sixty?
• Proration on plan changes can create misleading one-time line items that look like expansion or contraction.

Stripe’s own revenue recognition reports help, as do tools like ChartMogul, Maxio, or Mosaic that specialize in SaaS metrics out of Stripe data. If you are doing it yourself, the cleanest pattern is to compute MRR from a subscription snapshot table rather than from Stripe events.

Your application database

Your app database tells you which accounts are active, what plan they are on, when they signed up, and any internal flags (paying / trial / churned / paused). You need it for segment analysis: revenue by plan, signup cohort, region, self-serve vs. sales-led, and so on.

The dashboard usually needs to join billing data with application data on a customer or workspace identifier. Definitions matter most at this join: does “customer” mean a Stripe customer, a workspace, an organization, or a user?

Your CRM (for sales-led motions)

If you have a sales team, the CRM (Salesforce, HubSpot, Attio) is where new ARR, expansion, and downgrades get attributed to deals, segments, and reps. Pull from the CRM if you want revenue by segment, by industry, or by sales rep. Skip it if you are pure self-serve.

A data warehouse, if you have one

Beyond a few thousand customers, the usual pattern is to centralize Stripe, your app database, and your CRM in a warehouse (Snowflake, BigQuery, Redshift, ClickHouse, or Postgres) using an ELT tool like Fivetran, Airbyte, or Stitch, then build the dashboard on top of clean modeled tables.

For smaller teams, you can build a credible revenue dashboard directly on Postgres with a few well-designed views and a BI tool that connects natively to your database. You can skip the warehouse until your data volume or query complexity demands one.

A reference structure for the dashboard

The structure below works for most B2B SaaS companies and follows the order in which leadership teams scan the data.

Section 1: top-line scorecard

Large KPI cards at the top, visible without scrolling.

• Current ARR (or MRR), with month-over-month and year-over-year change
• Net new ARR for the current month, with comparison to plan or prior period
• Active customers, with delta
• NRR (trailing twelve months)
• GRR (trailing twelve months)

Someone with thirty seconds should be able to tell from this section alone whether things are on track.

Section 2: ARR over time

A single line chart of ARR (or MRR) over the past 12–24 months, with a clear marker for the current period. Include a comparison line to plan if you have one.

Investors and the board will look at this chart first, so keep it clean. Don’t add a second axis or try to overlay every metric onto it.

Section 3: the growth waterfall

A stacked bar chart by month showing new business, expansion, contraction, and churn. It is the most analytically dense chart on the dashboard, and it settles most “why is ARR slowing?” conversations.

Pair it with the same data shown as a small table for the most recent period, with absolute numbers and percentages.

Section 4: retention

NRR and GRR by trailing twelve months, plotted over time. Optionally, add a cohort retention table with starting cohorts as rows, months since signup as columns, and retained ARR as the value. Cohort tables are dense, so only include one if your audience knows how to read it.

Section 5: segmentation

These are the “why” charts. Choose two or three breakdowns that match how your business segments revenue:

• ARR by plan (e.g., Free, Team, Business, Enterprise)
• ARR by acquisition channel (self-serve, sales-led, partner)
• ARR by industry, geography, or company size
• ARPA over time

If you have more than four segmentation views, consider splitting them into a separate “revenue segments” dashboard so the main revenue dashboard stays tight.

Section 6: a small table of recent customer changes

A small table at the bottom listing recent material customer events (new deals over $X, expansions over $Y, churns over $Z) is often overlooked but useful. It ties the aggregate numbers to specific accounts, and it is the part the CEO will read most carefully.

Refresh cadence and freshness

Most revenue dashboards do not need to be real-time, and a daily refresh is enough for nearly every SaaS team. The exceptions:

• High-velocity self-serve businesses with hundreds of signups and churns per day may want an intra-day refresh on top-line ARR.
• The last day of the month or quarter, when finance is reconciling and more frequent refreshes are temporarily worth it.

A standard pattern is a daily refresh at 6 AM in the company’s primary time zone, so the dashboard is fresh before the morning standup. Pair this with an automated alert that flags large day-over-day changes in MRR or churn so people don’t have to manually scan for surprises.

Common mistakes that quietly break revenue dashboards

Keeping the numbers trustworthy over time is usually harder than the technical setup.

Inconsistent MRR definition. The dashboard says one number, the board deck says another, the investor update says a third. Pick one definition, document it, and rebuild any view that disagrees.

Counting one-time revenue as MRR. Setup fees, professional services, and one-time charges sneak into MRR through Stripe metadata or product mappings. Audit the source data quarterly and exclude anything that is not contractually recurring.

Mixing booked and recognized revenue. Bookings (signed contracts) and recognized revenue (delivered) are different numbers and should not be summed together on the same chart. If you show both, label them clearly.

Treating annual prepayments incorrectly. A customer who pays $12,000 for an annual plan is $1,000 of MRR, not $12,000. This sounds obvious but is one of the most common errors in homegrown dashboards built directly off Stripe charges.

Churn timing ambiguity. Decide whether churn is recognized when the customer cancels, when their access ends, or when their last paid period ends. All three are defensible. Pick one and document it.

Not handling currency. If you have customers in multiple currencies, decide whether ARR is reported in USD using the period-end FX rate, the period-average rate, or contract-locked rates. Mixing methods will make trends look wrong.

Dashboards without owners. A revenue dashboard without an owner becomes inaccurate within a quarter. Pricing changes, plan renames, and new product launches all change the source data. Assign an owner (usually finance or revenue ops) and review it monthly.

Build vs. buy

There are three reasonable paths, depending on team size and complexity:

Path 1: Specialist SaaS metrics tools. ChartMogul, Maxio, Baremetrics, and similar tools plug directly into Stripe and produce a usable revenue dashboard within a day. They are the fastest route for teams that do not have a data team and run primarily on Stripe. The tradeoff is limited customization: they enforce their own definitions of MRR and segments, which may not match how you want to report.

Path 2: A general BI tool on top of your own data. Tools like Basedash, Metabase, Hex, Mode, or Looker Studio let you build a fully customized dashboard from your warehouse or production database. Choose this path if you want to control the definitions, segment by your own business logic, and combine billing data with product and CRM data. It takes more setup, but the result matches how your team thinks about the business.

Path 3: A hybrid. Use a specialist tool for raw MRR plumbing and a BI tool for everything segment-, cohort-, and product-related. Common at companies between roughly $5M and $50M in ARR where finance owns the SaaS metrics tool and the data team owns the BI layer.

For teams already working in a database-connected BI tool, Basedash lets you describe the dashboard you want (for example, “show me ARR by month with a stacked bar of new, expansion, contraction, and churn, broken down by plan”) and build it from your Stripe and application data without wiring each chart manually. That works well when you want a customized revenue dashboard but don’t want to spend a week of analyst time on it.

A short checklist before you ship

Before publishing a SaaS revenue dashboard internally, verify:

• One documented definition of MRR / ARR exists and is linked from the dashboard.
• The top-line numbers reconcile to the most recent board deck or investor update.
• The growth waterfall components sum to net new ARR exactly.
• Annual subscriptions are correctly normalized to monthly.
• Trials, pauses, and unpaid past-due accounts are handled by an explicit rule.
• Churn is defined by a single event (cancellation date vs. access-end date) and applied consistently.
• The dashboard has a named owner and a monthly review on the calendar.
• A daily refresh runs at a fixed time, and someone is alerted if it fails.

Most of the effort in a revenue dashboard built this way goes into the definitions, and the charts are the easy part. It is also the dashboard the leadership team will open every morning and the one investors will ask to see during diligence, so getting it right is worth the time.

If you are working out how this dashboard fits into a broader BI setup, the principles in how to build dashboards that drive decisions apply directly: start with the decisions the leadership team needs to make, keep the metric set small, and design for the audience scanning the dashboard rather than the analyst building it.