What does C:B mean in a Google Sheets formula?

`C:B` is an unbounded column range referencing the entirety of columns B and C. Google Sheets automatically normalizes it to `B:C` when you enter the formula - the reversed column order has no functional effect. Both forms reference every row in those columns, from row 1 through the sheet's maximum height. You'll most often see it in SUMIFS, VLOOKUP, and INDEX/MATCH as a way to avoid hardcoding a row endpoint.

Is there a performance difference between B:B and B2:B1000 in Google Sheets?

Yes, though it's usually small for typical financial models. `B:B` forces Sheets to evaluate the entire column on each recalculation, while `B2:B1000` limits the scan to 999 rows. For models with under 10,000 rows of source data and 50 or fewer SUMIFS formulas, the difference is under 1 second. It becomes material with larger datasets (15,000+ rows), array formulas that multiply the scan scope, or models with 80+ dependent formulas recalculating simultaneously. Google Sheets caps total spreadsheet size at 10 million cells, so the theoretical ceiling on column scan depth is constrained - but a single tab's column can still contain ~4 million rows.

Can C:B or B:B cause a circular reference in Google Sheets?

Yes, if any formula in column B or C references `C:B`, `B:C`, `B:B`, or `C:C`, you'll get a circular reference error. This most commonly happens when someone adds a SUMIFS into column B that uses `B:B` as a criteria range, or when an ARRAYFORMULA in column C references `C:C`. Check for circular references via the chain icon that appears in the Sheets toolbar, or look for the blue trace arrows under View → Show formula traces.

How do I reference open column ranges across tabs in Google Sheets?

Use the tab name in single quotes followed by an exclamation mark: `'P&L'!C:C`. If the tab name contains spaces or special characters, the single quotes are required. Build cross-tab references by clicking the destination tab while your cursor is inside the formula bar - Sheets inserts the correct syntax automatically and handles any escaping. Reversed cross-tab notation like `'P&L'!C:B` auto-corrects to `'P&L'!B:C` on entry.

When should I use a named range instead of an open column reference?

Use a named range when you need bounded performance but the data footprint isn't fixed. Define the named range to cover your maximum expected row count (5,000 rows if you're pulling monthly actuals, 20,000 if you're working with transaction-level data), update it once when the dataset grows, and reference the name across all formulas in your model. This is especially valuable in board pack models and DCFs where 40+ formulas pull from the same source columns - changing a single named range definition is far faster than auditing every formula. Named ranges also make model reviews faster: `=SUMIFS(FCF_Actuals, FCF_Dates, ">="&Model_Start)` is self-documenting in a way that `=SUMIFS('Cash Flow'!F:F, 'Cash Flow'!B:B, ">="&Assumptions!$C$4)` never will be.

C:B Google Sheets Range: Unbounded Columns Explained (2026)

This notation shows up constantly in financial models because it's durable. It doesn't break when rows get inserted above your data. But it comes with trade-offs worth understanding before you build a 40-formula board pack on top of it.

What "C:B" Actually References

B:B references the entirety of column B - every row, no bounds. B:C (or C:B) covers that same full height for both columns B and C. When Sheets evaluates a formula using these ranges, it scans every row in those columns, including the thousands of blank cells below your actual data.

As of May 2026, Google Sheets caps total spreadsheet size at 10 million cells. A single open column reference on a sheet with 26 columns touches roughly 160,000 cells per column, per formula evaluation. That's manageable in isolation. Multiply it across 50 SUMIFS in a P&L model and recalc time starts to compound.

A real cross-tab example from a quarterly close model:

=SUMIFS('P&L'!D:D, 'P&L'!B:B, ">="&Assumptions!$C$3, 'P&L'!B:B, "<="&Assumptions!$C$4, 'P&L'!C:C, Returns!$A2)

This sums revenue in column D where dates in column B fall within a period and segment codes in column C match a value from the Returns tab. It works correctly and keeps working if the P&L grows from 400 to 1,400 rows without anyone touching the formula.

C:B vs B:C: Is There a Functional Difference?

No. Type C:B in the formula bar and Sheets auto-corrects to B:C on entry. The formula evaluates identically regardless of which order you typed the columns.

This matters when inheriting models copy-pasted from Excel. Excel's behavior around reversed column notation varies by version and context. If you're building a model that needs to run cleanly in both environments, write the conventional left-to-right form (B:C, not C:B). It avoids questions from anyone who reviews the file.

When Open Column Ranges Belong in a Model

The strongest case for B:B over B2:B5000 is dynamic source data - tables that grow without a predictable endpoint. Monthly ERP exports, rolling actuals, headcount tables with new hire rows added weekly by HR.

Compare these two in a headcount burn model:

Approach	Formula	Risk
Bounded	`=SUMIFS('HC'!E2:E500, 'HC'!C2:C500, "Engineering", 'HC'!D2:D500, "<="&Assumptions!$B$3)`	Silently misses rows 501+ when someone pastes Q3 hiring data
Unbounded	`=SUMIFS('HC'!E:E, 'HC'!C:C, "Engineering", 'HC'!D:D, "<="&Assumptions!$B$3)`	Catches all rows; slightly slower recalc

In a runway sensitivity model where new hire pace drives burn assumptions, a silent row miss produces wrong numbers in the board pack. The bounded version looks tighter but breaks in the worst possible way: silently, with no error.

A contribution margin analysis by SKU pulling from a transaction tab is another good candidate. You don't know how many rows next month's download will contain. =SUMIFS('Txns'!D:D, 'Txns'!A:A, SKU!$A2, 'Txns'!C:C, Assumptions!$B$1) handles 800 rows and 8,000 rows identically.

When Open Column Ranges Hurt You

3 scenarios where you want bounded ranges instead:

Same-column circular references. If column B contains formulas that reference B:B, you get a circular reference immediately. This is the most common way open column ranges break a model - someone adds a SUMIFS in column B that uses B:B as its criteria range.

High-formula-count models with volatile recalc. A bank syndicate DCF with 60+ SUMIFS formulas pulling from a 20,000-row transaction export will recalculate noticeably slower with unbounded ranges. According to Google's Sheets documentation on formula performance, reducing range scope is one of the primary recommendations for improving recalc speed in complex spreadsheets.

ARRAYFORMULA interactions. If column C is populated by an ARRAYFORMULA that spills down, referencing C:C in a SUMIFS in the same sheet can produce unpredictable results. The ARRAYFORMULA's output and the referencing formula don't always resolve in the right order.

Cross-Tab Syntax with Open Column Ranges

The pattern is identical to bounded cross-tab references - prefix the range with the sheet name in single quotes:

=SUMIFS('P&L'!C:C, 'P&L'!B:B, ">="&Assumptions!$B$3, 'P&L'!B:B, "<="&Assumptions!$B$4)

If the tab name contains spaces (like Cash Flow or Returns Analysis), single quotes are required and Sheets inserts them automatically when you click to build the reference. Writing 'P&L'!C:B (reversed cross-tab) auto-corrects to 'P&L'!B:C on entry - it doesn't break anything, but it'll get you raised eyebrows in a model review.

For INDEX/MATCH pulling LTM EBITDA from a financial summary tab:

=INDEX('Fin Summary'!D:D, MATCH(Assumptions!$B$2, 'Fin Summary'!B:B, 0))

Column D is the value array (unbounded), column B is the lookup array (unbounded). Works cleanly as long as neither column contains formulas that themselves reference D:D or B:B.

The Actual Performance Numbers

For most FP&A models - under 5,000 rows of transaction data, 30-50 SUMIFS formulas - the difference between B:B and B2:B5000 is under half a second. Not worth losing sleep over.

It becomes meaningful when:

Transaction data exceeds ~15,000 rows
You stack SUMIFS with ARRAYFORMULA or MMULT, multiplying the scan per cell
The model has 80+ dependent formulas recalculating simultaneously

A quarterly P&L model with 12 months of daily revenue (~3,000 rows) and 40 SUMIFS pulling from it: unbounded ranges add roughly 0.5-1.0 seconds to full recalc. Livable. A 5-year DCF pulling from a 50,000-row database export with the same approach: switch to bounded ranges or named ranges.

Named Ranges Cut the Trade-Off

If you're choosing between "unbounded and potentially slow" or "bounded and silently fragile," named ranges solve both problems. Define PL_Revenue as 'P&L'!$D$2:$D$3000 in the Named Ranges manager (Data → Named ranges), then reference it throughout your model:

=SUMIFS(PL_Revenue, PL_Dates, ">="&Assumptions!$B$3, PL_Segment, Returns!$A2)

The range is bounded (no scan penalty), but updating the boundary when the P&L grows only requires editing the named range definition once - not hunting through 40 formulas across 8 tabs. When a CFO asks you to walk through assumptions live, =SUMIFS(FCF_Actuals, FCF_Dates, ">="&Model_Start) also reads considerably better than a 120-character SUMIFS with 'Cash Flow'!F:F buried in it.

ModelMonkey can scan an existing multi-tab model and identify which formulas use unbounded column ranges vs named ranges - useful when you've inherited a model and need to understand where the recalc bottlenecks are before a board deadline. Try ModelMonkey free for 14 days - it works in both Google Sheets and Excel.