Insights

MRR Reporting: Churn, Expansion, ARR, and BigQuery Model

MRR reporting guide for growing companies: define recurring revenue, churn, expansion, ARR, subscription movements, reconciliation checks, and BigQuery reporting tables.

MRR reporting gives leadership a direct view of recurring revenue quality.

It sounds simple: how much monthly recurring revenue does the company have?

In practice, that number becomes difficult to defend when the business grows across billing plans, discounts, contract amendments, product tiers, customer hierarchies, churn definitions, upgrades, downgrades, reactivations, and finance adjustments.

For CFOs, founders, COOs, finance leaders, heads of data, revenue leaders, and board-facing teams, MRR reporting is not only a SaaS dashboard metric. It is a finance and operating control. It affects revenue forecasting, cash planning, growth efficiency, board reporting, retention work, pricing decisions, and sales investment.

The strongest MRR report does not stop at one headline number.

It explains why recurring revenue changed, which customers drove the movement, which rules were applied, which source systems agree, and which exceptions need review before leadership uses the number.

If your company already has revenue reporting, revenue recognition reporting, CAC payback reporting, CFO dashboard requirements, and board reporting, MRR reporting becomes the recurring-revenue layer that connects commercial momentum to finance-approved definitions.

For teams trying to model recurring revenue from billing, CRM, accounting, subscription, and product data instead of monthly spreadsheet exports, BigQuery reporting automation is the most relevant service path.

What MRR reporting means

MRR means monthly recurring revenue.

MRR reporting shows the recurring revenue base at a point in time and the movements that changed it during a period.

A useful report should answer:

• how much recurring revenue existed at the beginning of the period
• how much new recurring revenue was added
• how much recurring revenue expanded from existing customers
• how much recurring revenue contracted from downgrades, usage changes, discounts, or scope reductions
• how much recurring revenue was lost to churn
• how much recurring revenue was reactivated
• how much recurring revenue existed at the end of the period
• how MRR converts to ARR
• which customers, products, plans, channels, or cohorts drove the movement
• which records were excluded and why
• how the MRR view reconciles to billing, CRM, accounting, or finance-approved revenue reporting

MRR is most useful for subscription, recurring service, managed service, membership, retainer, or usage-based businesses that need to separate recurring commercial performance from one-time revenue.

It can also be useful for non-SaaS companies that have recurring contracts, maintenance plans, managed services, subscription products, annual agreements, or repeatable retainers.

The report should not pretend that every business has the same recurring revenue model. A clean MRR model starts by defining the company's recurring revenue rules before publishing the metric broadly.

Why MRR becomes a leadership issue

MRR becomes important when the company needs to understand whether growth is durable.

Leadership starts asking questions like:

• Is recurring revenue growing because we are winning new customers or expanding existing ones?
• Are upgrades being offset by downgrades?
• Is churn concentrated in a product, cohort, plan, segment, channel, or customer-success owner?
• Is sales pipeline converting into recurring revenue or mostly one-time revenue?
• Does the board pack show the same recurring revenue logic as finance and the CRM?
• Are discounts, credits, paused subscriptions, and failed payments handled consistently?
• Is ARR based on current MRR, contracted annual value, recognized revenue, or billing schedules?
• Are customer counts, active accounts, and logo churn using the same identity logic?
• Are forecast assumptions based on actual expansion, contraction, and churn patterns?
• Can finance explain why MRR changed without rebuilding the number manually?

Those questions are hard to answer from one system.

Billing systems may know invoices, subscriptions, plans, billing intervals, coupon codes, credit memos, and payment status. The CRM may know opportunities, contract terms, owners, sources, segments, and expansion deals. Accounting systems may know recognized revenue, deferred revenue, refunds, and close adjustments. Product systems may know usage, seats, workspaces, account activity, and customer status. Customer-success systems may know renewal risk, health scores, cancellations, and reactivation work.

When Stripe is the subscription or payment system, a focused Stripe to BigQuery reporting model can preserve subscription, invoice, payment, refund, fee, dispute, and payout detail before MRR movements are modeled for leadership.

MRR reporting needs to connect those views without hiding the differences between them.

Start with the recurring revenue definition

The first decision is what qualifies as recurring revenue.

This should be explicit.

Common recurring revenue categories include:

• software subscriptions
• managed service retainers
• support plans
• membership fees
• maintenance contracts
• subscription product plans
• committed usage contracts
• recurring platform fees
• recurring professional services retainers
• annual contracts converted into monthly value

Common exclusions include:

• implementation fees
• setup fees
• hardware or inventory sales
• pass-through costs
• one-time services
• migration projects
• ad hoc consulting
• reimbursed expenses
• taxes
• shipping
• temporary credits that should not reduce contractual recurring value

The right rule depends on the decision the report supports.

A finance-owned MRR view may exclude non-recurring service fees even if the invoice total is larger. A bookings view may include contracted recurring value that has not started billing yet. A recognized revenue view may lag MRR when annual prepayments, deferred revenue, or performance obligations matter.

Those views can all be useful, but they should not be mixed.

If the company still uses booked, billed, recognized, collected, and forecast revenue interchangeably, stabilize the broader revenue reporting model before treating MRR as a board-ready metric.

Separate MRR from ARR, revenue, and cash

MRR is related to ARR, revenue, billing, and cash, but it is not the same thing.

MRR shows normalized monthly recurring revenue.

ARR usually annualizes recurring revenue, often by multiplying ending MRR by 12. In some companies, ARR is instead based on active annual contract value. That difference matters.

Billed revenue shows what has been invoiced. Recognized revenue shows what finance considers earned. Cash shows what has been collected. Contract value may show the total commercial commitment over a term.

A useful reporting layer should preserve these views:

• MRR for normalized recurring revenue
• ARR for annualized recurring run rate or contracted annual recurring value
• bookings for signed commercial commitments
• billings for invoiced amounts
• recognized revenue for finance-approved performance
• collected cash for liquidity
• deferred revenue where billing precedes recognition
• remaining contract value where commitments extend beyond the current period

The dashboard can display several of these views, but each label must be precise.

This is especially important for board reporting. A board should not have to infer whether ARR is a run-rate calculation, contracted value, recognized revenue annualized, or a blended spreadsheet metric.

Define the MRR movement bridge

The MRR movement bridge is the heart of the report.

It explains how beginning MRR became ending MRR.

A practical bridge usually includes:

• beginning MRR
• new MRR
• expansion MRR
• contraction MRR
• churned MRR
• reactivation MRR
• FX or currency movement where relevant
• plan or product reclassification where relevant
• manual adjustments where approved
• ending MRR

Each movement needs a rule.

New MRR usually comes from a customer or subscription that did not have recurring revenue in the prior period. Expansion MRR usually comes from an existing customer increasing recurring value. Contraction MRR usually comes from an existing customer lowering recurring value. Churned MRR usually comes from recurring revenue that ended. Reactivation MRR usually comes from a previously churned or inactive customer returning.

The definitions sound straightforward until edge cases appear.

Examples include:

• a customer cancels one product but keeps another
• a customer moves from monthly to annual billing
• a customer pauses service for one month
• a failed payment later succeeds
• a discount expires and MRR rises
• a temporary credit reduces an invoice
• a product bundle is split into separate lines
• a customer changes parent account
• a contract amendment backdates the start date
• a customer churns and returns in the same quarter

The report should define how each case is handled.

Without that movement logic, the company may have an ending MRR number but no reliable explanation for why it changed.

Customer identity controls the answer

MRR reporting depends on customer identity.

The company needs to define whether the reporting grain is:

• billing customer
• subscription
• CRM account
• legal entity
• parent account
• workspace
• product tenant
• contract
• location
• end customer

This matters because customer counts, logo churn, net revenue retention, expansion, contraction, and segment reporting can all change depending on the identity rule.

For example, one enterprise parent may have several billing customers, workspaces, contracts, or product tenants. If one workspace cancels but the parent expands elsewhere, the report needs clear rules for whether that is logo churn, product churn, contraction, net expansion, or an internal account movement.

The customer map should define:

• source customer IDs
• CRM account IDs
• billing customer IDs
• parent-child relationships
• active and inactive statuses
• acquisition date
• churn date
• reactivation date
• segment
• sales owner
• customer-success owner
• product or plan ownership
• approved merge and split rules

If customer identity is weak, every recurring revenue metric becomes fragile.

For companies using CRM and accounting data together, the QuickBooks to BigQuery reporting pattern shows a common approach for centralizing customer and account mappings before building finance reporting logic.

Discounts, credits, and coupons need policy

Discount treatment is one of the main reasons MRR reporting loses trust.

Different teams often want different answers.

Sales may want to show contracted list price. Finance may want to show net recurring revenue after discounts. Customer success may care about current customer commitment. The board may care about normalized recurring run rate and whether discounts are hiding pricing pressure.

The model should define how it handles:

• recurring discounts
• temporary promotional discounts
• coupons
• credits
• refunds
• service concessions
• price overrides
• grandfathered plans
• ramped contracts
• free months
• delayed start dates
• partial-period proration

For many companies, the most useful first version separates gross MRR from net MRR.

Gross MRR shows recurring revenue before discounts and credits. Net MRR shows the recurring revenue after approved recurring discounts and recurring credits. Temporary one-time credits may need their own field so they do not rewrite the recurring revenue base.

If discounts, credits, refunds, and concessions are already causing margin questions, connect MRR reporting to margin leakage reporting. Recurring revenue growth can look healthy while pricing discipline or customer economics quietly weakens.

Churn reporting should be specific

Churn is not one number.

MRR reporting may need several churn views:

• gross revenue churn
• net revenue churn
• logo churn
• product churn
• voluntary churn
• involuntary churn
• contraction
• cancellation requests
• effective churn
• churned MRR
• churned ARR

Each answers a different question.

Gross revenue churn focuses on recurring revenue lost before expansion offsets it. Net revenue churn considers expansion and contraction together. Logo churn focuses on customer count. Product churn may show customers leaving one product while staying with the company. Involuntary churn may come from payment failure or administrative issues rather than customer intent.

The report should label the churn view clearly.

A company can have low logo churn and still have meaningful contraction. It can have high expansion that hides churn in a net revenue retention view. It can have payment-related churn that should trigger billing operations work rather than product intervention.

For leadership, the useful question is not only whether churn increased. It is which customers, cohorts, products, channels, plans, contract terms, implementation experiences, or service issues caused the movement.

That is where MRR connects to operations reporting. Retention problems often appear in the recurring revenue bridge after they have already appeared in onboarding, fulfillment, support, product usage, or service delivery data.

Expansion and contraction deserve the same rigor

Expansion is often treated as good news without enough inspection.

It still needs clean rules.

Expansion may come from:

• seat growth
• usage growth
• plan upgrades
• add-on products
• additional locations
• increased committed volume
• price increases
• renewal uplift
• cross-sell
• scope expansion

Contraction may come from:

• seat reductions
• usage declines
• plan downgrades
• product removals
• lower committed volume
• discounting
• renewal concessions
• location closures
• reduced service scope

The model should show whether expansion is durable, recurring, and customer-driven, or whether it is a one-time reclassification. It should also show whether contraction is tied to customer behavior, pricing pressure, product usage, service quality, billing corrections, or data cleanup.

This matters for forecast variance. If forecasted MRR growth misses because expansion was overestimated or contraction was understated, leadership needs to see that clearly. The forecast variance reporting guide covers how to compare actuals against assumptions without turning every miss into a vague narrative.

What a useful MRR report should show

A useful MRR report should be compact enough for executives and detailed enough for finance and data owners to defend.

The core report should include:

• beginning MRR
• new MRR
• expansion MRR
• contraction MRR
• churned MRR
• reactivation MRR
• ending MRR
• ARR or annualized recurring value
• active recurring customers
• new customers
• churned customers
• logo churn
• gross revenue retention
• net revenue retention where useful
• average revenue per account or customer where useful
• recurring revenue by product, plan, segment, channel, and cohort
• customers with missing mappings
• records excluded from recurring revenue
• billing, subscription, CRM, and finance reconciliation status
• owner-approved definitions and confidence level

The confidence level is important.

Some MRR views may be finance-approved. Others may be directional because product usage, source attribution, or customer hierarchy data is incomplete. Leadership can use directional data when the limitation is visible. Trust breaks when directional metrics are presented as if they are reconciled finance outputs.

Where MRR reporting usually breaks

The failure patterns are predictable.

Mistake 1: treating invoice totals as MRR

Invoice totals often include setup fees, one-time services, taxes, credits, pass-through costs, usage charges, or annual billing.

If the model uses invoice total as MRR, the recurring revenue view will be distorted.

The report needs line-level classification and period logic.

Mistake 2: mixing subscription status with customer status

A subscription can cancel while the customer remains active. A customer can pause one product while expanding another. A billing customer can become inactive while the parent account remains active through a different entity.

Customer, subscription, product, and parent-account status should be modeled separately.

Mistake 3: ignoring partial periods and proration

Mid-month starts, cancellations, plan changes, and annual billing can create partial-period values.

The report should define whether MRR uses ending run rate, daily proration, average MRR, contracted value, or finance-approved period value. Each answer serves a different decision.

Mistake 4: overwriting historical movements

If the reporting model recalculates prior periods using only current subscription state, historical bridges can change unexpectedly.

MRR reporting should preserve effective-dated snapshots, movement facts, or audit history so prior-period reports remain explainable.

Mistake 5: publishing retention metrics before the movement bridge works

Gross revenue retention, net revenue retention, churn, and expansion metrics depend on clean MRR movement logic.

If the bridge is not trusted, retention metrics will create more debate than clarity.

The broader issue is the same pattern behind dashboard trust issues: the dashboard becomes the place where weak definitions become visible.

How BigQuery can support MRR reporting

BigQuery is useful when MRR reporting needs several systems to support one repeatable workflow.

A practical BigQuery model may include:

• raw billing customers, subscriptions, subscription items, plans, invoices, invoice lines, credits, refunds, discounts, and payment status tables
• raw CRM account, opportunity, contract, owner, stage, source, segment, and renewal tables
• raw accounting revenue, deferred revenue, customer, invoice, credit, refund, and adjustment tables
• raw product, usage, workspace, tenant, seat, entitlement, support, and onboarding tables where they affect recurring revenue or retention
• customer and account identity mapping tables
• product, plan, price, channel, segment, period, and owner dimensions
• recurring revenue classification rules with owner and effective date
• subscription snapshot tables by customer, product, plan, and period
• MRR movement fact tables for new, expansion, contraction, churn, reactivation, and adjustments
• ARR and annual contract value tables where needed
• retention cohort tables for gross revenue retention, net revenue retention, and logo churn
• reconciliation tables that compare MRR to billing, CRM, accounting, and revenue reporting outputs
• exception tables for missing customer mappings, unclassified invoice lines, duplicate subscriptions, conflicting statuses, failed payments, unmapped discounts, and late source changes
• reporting-ready tables for leadership, board reporting, finance review, and revenue operations

The goal is not to create a massive subscription analytics platform in the first phase.

The goal is to centralize the data required to explain recurring revenue repeatedly, with visible definitions, stable period logic, and enough controls to support leadership decisions.

If the company is still deciding whether a warehouse is justified, data warehouse requirements for small business can help scope the first phase. If the data foundation already exists but the numbers drift, data warehouse maintenance for BigQuery reporting explains the operating checks needed after launch.

Reconciliation checks that protect trust

MRR reporting should include reconciliation before the numbers reach executives or the board.

Useful checks include:

• ending MRR ties to active recurring subscription records under the approved definition
• recurring invoice lines are classified by product, plan, customer, and revenue type
• invoice totals reconcile separately from recurring revenue totals
• booked recurring revenue ties to CRM closed-won or contract records where applicable
• recognized revenue remains separate from MRR and reconciles to the finance-approved view
• active customers with no active recurring revenue are reviewed
• active recurring revenue with no mapped customer is flagged
• churned subscriptions map to churned customers or valid product churn rules
• expansion and contraction movements tie to source subscription or contract changes
• discounts and credits are classified as recurring or temporary
• failed payments and involuntary churn are visible
• prior-period changes are flagged after close
• manual adjustments include owner, reason, effective period, and approval status

These checks are not only data tests.

They are the operating controls that keep finance, revenue, customer success, and leadership aligned around the same recurring revenue story.

Data quality checks for finance reporting gives a broader checklist for freshness, completeness, duplicates, mappings, reconciliation, and exception handling.

How MRR supports board reporting

Boards often care about MRR because it helps explain recurring growth quality.

But the board version should stay focused.

Useful board-level views may include:

• MRR and ARR trend by month or quarter
• MRR movement bridge
• new, expansion, contraction, churn, and reactivation trends
• gross revenue retention and net revenue retention where definitions are approved
• customer count and logo churn
• recurring revenue by product, segment, channel, and cohort
• forecast MRR versus actual MRR
• retention or expansion risks
• explanation of definition changes or unusual adjustments

The board should be able to see whether recurring revenue growth is coming from new acquisition, expansion, price, retention, contract timing, or data corrections.

MRR should connect to the broader board reporting process. It is most valuable when it uses the same customer, revenue, margin, forecast, and KPI definitions already used elsewhere in the board pack.

What to build first

The first phase should be narrow enough to trust.

A practical first version usually looks like this:

1. Define recurring revenue inclusions and exclusions.
2. Decide whether the first report uses ending MRR, average MRR, contracted MRR, or finance-approved period MRR.
3. Define customer, subscription, product, and parent-account grain.
4. Build source extracts from billing, CRM, accounting, and subscription systems.
5. Classify recurring versus non-recurring line items.
6. Build beginning and ending MRR snapshots.
7. Build the movement bridge for new, expansion, contraction, churn, and reactivation.
8. Add customer, product, segment, channel, owner, and cohort dimensions.
9. Add reconciliation checks and exception tables.
10. Publish one finance-approved leadership view before adding advanced retention metrics.

This scope is usually better than trying to build every SaaS metric, attribution model, and customer-health dashboard at once.

For many companies, the highest-value first workflow is the monthly finance pack, board pack, revenue forecast, customer retention review, or growth efficiency review. Start where the current recurring revenue number already creates questions.

FAQ

What is MRR reporting?

MRR reporting shows monthly recurring revenue and the movements that change it, including new recurring revenue, expansion, contraction, churn, reactivation, discounts, credits, and subscription status changes. It should explain both the ending number and the bridge behind it.

What should an MRR report include?

An MRR report should include beginning MRR, new MRR, expansion, contraction, churn, reactivation, ending MRR, ARR, customer counts, logo churn, net revenue retention where useful, definitions, exclusions, and reconciliation checks. It should also show customer, product, plan, segment, and period context.

Why does MRR reporting lose trust?

MRR reporting loses trust when billing, CRM, accounting, subscription, customer-success, and spreadsheet logic use different definitions for active customers, recurring revenue, churn, expansion, discounts, and period timing. The fix is usually a shared customer map, approved recurring revenue rules, a movement bridge, and visible reconciliation checks.

Can BigQuery support MRR reporting?

BigQuery can support MRR reporting by centralizing billing, subscription, CRM, accounting, product, and customer data, then modeling recurring revenue snapshots, movement facts, customer mappings, and exception checks. That gives finance and leadership a repeatable reporting layer instead of a monthly export rebuild.

Final thought

MRR reporting should make recurring revenue easier to explain, not harder to debate.

The strongest version separates MRR from revenue, billing, ARR, and cash; defines recurring revenue rules; preserves customer identity; and shows the movement bridge behind every period.

When those pieces are modeled clearly, MRR becomes more than a SaaS dashboard metric.

It becomes a practical finance and leadership control for recurring revenue growth.