ARR vs. CARR: Audit-Ready Revenue Metrics

Why ARR and CARR get confused

ARR — Annual Recurring Revenue — is the most quoted number in SaaS boardrooms. But there are at least three different definitions circulating in the same building: trailing-twelve-month recognized revenue, last-month MRR × 12, and total contracted future value. The last one isn't ARR at all — it's CARR, or Committed Annual Recurring Revenue — but the terms get used interchangeably because both measure "how much recurring revenue we have."

The problem isn't just vocabulary. When finance reports one number, sales reports another, and the data team calculates a third, the board sees inconsistency. Inconsistent revenue metrics erode confidence, slow fundraising, and create audit risk. The fix is a clear data model with every definition encoded in SQL, documented, and agreed upon.

What ARR actually measures

ARR is a performance metric. It reflects revenue that has already been earned and is recurring in nature. The purest form is the last complete month's MRR multiplied by 12. It answers: "If nothing changed, how much revenue would we recognize in the next twelve months based on our current run rate?"

This definition has two critical properties that make it audit-friendly:

• It is backward-looking — based on actual invoices posted and recognized, not on signed contracts that may or may not convert.
• It is stable — a customer must actively churn or expand to move the number, so month-to-month changes are explainable.

The downside is that ARR understates growth. A $500K multi-year deal signed yesterday contributes zero to ARR today because no revenue has been recognized yet. That's where CARR comes in.

What CARR measures — and where it gets tricky

CARR is a forward-looking metric. It includes all contracted future recurring revenue, regardless of whether any of it has been recognized yet. The multi-year $500K deal? That's in CARR at full annual value the day the contract is signed.

This makes CARR the metric sales leaders love and auditors scrutinize. To keep it honest, you need clear rules:

• Committed means signed — a verbal agreement or renewal conversation doesn't count until the contract is executed.
• Annualize correctly — a $90K three-year contract contributes $30K to CARR, not $90K. CARR is annual, not total contract value.
• Exclude contingent renewals — optional extensions or auto-renewals with termination windows belong in a separate "pipeline" metric, not CARR.

CARR also requires a churn assumption if you report it as a forward projection. Most teams don't — they report "CARR as of today" and let the reader infer. Either way, document the rule in your SQL view so nobody has to guess.

Modeling both in SQL

The cleanest approach is a single subscription events table that feeds two views: one for ARR and one for CARR. The events table captures every change — new bookings, expansions, contractions, churn, and renewals — with the date the change becomes effective.

-- views/arr.sql
-- ARR = last complete month's MRR × 12
WITH latest_mrr AS (
  SELECT
    DATE_TRUNC('month', event_date) AS month,
    SUM(amount_delta) AS mrr
  FROM subscription_events
  WHERE event_date < DATE_TRUNC('month', CURRENT_DATE)
  GROUP BY 1
  ORDER BY 1 DESC
  LIMIT 1
)
SELECT mrr * 12 AS arr
FROM latest_mrr;

-- views/carr.sql
-- CARR = annualized value of all active committed contracts
WITH active_contracts AS (
  SELECT
    contract_id,
    customer_id,
    annual_recurring_value,
    contract_start_date,
    contract_end_date
  FROM contracts
  WHERE status = 'ACTIVE'
    AND contract_start_date <= CURRENT_DATE
    AND contract_end_date > CURRENT_DATE
)
SELECT
  SUM(annual_recurring_value) AS carr,
  COUNT(DISTINCT customer_id)   AS carr_customers
FROM active_contracts;

Notice that the CARR view queries a separate contracts table, not the events table. This is intentional. Events drive ARR; contracts drive CARR. If you try to derive CARR from events, you miss multi-year deals that haven't started billing yet and overcount cancellations that haven't taken effect.

The reconciliation gap

In a healthy SaaS business, CARR should always be higher than ARR. The gap between them is a forward-looking growth signal — it represents revenue that is contracted but not yet recognized. But the gap can also expose data integrity problems:

• CARR lower than ARR — usually means churned contracts are still in the contracts table, or the ARR view is double-counting expansion events.
• Gap growing without new bookings — check for delayed revenue recognition. Signed deals may be sitting in the contracts table but missing from the billing system.
• Gap shrinking while bookings are strong — the revenue recognition rate may be accelerating, or contract terms are shortening.

I recommend a monthly reconciliation report that compares ARR and CARR side by side with the gap, new bookings, recognized revenue, and churn. When the gap moves, you should be able to explain every dollar.

Audit-readiness and data integrity

Auditors don't care which metric you choose — they care that you choose one, document it, and apply it consistently. The fastest way to fail an audit is to report ARR to the board and CARR to investors without labeling which is which.

My rules for audit-ready ARR / CARR reporting:

1. Name the view what it is — metrics.arr and metrics.carr, not metrics.revenue.
2. Document the definition in SQL comments — every view should have a header comment explaining the formula, inclusions, and exclusions.
3. Version the model in Git — when the definition changes, the commit history shows who changed it, when, and why.
4. Reconcile to source — ARR should tie to the general ledger; CARR should tie to the contract management system. Any variance should be investigated, not adjusted away in Excel.
5. Never change the definition mid-quarter — if the board compares Q1 ARR to Q2 ARR, they must be the same metric. Switching from MRR×12 to recognized TTM is a restatement, not an improvement.

When to use which metric

ARR and CARR serve different audiences and decisions. Use ARR when you need a stable, auditable performance number — for compensation planning, historical trend analysis, and board reporting on "what we did." Use CARR when you need a growth indicator — for pipeline planning, fundraising narratives, and strategic planning on "what we have committed."

Most mature SaaS finance teams report both, clearly labeled, and explain the gap in the narrative. The best CFOs I have worked with lead the board pack with ARR, add CARR as a forward supplement, and always include a reconciliation footnote. The transparency builds more confidence than either metric alone.

Summary

ARR and CARR are not interchangeable. ARR is earned, recognized, and backward-looking. CARR is contracted, forward-looking, and includes revenue not yet billed. Model them in separate SQL views, reconcile them monthly, document the definitions, and never change mid-quarter. The metric you choose matters less than the integrity with which you calculate it.