How do I build a revenue bridge in Google Sheets?

A revenue bridge decomposes a revenue change into price, volume, and mix components. You need 3 SUMIFS formulas per segment: one for current period actual, one for prior period actual, and one for budget. Store your date ranges in a single `Assumptions` tab so every formula references the same toggle. Price variance = (current price − prior price) × current volume; volume variance = (current volume − prior volume) × prior price; mix is the remainder. For a $600K gap against a $4.8M budget, this structure tells you whether to fix pricing, sales capacity, or product mix — three different root causes that require three different responses.

What's the fastest way to analyze contribution margin by product in Google Sheets?

Keep a `Products` master tab with SKU, category, and standard COGS per unit. In your analysis, use SUMIFS for revenue and units sold, then XLOOKUP to pull the COGS rate from the master and multiply by units. The result is contribution margin in dollars per SKU. Avoid hardcoding COGS rates in your analysis tab — when standard costs update, you want one place to change. For a portfolio with 38.5% blended gross margin, this calculation typically reveals that 20% of SKUs generate 60%+ of contribution dollars, which is where pricing and volume decisions should focus.

How many rows can Google Sheets handle for sales analysis?

Google Sheets caps at 10 million cells per spreadsheet, but the practical SUMIFS limit is around 100,000–200,000 rows before recalculation lag hits 15–30 seconds per change. Above that threshold, pre-aggregate your transactions into quarterly summary ranges that your analysis tab references rather than scanning raw rows directly, or use the `QUERY` function for aggregation-heavy pulls on a single sheet. For truly large datasets (500K+ rows), consider pulling pre-aggregated summaries from your source system rather than grain-level transactions.

How do I do cohort retention analysis in Google Sheets?

You need a `First Purchase Date` column on your transactions data. If it's not there, calculate it with `=MINIFS('Transactions'!B:B, 'Transactions'!CustomerID, CustomerID)` as a helper. Then build a double-condition COUNTIFS: one date condition for the acquisition window, one for the retention period. Lay out a 12×12 matrix — acquisition cohort on one axis, observation period on the other — to see retention by cohort over time. Net revenue retention above 110% is generally considered strong in SaaS diligence; below 80% is a structural red flag regardless of top-line growth.

Why do my SUMIFS formulas recalculate so slowly across tabs?

Each SUMIFS across a tab triggers a full scan of the referenced range on every workbook change. With 30+ SUMIFS each scanning 50,000+ rows, recalculation stacks up fast. Three fixes: first, switch from full-column references (`E:E`) to bounded ranges (`E2:E50000`) — this alone often cuts recalculation time by 40–60%. Second, turn off automatic recalculation during model building (Tools → Calculation settings → On change) and manually trigger with Ctrl+Shift+F9. Third, pre-aggregate your transaction data into a summary range — a `MonthlyBySegment` tab with pre-calculated subtotals — so your analysis formulas reference 200 rows instead of 50,000.

Analyze Sales Data in Google Sheets: FP&A Framework

What Sales Analysis Actually Requires

The deliverable your CFO cares about isn't total revenue by month. It's the story: how much of the $2.3M shortfall vs. budget was price, how much was volume, and which segments drove it.

That requires linked tabs. A Transactions tab at the grain level (order ID, date, customer, SKU, quantity, unit price). A Products master with segment mapping and standard COGS. An Assumptions tab holding date toggles and budget figures. An Analysis tab where every number traces back through a formula, nothing hardcoded.

Analysts who skip this structure end up with analysis that can't be re-run. The architecture is the analysis.

Revenue Bridge and Variance Analysis

A revenue bridge decomposes the change in revenue into price effect, volume effect, and mix effect. The formulas aren't complicated — the discipline is making every date reference point to a single source.

// Actual revenue for current period, by segment (Analysis!A5 = segment name)
=SUMIFS('Transactions'!E:E,
        'Transactions'!B:B, ">="&Assumptions!$B$3,
        'Transactions'!B:B, "<="&Assumptions!$C$3,
        'Transactions'!D:D, Analysis!$A5)

// Budget comparison for same period and segment
-SUMIFS('Budget'!E:E,
        'Budget'!B:B,       ">="&Assumptions!$B$3,
        'Budget'!B:B,       "<="&Assumptions!$C$3,
        'Budget'!D:D,       Analysis!$A5)

Assumptions!$B$3:$C$3 is your period toggle — change it once, every tab recalculates. This is the difference between a model that takes 2 minutes to update for a new quarter and one that takes 2 hours.

For a realistic scenario: a company with $4.2M in Q1 revenue against a $4.8M budget has a $600K shortfall. Without the bridge, you don't know if the problem is pricing (sales team discounting), volume (fewer units closed), or mix (too many low-margin SKUs). Those are three different conversations with three different fixes.

Contribution Margin by SKU

Contribution margin by SKU sounds simple until you realize the unit economics live in a different tab from the transaction data, and the SKU codes don't match between systems.

The pattern that works: a Products master with a SKU column, a category column, and a standard COGS column. Then in Analysis:

// Contribution margin = Revenue - (Standard COGS per unit × Units sold)
=SUMIFS('Transactions'!E:E, 'Transactions'!D:D, $A5,
        'Transactions'!B:B, ">="&Assumptions!$B$3)
-(IFERROR(XLOOKUP($A5, Products!$A:$A, Products!$C:$C), 0)
  * SUMIFS('Transactions'!C:C, 'Transactions'!D:D, $A5,
           'Transactions'!B:B, ">="&Assumptions!$B$3))

This gives you contribution margin in dollars per SKU. Divide by revenue for the rate. In most portfolios with a 38.5% blended gross margin, a handful of SKUs account for 60%+ of total contribution dollars — and several are quietly destroying the average. That's the finding that makes a board pack worth reading.

Cohort and Retention Analysis

Cohort analysis separates revenue quality from revenue quantity. A company with $8M ARR and 90% net revenue retention is a different business from one with $8M ARR and 70% retention — the former is compounding, the latter is churning.

The building block in Sheets is a double-condition COUNTIFS: one for the acquisition window (when the customer first appears), one for the retention window (whether they're still buying in a later period).

// Customers acquired in Q1 2025 who also transacted in Q4 2025
=COUNTIFS('Transactions'!F:F, ">="&DATE(2025,1,1),   // First purchase >= cohort start
          'Transactions'!F:F, "<="&DATE(2025,3,31),   // First purchase <= cohort end
          'Transactions'!B:B, ">="&DATE(2025,10,1),   // Revenue in Q4
          'Transactions'!B:B, "<="&DATE(2025,12,31))

Column F here is First Purchase Date — calculate it with =MINIFS('Transactions'!B:B, 'Transactions'!CustomerID:CustomerID, CustomerID) if your data doesn't already have it. Once you have it, a 12×12 retention heatmap builds itself: acquisition cohort on one axis, observation period on the other. That matrix is what VCs ask for in every Series B diligence and what a bank syndicate wants to see in a sponsor-backed deal.

Choosing the Right Tool for Each Analysis

Not all sales analysis belongs in SUMIFS. As of April 2026, here's how the main approaches compare in practice:

Analysis type	Best tool	Key limitation
Aggregation, single dimension	`SUMIFS`	Slows above ~150K rows
Multi-condition, cross-tab	`SUMIFS` + `XLOOKUP`	No true multi-table join
SQL-style grouping/filtering	`QUERY`	Single sheet only, no cross-sheet joins
Live cross-file data	`IMPORTRANGE` + `QUERY`	Latency, breaks on large ranges
Grain-level joins from multiple sources	External tool	Sheets can't do this natively

According to Google's Sheets documentation, the QUERY function uses "a limited subset of the SQL language" — no joins, no subqueries, single-sheet scope. Analysts who try to use QUERY across sheets hit this ceiling fast.

Where Google Sheets Starts to Break

Google Sheets caps at 10 million cells per spreadsheet. That's rarely the constraint. The real ceiling for SUMIFS-heavy sales analysis is around 100,000–200,000 rows, where recalculation lag becomes 15–30 seconds per change — enough to make scenario analysis painful.

The other failure mode is data assembly. When your transactions live in Salesforce or NetSuite, getting them into Sheets means a weekly manual export, which makes your "live model" a weekly snapshot. IMPORTRANGE adds latency and breaks silently on large ranges. The analysis is fine; the data pipeline isn't.

This is where AI tools for Google Sheets close a real gap. Instead of managing exports and IMPORTRANGE dependencies, you describe the data pull in plain language and the agent handles the assembly. For a board pack where transactions come from Salesforce, budget data from NetSuite, and headcount from Workday, eliminating that assembly step is the actual time savings — not the formulas themselves.

ModelMonkey handles this natively inside Google Sheets: connect your sources, ask for the pull, get structured data back ready for your existing SUMIFS model. The formulas you've already built keep working; you just stop spending Sunday afternoon copying CSVs.

In summary: solid sales analysis in Google Sheets runs on a clean tab architecture, date references that live in one place, and SUMIFS that reach across tabs consistently. The frameworks — bridge, margin, cohort — aren't complicated. What's complicated is keeping the data clean enough to trust the output when the CFO asks a follow-up question.

Try ModelMonkey free for 14 days — it works in both Google Sheets and Excel.