Large language models cannot reliably build ARR snowball analyses from raw operational data. Despite their ability to summarize text, generate code, and answer questions about SaaS metrics, LLMs lack the rule-based calculations, system-of-record awareness, and company-specific logic required to decompose recurring revenue into its component movements — new, expansion, contraction, and churn — from bookings, billing, or revenue source systems.

This matters because PE-backed SaaS operators increasingly ask AI tools to “build me an ARR snowball” from their CRM exports, Stripe billing data, or ERP revenue tables. The results look plausible. They’re also often wrong in ways that are invisible without deep domain expertise.

What Makes ARR Snowball Construction Hard

An ARR snowball decomposes period-over-period ARR change into five movements: Starting ARR, New ARR, Expansion ARR, Contraction ARR, and Churned ARR. Each movement requires precise classification of every customer’s revenue change against a prior period baseline. This is a rule-based calculation — there is exactly one correct answer for a given dataset and classification ruleset. For a deeper look at these components, see our guide to ARR waterfall models.

The challenge is that the input data is never clean, never standardized, and never complete in a single system.

Source System	What It Captures	What It Misses for ARR
CRM (Salesforce, HubSpot)	Bookings, deal close dates, ACV, renewal dates	Actual revenue recognition, mid-contract changes, billing adjustments, credits
Billing (Stripe, Chargebee, Zuora)	Invoice amounts, subscription status, plan changes	Multi-year deal structures, professional services carve-outs, negotiated discounts not in billing
ERP (NetSuite, Sage Intacct)	Recognized revenue, deferred revenue schedules	Forward-looking ARR (recognized revenue ≠ ARR), customer-level granularity often missing

As Bessemer Venture Partners notes in their cloud metrics research, ARR is the foundational metric for SaaS valuation — but its accuracy depends entirely on the rigor of how it’s calculated from source systems.

Why LLMs Fail at This Task

1. LLMs Do Not Compute — They Predict

LLMs generate outputs by predicting the most likely next token. When you ask an LLM to calculate ARR movements from a spreadsheet, it is not performing arithmetic — it is pattern-matching against training data about what ARR calculations look like. For small, clean datasets this may produce correct results. For real-world operational data with thousands of rows, edge cases, and exceptions, the error rate is unacceptable for board-level reporting.

A single misclassification — coding a contraction as churn, or double-counting a renewal with a price increase as both expansion and new — cascades through the entire snowball. The starting ARR for the next period is wrong, which makes every subsequent movement wrong.

2. Operational Data Needs an Analytics Database, Not a Chat Agent

ARR snowball construction requires tracking each customer’s ARR across multiple periods and comparing current-period ARR to prior-period ARR to classify the movement. A chat agent processes each prompt in isolation — it has no memory of last quarter’s numbers, no running ledger of customer ARR, and no way to apply the same rules consistently across thousands of records.

More importantly, every company has its own nuances to how they define ARR. What counts as “expansion” versus “new” when an existing customer signs a separate contract for a different product? When does a downgrade become churn? These aren’t universal definitions — they’re company-specific rules that often take weeks to align on internally. In many organizations, Finance, Sales, and RevOps can’t even agree on the definitions, which is exactly where an experienced ARR expert is needed to codify the rules before any tool — AI or otherwise — can automate the calculation.

LLMs have no mechanism to:

• Maintain a running customer-level ARR ledger across periods
• Apply your company’s specific ARR classification rules consistently to every record (an LLM may classify the same scenario differently on successive runs)
• Handle fiscal calendar logic — month-end cutoffs, mid-month starts, annual vs. monthly billing normalization
• Track customer identity across systems where the same customer has different IDs in CRM, billing, and ERP — a problem Pacer AI solves with a unified Customer Data Cube

3. Every Company’s Data Is Messy in Its Own Way

LLMs are built to understand language. But the problem with operational data isn’t that it’s hard to read — it’s that every company has its own way of doing things, and those custom processes create data patterns that no general-purpose AI model has been trained on. Consider these real scenarios that break naive ARR calculations:

• CRM booking ≠ billing amount: A $120K ACV deal in Salesforce may bill as $10K/month in Stripe, but with a 90-day free trial the first invoice is $0. The CRM says $120K ARR from day one. Billing says $0 for three months.
• Multi-product bundling: A customer contracts for Product A at $50K and Product B at $30K. When they drop Product B, is that $30K contraction or partial churn? The answer depends on your ARR policy, and it must be applied consistently across every customer.
• Revenue recognition timing: ERP records revenue as it’s recognized under ASC 606. A 3-year prepaid deal recognized ratably shows flat monthly revenue — but the ARR impact happened at booking. The ERP view and the ARR view are fundamentally different lenses on the same contract. SaaS Capital’s research on SaaS metrics highlights how this disconnect between recognized revenue and ARR frequently leads to reporting errors.
• Customer mergers and splits: When Customer A acquires Customer B, do you show churn for B and expansion for A? Or maintain continuity? LLMs have no way to apply your company’s specific M&A accounting policy.

4. Hallucination Risk in Financial Reporting

When an LLM encounters a data scenario it hasn’t seen in training — a negative invoice, a backdated contract amendment, a currency conversion edge case — it doesn’t flag uncertainty. It produces an answer. In a narrative summary, a hallucination is an inconvenience. In an ARR snowball that goes to your board or PE sponsor, a hallucination is a material misstatement.

The board deck problem is acute: ARR snowball numbers must reconcile to the general ledger, to the CRM pipeline, and to the billing system totals. LLMs cannot perform three-way reconciliation because they cannot hold all three datasets in context simultaneously, and they cannot guarantee that intermediate calculations are arithmetically correct. Research from Apple’s GSM-NoOp study demonstrated that LLMs fail on even basic math problems when irrelevant information is added — exactly the kind of noisy data present in real operational systems.

What LLMs Can Do Well in the ARR Workflow

This is not an argument against using AI in revenue operations. LLMs add genuine value in specific parts of the ARR analysis workflow — just not the core computation.

Task	LLM Capability	Why It Works
Explaining ARR movements in narrative form	Strong	Natural language generation from structured data is a core LLM strength
Drafting board commentary on trends	Strong	Summarization and pattern description, not calculation
Suggesting data cleaning rules	Moderate	Can identify common patterns, but rules must be validated by humans
Generating SQL or Python for ARR calculations	Moderate	Can produce code scaffolds, but logic must be reviewed for edge cases
Classifying ARR movements from raw data	Weak	Not repeatable, no state management, cannot guarantee consistency
Reconciling across CRM, billing, and ERP	Weak	Cannot hold multiple large datasets in context or verify arithmetic

What the ARR Snowball Actually Requires

Building an accurate ARR snowball from operational data requires a purpose-built data pipeline, not a language model. The core requirements are:

1. Rule-based classification: Consistent logic that classifies every customer’s period-over-period ARR change as new, expansion, contraction, or churn — the same way, every time, for every customer.
2. Cross-system customer matching: Connecting customer records across CRM, billing, and ERP where names, IDs, and hierarchies differ. This is a data engineering problem, not a language problem.
3. Period-over-period tracking: Maintaining a customer-level ARR ledger that tracks the prior-period baseline for movement classification. Without this, you cannot distinguish expansion from new.
4. Automated reconciliation: Checks that verify the snowball’s ending ARR equals the sum of starting ARR plus all movements, and that totals tie to source system totals within an acceptable tolerance.
5. Full audit trail: Every ARR movement must trace back to a specific source record — a CRM opportunity, a billing subscription change, or an ERP journal entry. LLMs cannot provide this traceability.

As OpenView’s SaaS benchmarks consistently show, the companies with the most accurate revenue reporting are the ones that invest in data infrastructure — not the ones that adopt the flashiest AI tools.

The Pacer AI Approach

Pacer AI handles ARR snowball construction with a rule-based data engine — not an LLM — that ingests operational data from CRMs, billing platforms, and ERPs, resolves customer identities across systems, applies consistent classification rules, and produces reconciled, auditable ARR snowball reports. The AI layer sits on top: generating narratives, surfacing anomalies, and drafting board commentary from the verified numbers.

This is the critical distinction. The computation must be rule-based and auditable. The intelligence layer — explaining what the numbers mean, identifying churn risk, recommending actions — is where LLMs add value. Conflating the two is where ARR analysis goes wrong.

Key Takeaways for SaaS Operators

• Do not trust LLM-generated ARR snowballs from raw CRM, billing, or ERP data without independent verification against source systems.
• Use LLMs for narrative and analysis — explaining movements, drafting board commentary, identifying patterns — not for the underlying calculations.
• Demand auditability: Every number in your ARR snowball should trace to a source record. If your tool cannot show you why Customer X is classified as expansion, the number is unreliable.
• Recognize the data unification problem: The hardest part of ARR analysis is not the math — it’s reconciling three different views of the same customer across CRM, billing, and ERP. This requires purpose-built data pipelines, not prompts.